From kwythers at umn.edu Mon Oct 1 00:23:38 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Mon Oct 1 00:23:43 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: <18175.54430.44379.387499@cerise.gclements.plus.com> References: <049F0A26-957D-4542-A32E-59683CBA2665@umn.edu> <18175.54430.44379.387499@cerise.gclements.plus.com> Message-ID: <8480918A-355E-4AF6-82E6-9CF388726861@umn.edu> On Sep 30, 2007, at 11:53 AM, Glynn Clements wrote: > > Michael Barton wrote: > >> I haven't updated in a few days but don't have a problem. Have you >> run >> g.region to see what your resolution is? The res=0.0 is the >> problem. It is >> getting this value from running g.region previously in your mapset, >> returning rows, columns, and res. > > GmAnim::main has: > > regexp {nsres= *([0-9]+)} $region dummy oldres1 > regexp {ewres= *([0-9]+)} $region dummy oldres2 > > This isn't going to work if your resolution is less than one unit, > e.g. lat/lon regions. > > The regexp needs to allow for a decimal point. It is odd because on my G5, grass63 (but last updated a month or two ago), gmanim runs fine with the mapset in question. However, on my macbook pro (intel) and newly updated, the same mapset throws the error. The output from g.region is: GRASS 6.3.cvs (global_30s):~ > g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: ** unknown (default: WGS84) ** ellipsoid: sphere north: 90N south: 90S west: 180W east: 180E nsres: 0:05 ewres: 0:05 rows: 2160 cols: 4320 cells: 9331200 So I think Glynn is right (looks like the resolution is less than one unit. But.. why would it work on my G5? Kirk From michael.barton at asu.edu Mon Oct 1 05:34:59 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Oct 1 05:35:07 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: <18175.54430.44379.387499@cerise.gclements.plus.com> Message-ID: Glynn, I am really bad at regexp. Can you suggest how to redo this so as to permit decimals? I'm pretty sure that it would fix a problem reported by Hamish a few weeks back that was baffling. I'm currently on the road and cannot commit to the CVS, but could do so when I get back if need be. Michael On 9/30/07 9:53 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I haven't updated in a few days but don't have a problem. Have you run >> g.region to see what your resolution is? The res=0.0 is the problem. It is >> getting this value from running g.region previously in your mapset, >> returning rows, columns, and res. > > GmAnim::main has: > > regexp {nsres= *([0-9]+)} $region dummy oldres1 > regexp {ewres= *([0-9]+)} $region dummy oldres2 > > This isn't going to work if your resolution is less than one unit, > e.g. lat/lon regions. > > The regexp needs to allow for a decimal point. __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Mon Oct 1 06:23:40 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Oct 1 06:23:48 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: <18175.54430.44379.387499@cerise.gclements.plus.com> Message-ID: Well, after asking for help, I figured out how to this without the dread regexp ;-). This might even be a bit better routine. Anyway, I can't commit this because I'm out of town, but if anyone wants to try it, you need to change lines in procedure GmAnim::main (module animate.tcl). Replace the commented lines with the uncommented lines below. foreach line $reglist { set line [string trim $line] set key [lindex [split $line "="] 0] switch $key { nsres {set oldres1 [lindex [split $line "="] 1]} ewres {set oldres2 [lindex [split $line "="] 1]} rows {set vrows [lindex [split $line "="] 1]} cols {set vcols [lindex [split $line "="] 1]} } } # regexp {nsres= *([0-9]+)} $region dummy oldres1 # regexp {ewres= *([0-9]+)} $region dummy oldres2 # regexp {rows= *([0-9]+)} $region dummy vrows # regexp {cols= *([0-9]+)} $region dummy vcols Michael On 9/30/07 9:53 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I haven't updated in a few days but don't have a problem. Have you run >> g.region to see what your resolution is? The res=0.0 is the problem. It is >> getting this value from running g.region previously in your mapset, >> returning rows, columns, and res. > > GmAnim::main has: > > regexp {nsres= *([0-9]+)} $region dummy oldres1 > regexp {ewres= *([0-9]+)} $region dummy oldres2 > > This isn't going to work if your resolution is less than one unit, > e.g. lat/lon regions. > > The regexp needs to allow for a decimal point. __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Mon Oct 1 07:55:06 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 1 07:55:12 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> Message-ID: <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> Hamish wrote: > I notice over the last day or two a high number of seemingly randomly > generated new user accounts on our wiki site. We can ban these fake > users as they come and hope we don't hit anyone real, but at 10/day > it becomes an ugly chore, time sink, and demotivator. Up til now we've > been getting a few suspect accounts at the rate of around 1/week but no > automated spam. > > We are up to 908 users registered, most appear to be spambot accounts, > but only 41 have been manually blocked. > > There are apparently plans afoot to upgrade the wiki software on the > server, hopefully the new version will contain stronger capcha > mechanisms to weed out the jerks and we can spend more time on useful > work. Hopefully it can easily rank and remove bogus accounts instead of > just blocking them. > > to combat wiki spam we need to keep an eye on the recent changes page, > http://grass.gdf-hannover.de/wiki/Special:Recentchanges over the weekend there were 56 new spambot accounts opened in the wiki. I am now working through the wiki's web interface to ban these one by one, but it is a big drain of time which I would much prefer to spend on more productive tasks. the sooner we get this situation fixed the better. Hamish From hamish_nospam at yahoo.com Mon Oct 1 07:57:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 1 07:57:21 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> Message-ID: <20071001185716.6862a47c.hamish_nospam@yahoo.com> Hamish wrote: > over the weekend there were 56 new spambot accounts opened in the wiki. > I am now working through the wiki's web interface to ban these one by > one, but it is a big drain of time which I would much prefer to spend > on more productive tasks. the sooner we get this situation fixed the > better. oops I counted wrong, make that 68 new accounts to ban. Hamish From landa.martin at gmail.com Mon Oct 1 08:14:33 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Oct 1 08:14:36 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: <20071001185716.6862a47c.hamish_nospam@yahoo.com> References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> <20071001185716.6862a47c.hamish_nospam@yahoo.com> Message-ID: Hamish, 2007/10/1, Hamish : > Hamish wrote: > > over the weekend there were 56 new spambot accounts opened in the wiki. > > I am now working through the wiki's web interface to ban these one by > > one, but it is a big drain of time which I would much prefer to spend > > on more productive tasks. the sooner we get this situation fixed the > > better. > > oops I counted wrong, make that 68 new accounts to ban. hm, too bad. Not sure how to avoid this situation. To allow creating new accounts only for sysops is maybe too restrictive... Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From maris.gis at gmail.com Mon Oct 1 09:22:17 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Mon Oct 1 09:22:21 2007 Subject: [GRASS-dev] [grass-code I][495] gis.m output window buttons don't fit text width In-Reply-To: <4700059F.80803@jemila.jazztel.es> References: <4700059F.80803@jemila.jazztel.es> Message-ID: <2b3d8c1c0710010022x50cee6a5n76bc3d44c7938be6@mail.gmail.com> Hi, just 2 notes: 1) Carlos - when reporting such issues, please, specify language. If language is know, anyone can test it with "export LC_ALL=es_ES"; 2) Michael - for bugreports, please, check it at bug tracker, as attachments may not be forwarded to ML. Also - any important comments should be attached to bugreport, as not everyone will search bug reports AND ML for same issue. Sorry for interuption, Maris. 2007/9/30, Carlos D?vila : > Michael Barton escribi?: > > Carlos, > > > > Which buttons? Can you send a screenshot? > > > You can see it here: > http://wald.intevation.org/tracker/download.php/21/204/495/232/Salida%20-%20GIS.m.png > > Michael > > > > NB: It would be nice if the the difficulty of replying to Carlos in this > > message could be reduced (i.e., not having to manually look up his email > and > > paste it in to my reply) > > > > > > On 9/30/07 6:13 AM, "grass-dev@grass.itc.it" > wrote: > > > > > >> code I item #495, was opened at 2007-09-30 15:13 > >> Status: Open > >> Priority: 3 > >> Submitted By: Carlos D?vila (carluti) > >> Assigned to: Nobody (None) > >> Summary: gis.m output window buttons don't fit text width > >> Issue type: module bad feature > >> Issue status: None > >> GRASS version: CVS HEAD > >> GRASS component: gis.m > >> Operating system: Linux > >> Operating system version: debian testing > >> GRASS CVS checkout date, if applies (YYMMDD): > >> > >> > >> Initial Comment: > >> Translated text within some buttons is larger than default width and text > is > >> cut, even if you enlarge the window. > >> > >> ---------------------------------------------------------------------- > >> > >> You can respond by visiting: > >> > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=495&group_id=21 > >> > >> > >> > > > > __________________________________________ > > 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-6213 > > fax: 480-965-7671 > > www: http://www.public.asu.edu/~cmbarton > > > > > > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From neteler at itc.it Mon Oct 1 10:06:47 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Oct 1 10:06:50 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> <20071001185716.6862a47c.hamish_nospam@yahoo.com> Message-ID: <4700AA97.1090308@itc.it> Martin Landa wrote on 10/01/2007 08:14 AM: > Hamish, > > 2007/10/1, Hamish : > >> Hamish wrote: >> >>> over the weekend there were 56 new spambot accounts opened in the wiki. >>> I am now working through the wiki's web interface to ban these one by >>> one, but it is a big drain of time which I would much prefer to spend >>> on more productive tasks. the sooner we get this situation fixed the >>> better. >>> >> oops I counted wrong, make that 68 new accounts to ban. >> > > hm, too bad. Not sure how to avoid this situation. To allow creating > new accounts only for sysops is maybe too restrictive... > Once Martin arrives in the office, we'll schedule an update of\ MediaWiki (hopefully later today). Would it help to enable a captcha? Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From hamish_nospam at yahoo.com Mon Oct 1 12:08:48 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 1 12:09:02 2007 Subject: [GRASS-dev] BLAS/LAPACK detection (was: configure fails) In-Reply-To: <18172.49308.435792.213235@cerise.gclements.plus.com> References: <1389.85.10.67.113.1190573958.squirrel@geog-pc40.ulb.ac.be> <1190582634.4349.22.camel@dev64.localdomain> <18171.48522.435225.984210@cerise.gclements.plus.com> <1190955520.4349.245.camel@dev64.localdomain> <18172.49308.435792.213235@cerise.gclements.plus.com> Message-ID: <20071001230848.2009cb43.hamish_nospam@yahoo.com> Glynn Clements wrote: > > [Actually, I'm not sure that PostgreSQL really belongs on that list. > When we adopted a policy of generating fatal errors if important > dependencies were missing, PostgreSQL was the only supported database, > and it resulted in a bunch of additional pg.* modules as well as > adding PostgreSQL support to NVIZ. > > Now that other databases can be used, and the option only affects > compilation of the actual database driver, it could probably be turned > off by default. OTOH, maybe that should wait for 7.x.] my vote is for setting the default to --without-postgres now (6.3+). Hamish From hamish_nospam at yahoo.com Mon Oct 1 12:33:23 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 1 12:33:28 2007 Subject: [GRASS-dev] Installing GRASS on cygwin In-Reply-To: <01c801c80140$1a691c50$3e40ae80@ace.uiuc.edu> References: <01c801c80140$1a691c50$3e40ae80@ace.uiuc.edu> Message-ID: <20071001233323.4a150990.hamish_nospam@yahoo.com> > I'm having issues installing GRASS on cygwin running on Windows. > I execute the configure script below successfully and with no errors. > > CFLAGS="-g -Wall" ./configure --with-includes=c:/msys/local/include \ > --with-libs=c:/msys/local/lib --with-python > --with-proj-share=/usr/share/proj > But when I run make, it hangs when it enters the d.ask command: > > make[2]: Entering directory `/c/GRASS/grass-6.2.2/display/d.ask' > GISRC=/c/GRASS/grass-6.2.2/dist.i686-pc-cygwin/demolocation/.grassrc62 > GISBASE=/c/GRASS/grass-6.2.2/dist.i686-pc-cygwin > PATH=/c/GRASS/grass-6.2.2/dist.i686-pc-cygwin/bin:$PATH > PATH="/c/GRASS/grass-6.2.2/dist.i686-pc-cygwin/lib:./:/usr/local/grass-6.2.2 > /bin_extra:/usr/local/gr > ass-6.2.2/bin_tcl:/usr/local/bin:/usr/bin:/b > in:/usr/X11R6/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c > /Pro > gram Files/ATI Technologies/ATI Control Panel:/c/Program > Files/Reflection:/c/arcgis/arcexe9x/bin:/c/PROGRA~1/COMMON~1/DHI/MikeZero:/c > /Program > Files/GnuWin32/bin:/usr/local/gmt/bin:/c/Program Files/Common > Files/DHI/MIKEZero:/c/Program Files/QuickTime/QTSystem/:/c/Program > Files/Attachmate/Reflection/:/usr/local/bin:/usr/X11R6/bin:/usr/bin:/c/Progr > am > Files/wgrib" LC_ALL=C /c/GRASS/grass-6.2.2/dist.i686-pc-cygwin/bin/d.ask > --html-description | grep -v '\|' > d.ask.tmp.html ; true d.ask is a rarely used module which you will almost surely be able to live without. I suggest you remove it from display/Makefile and try again. It will be removed for GRASS 7 as it is incompatible with the new GUIs. Hamish From neteler at itc.it Mon Oct 1 15:07:46 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Oct 1 15:07:48 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: <20071001185716.6862a47c.hamish_nospam@yahoo.com> References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> <20071001185716.6862a47c.hamish_nospam@yahoo.com> Message-ID: <4700F122.4020804@itc.it> Hamish wrote on 10/01/2007 07:57 AM: > Hamish wrote: > >> over the weekend there were 56 new spambot accounts opened in the wiki. >> I am now working through the wiki's web interface to ban these one by >> one, but it is a big drain of time which I would much prefer to spend >> on more productive tasks. the sooner we get this situation fixed the >> better. >> > > oops I counted wrong, make that 68 new accounts to ban. > > Some news: * Martin and me have updated Mediawiki to 1.6.10-SVN. * I have removed all above mentioned bad users from the DB (they all subscribe from the *same* email address for verification - how to block that?). * I have added that if "User-Agent" is empty, the user will be rejected (let me know if you have problems with that). * Bonus: thumbnail creation now works :) using something like [[Image:wxgrass-gis-manager-layer.png|350px]] Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From kwythers at umn.edu Mon Oct 1 15:36:30 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Mon Oct 1 15:36:36 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: References: Message-ID: <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> On Sep 30, 2007, at 11:23 PM, Michael Barton wrote: > Well, after asking for help, I figured out how to this without the > dread > regexp ;-). This might even be a bit better routine. > > Anyway, I can't commit this because I'm out of town, but if anyone > wants to > try it, you need to change lines in procedure GmAnim::main (module > animate.tcl). Replace the commented lines with the uncommented > lines below. > > foreach line $reglist { > set line [string trim $line] > set key [lindex [split $line "="] 0] > switch $key { > nsres {set oldres1 [lindex [split $line "="] 1]} > ewres {set oldres2 [lindex [split $line "="] 1]} > rows {set vrows [lindex [split $line "="] 1]} > cols {set vcols [lindex [split $line "="] 1]} > } > > } > > # regexp {nsres= *([0-9]+)} $region dummy oldres1 > # regexp {ewres= *([0-9]+)} $region dummy oldres2 > # regexp {rows= *([0-9]+)} $region dummy vrows > # regexp {cols= *([0-9]+)} $region dummy vcols > > Michael, Thanks for the email. I made the following changes but ended up with a new error. I might have altered the wrong file. Here is what I tried. From the file ~/src_intel/grass-6.3.cvs/gui/tcltk/gis.m/animate.tcl # set initial canvas geometry to match region if {[catch {set region [exec g.region -ugp]} error]} { Gm::errmsg $error } # regexp {nsres= *([0-9]+)} $region dummy oldres1 # regexp {ewres= *([0-9]+)} $region dummy oldres2 # regexp {rows= *([0-9]+)} $region dummy vrows # regexp {cols= *([0-9]+)} $region dummy vcols foreach line $reglist { set line [string trim $line] set key [lindex [split $line "="] 0] switch $key { nsres {set oldres1 [lindex [split $line "="] 1]} ewres {set oldres2 [lindex [split $line "="] 1]} rows {set vrows [lindex [split $line "="] 1]} cols {set vcols [lindex [split $line "="] 1]} } } New error when startring up GmAnim. can't read "reglist": no such variable can't read "reglist": no such variable while executing "foreach line $reglist { set line [string trim $line] set key [lindex [split $line "="] 0] switch $key { nsres {..." (procedure "GmAnim::main" line 28) invoked from within "GmAnim::main" ("uplevel" body line 1) invoked from within "uplevel \#0 $cmd" (procedure "Button::_release" line 18) invoked from within "Button::_release .mainframe.topf.tb1.bbox4.b0" (command bound to event) Perhaps this is not what you intended? Kirk From glynn at gclements.plus.com Mon Oct 1 18:15:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 1 18:15:55 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> References: <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> Message-ID: <18177.7477.99729.375043@cerise.gclements.plus.com> Kirk Wythers wrote: > > On Sep 30, 2007, at 11:23 PM, Michael Barton wrote: > > > Well, after asking for help, I figured out how to this without the > > dread > > regexp ;-). This might even be a bit better routine. > > > > Anyway, I can't commit this because I'm out of town, but if anyone > > wants to > > try it, you need to change lines in procedure GmAnim::main (module > > animate.tcl). Replace the commented lines with the uncommented > > lines below. > > > > foreach line $reglist { > > set line [string trim $line] > > set key [lindex [split $line "="] 0] > > switch $key { > > nsres {set oldres1 [lindex [split $line "="] 1]} > > ewres {set oldres2 [lindex [split $line "="] 1]} > > rows {set vrows [lindex [split $line "="] 1]} > > cols {set vcols [lindex [split $line "="] 1]} > > } > > > > } > > > > # regexp {nsres= *([0-9]+)} $region dummy oldres1 > > # regexp {ewres= *([0-9]+)} $region dummy oldres2 > > # regexp {rows= *([0-9]+)} $region dummy vrows > > # regexp {cols= *([0-9]+)} $region dummy vcols > > > > > > Michael, > > Thanks for the email. I made the following changes but ended up with > a new error. Add: set reglist [split $region "\n"] -- Glynn Clements From Agustin.Diez at uv.es Mon Oct 1 18:36:05 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Mon Oct 1 18:39:59 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: <18177.7477.99729.375043@cerise.gclements.plus.com> References: <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> <18177.7477.99729.375043@cerise.gclements.plus.com> Message-ID: d.m.html not found, but no problem when make is done in /Users/Shared/ grasssource/grass6/gui/tcltk/d.m Model Name: iMac Model Identifier: iMac5,1 Processor Name: Intel Core 2 Duo Processor Speed: 2 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache (per processor): 4 MB Memory: 2 GB Bus Speed: 667 MHz Boot ROM Version: IM51.0090.B09 SMC Version: 1.8f2 /usr/bin/install -c $tcl /Users/Shared/grasssource/grass6/ dist.i686-apple-darwin8.10.1/etc/dm/ ; \ done chmod 755 /Users/Shared/grasssource/grass6/dist.i686-apple- darwin8.10.1/etc/dm/tksys.tcl /usr/bin/install -c -m 755 d.m.tcl /Users/Shared/grasssource/grass6/ dist.i686-apple-darwin8.10.1/etc/dm/d.m.tcl mkdir -p /Users/Shared/grasssource/grass6/dist.i686-apple- darwin8.10.1/etc/dm/script /usr/bin/install -c -m 755 script/*.* /Users/Shared/grasssource/ grass6/dist.i686-apple-darwin8.10.1/etc/dm/script make[3]: *** No rule to make target `/Users/Shared/grasssource/grass6/ dist.i686-apple-darwin8.10.1/docs/html/d.m.html', needed by `html'. Stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071001/03cc9d96/attachment-0001.html From kwythers at umn.edu Mon Oct 1 19:35:19 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Mon Oct 1 19:35:25 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: <18177.7477.99729.375043@cerise.gclements.plus.com> References: <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> <18177.7477.99729.375043@cerise.gclements.plus.com> Message-ID: <3D3A89AF-9479-4639-807D-98FFE5D71374@umn.edu> On Oct 1, 2007, at 11:15 AM, Glynn Clements wrote: > > Kirk Wythers wrote: > >> >> On Sep 30, 2007, at 11:23 PM, Michael Barton wrote: >> >>> Well, after asking for help, I figured out how to this without the >>> dread >>> regexp ;-). This might even be a bit better routine. >>> >>> Anyway, I can't commit this because I'm out of town, but if anyone >>> wants to >>> try it, you need to change lines in procedure GmAnim::main (module >>> animate.tcl). Replace the commented lines with the uncommented >>> lines below. >>> >>> foreach line $reglist { >>> set line [string trim $line] >>> set key [lindex [split $line "="] 0] >>> switch $key { >>> nsres {set oldres1 [lindex [split $line "="] 1]} >>> ewres {set oldres2 [lindex [split $line "="] 1]} >>> rows {set vrows [lindex [split $line "="] 1]} >>> cols {set vcols [lindex [split $line "="] 1]} >>> } >>> >>> } >>> >>> # regexp {nsres= *([0-9]+)} $region dummy oldres1 >>> # regexp {ewres= *([0-9]+)} $region dummy oldres2 >>> # regexp {rows= *([0-9]+)} $region dummy vrows >>> # regexp {cols= *([0-9]+)} $region dummy vcols > > Add: > set reglist [split $region "\n"] In the foreach loop, like this? foreach line $reglist { set reglist [split $region "\n"] set line [string trim $line] set key [lindex [split $line "="] 0] switch $key { nsres {set oldres1 [lindex [split $line "="] 1]} ewres {set oldres2 [lindex [split $line "="] 1]} rows {set vrows [lindex [split $line "="] 1]} cols {set vcols [lindex [split $line "="] 1]} } } > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Mon Oct 1 20:20:30 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 1 20:20:37 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: <3D3A89AF-9479-4639-807D-98FFE5D71374@umn.edu> References: <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> <18177.7477.99729.375043@cerise.gclements.plus.com> <3D3A89AF-9479-4639-807D-98FFE5D71374@umn.edu> Message-ID: <18177.14958.860777.186515@cerise.gclements.plus.com> Kirk Wythers wrote: > >>> Well, after asking for help, I figured out how to this without the > >>> dread > >>> regexp ;-). This might even be a bit better routine. > >>> > >>> Anyway, I can't commit this because I'm out of town, but if anyone > >>> wants to > >>> try it, you need to change lines in procedure GmAnim::main (module > >>> animate.tcl). Replace the commented lines with the uncommented > >>> lines below. > >>> > >>> foreach line $reglist { > >>> set line [string trim $line] > >>> set key [lindex [split $line "="] 0] > >>> switch $key { > >>> nsres {set oldres1 [lindex [split $line "="] 1]} > >>> ewres {set oldres2 [lindex [split $line "="] 1]} > >>> rows {set vrows [lindex [split $line "="] 1]} > >>> cols {set vcols [lindex [split $line "="] 1]} > >>> } > >>> > >>> } > >>> > >>> # regexp {nsres= *([0-9]+)} $region dummy oldres1 > >>> # regexp {ewres= *([0-9]+)} $region dummy oldres2 > >>> # regexp {rows= *([0-9]+)} $region dummy vrows > >>> # regexp {cols= *([0-9]+)} $region dummy vcols > > > > > Add: > > set reglist [split $region "\n"] > > In the foreach loop, like this? > > foreach line $reglist { > set reglist [split $region "\n"] No, before it: set reglist [split $region "\n"] foreach line $reglist { ... Or just omit the variable altogether: foreach line [split $region "\n"] { ... -- Glynn Clements From stephan.holl at intevation.de Mon Oct 1 20:21:42 2007 From: stephan.holl at intevation.de (Stephan Holl) Date: Mon Oct 1 20:21:51 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <86782b610709281145y28f0d0a4y9249d2e854dcca07@mail.gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <200709271037.37523.jan-oliver.wagner@intevation.de> <46FB830C.9030004@itc.it> <200709272037.31555.jan-oliver.wagner@intevation.de> <46FCEE62.2020306@itc.it> <46FD4586.3030807@o2.pl> <86782b610709281145y28f0d0a4y9249d2e854dcca07@mail.gmail.com> Message-ID: <20071001202142.2db41aca@intevation.de> Hello Markus, "Markus Neteler" , [20070928-20:45:42]: > On 9/28/07, Maciej Sieczka wrote: > > Markus Neteler wrote: > > > Jan-Oliver Wagner wrote on 09/27/2007 08:37 PM: > > > > >> one of the Admins of the GForge grass project can switch on > > >> other modules, among them SCM (Source Code Management, == SVN), > > >> a wiki (I don't like this implementation) and other stuff. > > > > > Currently I don't know who is admin (AFAIK Maciej, anyone else?). > > > > Yes, bernhard is backing me up :) [1]. If you want me to > > turn something on or enable admin rights for a certain > > GForge GRASS member drop me a line. I haven't investigated > > GForge capabilities in regard to SVN server (and I > > completely don't know if it's able to integrate with the > > tracker) but I mentioned it [2]. > > > > [1]http://grass.gdf-hannover.de/wiki/Tracking#How_it_works > > [2]http://grass.gdf-hannover.de/wiki/Tracking#GForge:_beyond_the_trackers > > Perhaps features could be linked with examples to the Wiki page: > http://grass.gdf-hannover.de/wiki/SVN_hosting > ? > > Stephan Holl had added > "* GForge includes different SCMs, like CVS, SVN, Mercurial, ..." > but I don't know how it looks like. Example URLs welcome. Is it that what you want? Browse arround and see the integration of viewCVS/SVN into geforge. This is currently not enabled for GRASS IIRC. Best Stephan -- Stephan Holl , http://intevation.de/~stephan Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabr?ck - HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From glynn at gclements.plus.com Mon Oct 1 20:38:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 1 20:38:16 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: References: Message-ID: <18177.16022.290809.107029@cerise.gclements.plus.com> Agustin Diez Castillo wrote: > d.m.html not found, but no problem when make is done in > /Users/Shared/grasssource/grass6/gui/tcltk/d.m Can you please try the following: 1. Delete the files: dist.i686-apple-darwin8.10.1/docs/html/d.m.html dist.i686-apple-darwin8.10.1/scripts/d.m gui/tcltk/d.m/d.m.tmp.html 2. Run "make -C gui/tcltk/d.m" 3. Report any errors, and whether any of the files mentioned in #1 above exist. 4. Repeat steps 2 and 3. This problem only occurs on certain systems (possibly depending upon the version of "make"). I can't reproduce it here. Also, it has only been reported with regard to d.m and gis.m, although exactly the same rules are used for other scripts. -- Glynn Clements From wichmann at laserdata.at Mon Oct 1 21:08:55 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Mon Oct 1 21:08:17 2007 Subject: [GRASS-dev] porting sites format to new vector Message-ID: <470145C7.8040902@laserdata.at> Hi, I'd like to know if there is some kind of 'how-to' about porting a module that is using the obsolete vector sites format to the latest vector architecture? I've been searching the web but couldn't find anything like that. Thanks, Volker From Agustin.Diez at uv.es Mon Oct 1 21:07:06 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Mon Oct 1 21:11:02 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: <18177.16022.290809.107029@cerise.gclements.plus.com> References: <18177.16022.290809.107029@cerise.gclements.plus.com> Message-ID: <16A3A4B9-D546-4CE4-99B6-8A3C4A19008B@uv.es> On Oct 1, 2007, at 8:38 PM, Glynn Clements wrote: > > Can you please try the following: > > 1. Delete the files: > > dist.i686-apple-darwin8.10.1/docs/html/d.m.html it does exist > dist.i686-apple-darwin8.10.1/scripts/d.m it does exist > gui/tcltk/d.m/d.m.tmp.html it doesn't exist > > 2. Run "make -C gui/tcltk/d.m" > > 3. Report any errors, and whether any of the files mentioned in #1 > above exist. No errors make -C gui/tcltk/d.m if [ ! -d /Users/Shared/grasssource/grass6/dist.i686-apple- darwin8.10.1/scripts ]; then mkdir -p /Users/Shared/grasssource/ grass6/dist.i686-apple-darwin8.10.1/scripts; fi /usr/bin/install -c d.m /Users/Shared/grasssource/grass6/dist.i686- apple-darwin8.10.1/scripts/d.m GISRC=/Users/Shared/grasssource/grass6/dist.i686-apple-darwin8.10.1/ demolocation/.grassrc63 GISBASE=/Users/Shared/grasssource/grass6/ dist.i686-apple-darwin8.10.1 PATH="/Users/Shared/grasssource/grass6/ dist.i686-apple-darwin8.10.1/bin:$PATH" DYLD_LIBRARY_PATH="/Users/ Shared/grasssource/grass6/dist.i686-apple-darwin8.10.1/bin:/Users/ Shared/grasssource/grass6/dist.i686-apple-darwin8.10.1/lib:" LC_ALL=C /Users/Shared/grasssource/grass6/dist.i686-apple- darwin8.10.1/scripts/d.m --html-description < /dev/null | grep -v '\|' > d.m.tmp.html ; true ../../../tools/mkhtml.sh d.m ; mkdir -p /Users/Shared/grasssource/ grass6/dist.i686-apple-darwin8.10.1/docs/html ; /usr/bin/install -c - m 644 d.m.tmp.html /Users/Shared/grasssource/grass6/dist.i686-apple- darwin8.10.1/docs/html/d.m.html ; for file in *.png *.jpg ; do head - n 1 $file | grep '^#!' > /dev/null ; if [ $? -ne 0 ] ; then /usr/bin/ install -c -m 644 $file /Users/Shared/grasssource/grass6/dist.i686- apple-darwin8.10.1/docs/html ; fi done 2> /dev/null ; true rm d.m.tmp.html > > 4. Repeat steps 2 and 3. No problem the second time > > This problem only occurs on certain systems (possibly depending upon > the version of "make"). I can't reproduce it here. Also, it has only > been reported with regard to d.m and gis.m, although exactly the same > rules are used for other scripts. > This has been the first and only time it occurs. I did "make distclean" before ./configure -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071001/b1314e37/attachment.html From landa.martin at gmail.com Mon Oct 1 21:14:42 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Oct 1 21:14:47 2007 Subject: [GRASS-dev] porting sites format to new vector In-Reply-To: <470145C7.8040902@laserdata.at> References: <470145C7.8040902@laserdata.at> Message-ID: Hi, not sure if such kind of 'how-to' exists, anyway some time ago I updated v.hull to get rid of sites.h [1] Martin [1] http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.hull/main.c.diff?r1=1.10&r2=1.11 2007/10/1, Volker Wichmann : > Hi, > > I'd like to know if there is some kind of 'how-to' about porting a > module that is using the obsolete vector sites format to the latest > vector architecture? I've been searching the web but couldn't find > anything like that. > > Thanks, > Volker > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From jan-oliver.wagner at intevation.de Mon Oct 1 22:09:33 2007 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon Oct 1 22:13:19 2007 Subject: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <12953139.post@talk.nabble.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> Message-ID: <200710012209.36561.jan-oliver.wagner@intevation.de> On Saturday 29 September 2007 09:58, Markus Neteler wrote: > Jan-Oliver Wagner-2 wrote: > > On Friday 28 September 2007 14:06, Markus Neteler wrote: > >> Jan-Oliver Wagner wrote on 09/27/2007 08:37 PM: > >> > one of the Admins of the GForge grass project can switch on other > >> > modules, among them SCM (Source Code Management, == SVN), a wiki (I > >> > >> don't > >> > >> > like this implementation) and other stuff. > >> > >> Currently I don't know who is admin (AFAIK Maciej, anyone else?). > >> I have no list of available modules (this is what I am asking for...). > > > > see top right box of http://wald.intevation.org/projects/grass > > Not sure what to see there... the names of the project admins and developers. The project admins is what you were looking for. > Jan-Oliver Wagner-2 wrote: > >> Ah, this means that there is a link between SVN and GForge? To visualize > >> patches and such? I am honestly asking since I don't know (and cannot > >> spend more time on searching around). > > > > E.g. look at http://wald.intevation.org/scm/?group_id=27 > > which is the SVN for deegree project. > > Click on browse and you enter viewcvs 1.0. Welcome home ;-) > > OK, fine (not enabled for GRASS apparently). up to project admins to do so. > Jan-Oliver Wagner-2 wrote: > >> Jan, for several *months* we try to complete the list to make a > >> *reasonable* comparison. Again: concrete input is welcome. You as GForge > >> developer will know much more; we (a set of GRASS developers) are > >> lacking this knowledge. > > > > I am not a GForge developer. I am a GForge *user*. And a Sourceforge > > user. And a user of Savannah and of trac. ;-) > > BTW, GForge is a Sourceforge fork. > > > > Doing a comparison of such platforms is far beyond scope I guess. > > Perhaps it is better to collect some needs of the developers and > > simply select a platform that suits them? I guess that at the end of the > > day > > any platform will do the job good enough of managing SVN. > > Not entirely sure if any platform will do the job good enough. We clearly > see > that GForge for GRASS is way under-used. I guess you mean the bug tracker is underused? -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From neteler at itc.it Mon Oct 1 22:25:03 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Oct 1 22:25:05 2007 Subject: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <200710012209.36561.jan-oliver.wagner@intevation.de> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> Message-ID: <20071001202503.GD17023@bartok.itc.it> On Mon, Oct 01, 2007 at 10:09:33PM +0200, Jan-Oliver Wagner wrote: > On Saturday 29 September 2007 09:58, Markus Neteler wrote: > > Jan-Oliver Wagner-2 wrote: > > > On Friday 28 September 2007 14:06, Markus Neteler wrote: > > >> Jan-Oliver Wagner wrote on 09/27/2007 08:37 PM: > > >> > one of the Admins of the GForge grass project can switch on other > > >> > modules, among them SCM (Source Code Management, == SVN), a wiki (I > > >> > don't like this implementation) and other stuff. Don't you like the GForge Wiki or Wiki in general? > > >> Currently I don't know who is admin (AFAIK Maciej, anyone else?). > > >> I have no list of available modules (this is what I am asking for...). > > > > > > see top right box of http://wald.intevation.org/projects/grass > > > > Not sure what to see there... > > the names of the project admins and developers. > The project admins is what you were looking for. Yes, right: Bernhard Reiter Maciej Sieczka > > Jan-Oliver Wagner-2 wrote: > > >> Ah, this means that there is a link between SVN and GForge? To visualize > > >> patches and such? I am honestly asking since I don't know (and cannot > > >> spend more time on searching around). > > > > > > E.g. look at http://wald.intevation.org/scm/?group_id=27 > > > which is the SVN for deegree project. > > > Click on browse and you enter viewcvs 1.0. Welcome home ;-) > > > > OK, fine (not enabled for GRASS apparently). > > up to project admins to do so. OK - I am none, so I cannot do anything. > > Jan-Oliver Wagner-2 wrote: > > > Markus Neteler wrote: > > > > Jan, for several *months* we try to complete the list to make a > > > > *reasonable* comparison. Again: concrete input is welcome. You as GForge > > > > developer will know much more; we (a set of GRASS developers) are > > > > lacking this knowledge. > > > > > > I am not a GForge developer. I am a GForge *user*. And a Sourceforge > > > user. And a user of Savannah and of trac. ;-) > > > BTW, GForge is a Sourceforge fork. > > > > > > Doing a comparison of such platforms is far beyond scope I guess. > > > Perhaps it is better to collect some needs of the developers and > > > simply select a platform that suits them? I guess that at the end of the > > > day > > > any platform will do the job good enough of managing SVN. > > > > Not entirely sure if any platform will do the job good enough. We clearly > > see that GForge for GRASS is way under-used. > > I guess you mean the bug tracker is underused? Yes. Numerous active developers are not even registered there (see 'Developers:' on the page mentioned above). Additionally, there are several useful features either missing in GForge or not activated (I cannot judge that since still I don't know what's available and possible). But I feel that we start to go in circles. Markus > -- > Dr. Jan-Oliver Wagner Intevation GmbH > Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From woklist at kyngchaos.com Mon Oct 1 22:53:48 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Oct 1 22:54:31 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: <16A3A4B9-D546-4CE4-99B6-8A3C4A19008B@uv.es> References: <18177.16022.290809.107029@cerise.gclements.plus.com> <16A3A4B9-D546-4CE4-99B6-8A3C4A19008B@uv.es> Message-ID: <6C7E7036-0562-499D-A2F1-49ECD9DCCBE3@kyngchaos.com> Same problem here. After distclean, I get the no target error. dist/ scripts/d.m is created, but not dist/docs/html/d.m.html. Immediately running make -C gui/tcltk/d.m again succeeds and installs d.m.html. make clean, then make - back to the error. PS. Augustin, I found and fixed a macosx build problem (a couple hours ago) from Glynn's parallel build updates. You should do a cvs update or you won't get a OSX app. On Oct 1, 2007, at 2:07 PM, Agustin Diez Castillo wrote: > On Oct 1, 2007, at 8:38 PM, Glynn Clements wrote: > >> Can you please try the following: >> >> 1. Delete the files: >> >> dist.i686-apple-darwin8.10.1/docs/html/d.m.html > it does exist >> dist.i686-apple-darwin8.10.1/scripts/d.m > it does exist >> gui/tcltk/d.m/d.m.tmp.html > it doesn't exist >> >> 2. Run "make -C gui/tcltk/d.m" >> >> 3. Report any errors, and whether any of the files mentioned in #1 >> above exist. ----- 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 From jan-oliver.wagner at intevation.de Mon Oct 1 22:58:37 2007 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon Oct 1 23:02:22 2007 Subject: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <20071001202503.GD17023@bartok.itc.it> References: <20070914114723.GD14995@bartok.itc.it> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071001202503.GD17023@bartok.itc.it> Message-ID: <200710012258.41258.jan-oliver.wagner@intevation.de> On Monday 01 October 2007 22:25, Markus Neteler wrote: > Don't you like the GForge Wiki or Wiki in general? I like wikis. I used a lot of various implementations. The only ones I started to like are MoinMoin and MediaWiki. Neither is supported by GForge. IIRC, there is phpwiki available. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From woklist at kyngchaos.com Mon Oct 1 23:04:03 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Oct 1 23:04:46 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) Message-ID: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> Make now ALWAYS recompiles everything. I'm guessing it has something to do with the recent parallel build/recompile changes. My last cvs update was a week ago, and it was normal (a few would recompile regardless of the need, but not everything). ie, from a distclean and configure: make -> all GRASS is compiled change a source file or makefile - or not, doesn't matter make -> all recompiled ----- 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 From rez at touchofmadness.com Tue Oct 2 00:57:04 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Oct 2 00:57:25 2007 Subject: [GRASS-dev] porting sites format to new vector In-Reply-To: <470145C7.8040902@laserdata.at> References: <470145C7.8040902@laserdata.at> Message-ID: <1191279424.3194.136.camel@dev64.localdomain> On Mon, 2007-10-01 at 21:08 +0200, Volker Wichmann wrote: > Hi, > > I'd like to know if there is some kind of 'how-to' about porting a > module that is using the obsolete vector sites format to the latest > vector architecture? I've been searching the web but couldn't find > anything like that. Not AFAIK. lib/sites/README offers little info, but lib/sites/sites.c is useful to see how wrapper functions work. It may be helpful to compare a module that was once based on sites that has been converted to the vector library (s.surf.idw from grass54 and v.surf.idw from current). If you do end up converting a module, adding tips to the wiki for others would be great. ;-) -- 73, de Brad KB8UYR/6 From grass-dev at grass.itc.it Tue Oct 2 04:21:38 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Tue Oct 2 04:12:46 2007 Subject: [GRASS-dev] [grass-code I][496] v.proj overwrites even if --o wasn't given Message-ID: <20071002022138.1EC8E40328@pyrosoma.intevation.org> code I item #496, was opened at 2007-10-02 14:21 Status: Open Priority: 3 Submitted By: Hamish Bowman (hamish) Assigned to: Nobody (None) Summary: v.proj overwrites even if --o wasn't given Issue type: module bad feature Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: Linux Operating system version: debian/etch GRASS CVS checkout date, if applies (YYMMDD): 070901 Initial Comment: v.proj skips checking for the --overwrite flag, it overwrites regardless after issuing a WARNING: that the map exists and will be overwritten. It should follow normal module conventions and not do that unless --o or GRASS_OVERWRITE=x was set. My test used just an input map name, ie the output map name was taken from the input name and not given on the command line for the parser to test. r.proj probably needs checking too, it may do the same. thanks, Hamish ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=496&group_id=21 From michael.barton at asu.edu Tue Oct 2 04:17:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Oct 2 04:17:58 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> Message-ID: Kirk, You seem to be missing a line (maybe my fault). Note the line defining reglist. Michael ===================================== set reglist [split $region "\n"] foreach line $reglist { set line [string trim $line] set key [lindex [split $line "="] 0] switch $key { nsres {set oldres1 [lindex [split $line "="] 1]} ewres {set oldres2 [lindex [split $line "="] 1]} rows {set vrows [lindex [split $line "="] 1]} cols {set vcols [lindex [split $line "="] 1]} } } On 10/1/07 6:36 AM, "Kirk Wythers" wrote: > > On Sep 30, 2007, at 11:23 PM, Michael Barton wrote: > >> Well, after asking for help, I figured out how to this without the >> dread >> regexp ;-). This might even be a bit better routine. >> >> Anyway, I can't commit this because I'm out of town, but if anyone >> wants to >> try it, you need to change lines in procedure GmAnim::main (module >> animate.tcl). Replace the commented lines with the uncommented >> lines below. >> >> foreach line $reglist { >> set line [string trim $line] >> set key [lindex [split $line "="] 0] >> switch $key { >> nsres {set oldres1 [lindex [split $line "="] 1]} >> ewres {set oldres2 [lindex [split $line "="] 1]} >> rows {set vrows [lindex [split $line "="] 1]} >> cols {set vcols [lindex [split $line "="] 1]} >> } >> >> } >> >> # regexp {nsres= *([0-9]+)} $region dummy oldres1 >> # regexp {ewres= *([0-9]+)} $region dummy oldres2 >> # regexp {rows= *([0-9]+)} $region dummy vrows >> # regexp {cols= *([0-9]+)} $region dummy vcols >> >> > > Michael, > > Thanks for the email. I made the following changes but ended up with > a new error. I might have altered the wrong file. Here is what I tried. > > From the file ~/src_intel/grass-6.3.cvs/gui/tcltk/gis.m/animate.tcl > > # set initial canvas geometry to match region > if {[catch {set region [exec g.region -ugp]} error]} { > Gm::errmsg $error > } > > # regexp {nsres= *([0-9]+)} $region dummy oldres1 > # regexp {ewres= *([0-9]+)} $region dummy oldres2 > # regexp {rows= *([0-9]+)} $region dummy vrows > # regexp {cols= *([0-9]+)} $region dummy vcols > > foreach line $reglist { > set line [string trim $line] > set key [lindex [split $line "="] 0] > switch $key { > nsres {set oldres1 [lindex [split $line "="] 1]} > ewres {set oldres2 [lindex [split $line "="] 1]} > rows {set vrows [lindex [split $line "="] 1]} > cols {set vcols [lindex [split $line "="] 1]} > } > > } > > New error when startring up GmAnim. > > can't read "reglist": no such variable > can't read "reglist": no such variable > while executing > "foreach line $reglist { > set line [string trim $line] > set key [lindex [split $line "="] 0] > switch $key { > nsres {..." > (procedure "GmAnim::main" line 28) > invoked from within > "GmAnim::main" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 18) > invoked from within > "Button::_release .mainframe.topf.tb1.bbox4.b0" > (command bound to event) > > Perhaps this is not what you intended? > > Kirk > > > > > __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Oct 2 05:14:50 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Oct 2 05:14:55 2007 Subject: [GRASS-dev] [grass-code I][495] gis.m output window buttons don't fit text width In-Reply-To: <4700059F.80803@jemila.jazztel.es> Message-ID: Carlos, May I suggest that "run (background)" might be better translated as "ejecutar (fondo)" than "ejecutar (segundo plan)" This should fit OK. Michael On 9/30/07 1:22 PM, "Carlos D?vila" wrote: > Michael Barton escribi?: >> Carlos, >> >> Which buttons? Can you send a screenshot? >> > You can see it here: > http://wald.intevation.org/tracker/download.php/21/204/495/232/Salida%20-%20GI > S.m.png >> Michael >> >> NB: It would be nice if the the difficulty of replying to Carlos in this >> message could be reduced (i.e., not having to manually look up his email and >> paste it in to my reply) >> >> >> On 9/30/07 6:13 AM, "grass-dev@grass.itc.it" wrote: >> >> >>> code I item #495, was opened at 2007-09-30 15:13 >>> Status: Open >>> Priority: 3 >>> Submitted By: Carlos D?vila (carluti) >>> Assigned to: Nobody (None) >>> Summary: gis.m output window buttons don't fit text width >>> Issue type: module bad feature >>> Issue status: None >>> GRASS version: CVS HEAD >>> GRASS component: gis.m >>> Operating system: Linux >>> Operating system version: debian testing >>> GRASS CVS checkout date, if applies (YYMMDD): >>> >>> >>> Initial Comment: >>> Translated text within some buttons is larger than default width and text is >>> cut, even if you enlarge the window. >>> >>> ---------------------------------------------------------------------- >>> >>> You can respond by visiting: >>> http://wald.intevation.org/tracker/?func=detail&atid=204&aid=495&group_id=21 >>> >>> >>> >> >> __________________________________________ >> 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-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> >> > > __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Oct 2 05:23:16 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Oct 2 05:23:23 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: <6C7E7036-0562-499D-A2F1-49ECD9DCCBE3@kyngchaos.com> Message-ID: I've had this problem for ages. I just cd to the d.m directory and type make. Then all is well. A bit annoying, but not a problem. I probably shouldn't even bother with this. Michael On 10/1/07 1:53 PM, "William Kyngesburye" wrote: > Same problem here. After distclean, I get the no target error. dist/ > scripts/d.m is created, but not dist/docs/html/d.m.html. Immediately > running make -C gui/tcltk/d.m again succeeds and installs d.m.html. > > make clean, then make - back to the error. > > PS. Augustin, I found and fixed a macosx build problem (a couple > hours ago) from Glynn's parallel build updates. You should do a cvs > update or you won't get a OSX app. > > > On Oct 1, 2007, at 2:07 PM, Agustin Diez Castillo wrote: > >> On Oct 1, 2007, at 8:38 PM, Glynn Clements wrote: >> >>> Can you please try the following: >>> >>> 1. Delete the files: >>> >>> dist.i686-apple-darwin8.10.1/docs/html/d.m.html >> it does exist >>> dist.i686-apple-darwin8.10.1/scripts/d.m >> it does exist >>> gui/tcltk/d.m/d.m.tmp.html >> it doesn't exist >>> >>> 2. Run "make -C gui/tcltk/d.m" >>> >>> 3. Report any errors, and whether any of the files mentioned in #1 >>> above exist. > > ----- > 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 > > > __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Oct 2 08:57:28 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Oct 2 08:57:36 2007 Subject: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <200710012209.36561.jan-oliver.wagner@intevation.de> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> Message-ID: <20071002195728.31b45442.hamish_nospam@yahoo.com> [combining some posts here] Jan: > sorry for the late coment. I am catching up the list only in certain > intervals and usually can not react immediately unless put in cc > or notified else. Ok. I hope you saw all the comments from a number of us about how happy we have been with the CVS and other support from Intevation. That is probably the number one reason we have not moved to OSGeo's servers a year ago and why this discussion continues on and on. > this list apparenly is driven by the wish to go to osgeo. I would say there is some general wish to have closer ties with OSGeo than we have now. There is no reason to move away from Intevation, just a slight reason to put something at OSGeo. In that case, all other things being neutral, and having to do a cvs2svn port anyway, a move to OSGeo has had some support. (my personal view is that I'd be happy with either place) Markus: > > We clearly see that GForge for GRASS is way under-used. Jan-Oliver Wagner: > I guess you mean the bug tracker is underused? yes. (AFAIK that's all we have turned on) I think it is best to solidly decide which support software we want to use. Once we have clearly decided that we just push hard to get it ;) Right now we seem to be deciding what to use (& where) based on what is already installed, which seems backwards. What support software to use seems to be a totally separate issue from where to host things, as Intevation seems to be happy to provide what we ask for as best they can, and I guess (but don't know) that the OSGeo admins would be supportive too. For me, getting the support service software "right" is much more important than looking like a good OSGeo team member or keeping *everything* on the same server in some unified content management system. But of course we should encourage tie-ins with OSGeo as best we can, I don't mean to say we shouldn't do that as much as possible, just not at the expense of choking the good infrastructure we have now. For my 2c, I like: * current web server setup seems ok (including rsync mirrors and CVS) * current wiki software (MediaWiki) (we can fix the current spam issue) * move to SVN for source code management (actually, for me anyway, I don't have any problems with CVS) * Same ViewCVS setup as we have now, but interfaced to SVN: e.g. http://josef.fsv.cvut.cz/cgi-bin/viewcvs.cgi/?root=grass7svn * .... bug tracker .... what was wrong with the old one again? The two really annoying things with Gforge bug tracker to me is the top posting of comments and that you can't cc it in posts to the grass-dev mailing list, you have to use the web form, duplicating effort and killing casual contributions. I don't like to think that we are defeated in what we want to do based on spammers. I don't see a huge need to move Everything into "the" OSGeo framework with a OSGeo "look" to it. On the same lines I don't see a huge need to combine all web/wiki/SCM/bugs under a single Trac or Gforge master. (I accept Frank's word that the SVN tie-in will be rewarding, but haven't seen that clearly yet myself) I accept that there can be e.g. multiple SVN web interfaces running at the same time, to suit all tastes -- at least for that it is important to note that it doesn't have to be mutually exclusive. Another point is that the CMS (trac,gforge,..) doesn't have to actually host the wiki, e.g., it just has to point to where it is. So what I really care about is having the right tools working at 100%, not where they live at night or what colors they are painted. If we decide to stay with GForge or MediaWiki but there is some feature we just can't live without, then surely there is enough programming talent around here to patch them & submit to upstream..... and if Intevation or OSGeo needs help fulfilling our wants, we can do that too. regards & sorry for the ramble, Hamish From hamish_nospam at yahoo.com Tue Oct 2 09:18:35 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Oct 2 09:18:42 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> <20071001185716.6862a47c.hamish_nospam@yahoo.com> Message-ID: <20071002201835.31696203.hamish_nospam@yahoo.com> Hamish wrote: > > > over the weekend there were 56 new spambot accounts opened in the > > > wiki .. > > oops I counted wrong, make that 68 new accounts to ban. Martin Landa: > hm, too bad. Not sure how to avoid this situation. To allow creating > new accounts only for sysops is maybe too restrictive... We tried this for the GpsDrive wiki. IMO (as a wiki admin there validating accounts) it IS too restrictive and a big mistake. It means that just the usual core contributors contribute, the casual contributors (ie potential future core contributors) don't bother. We were forced to do it to stop the spamming though. :-/ I will push for captcha + reopening it there if we find a good solution here. (both use MediaWiki) Markus: > Would it help to enable a captcha? Yes. It would help solve our current problem of creation of fake accounts. Markus: > What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ? Looks good! For ConfirmEdit I wouldn't like to turn on the captcha for "all edits" as that would be too much of a burden, but apparently you can do it for all edits which include external URLs and for new accounts, which is an ok compromise. And it seems those are the ConfirmEdit defaults already: $wgCaptchaTriggers['edit'] = false; $wgCaptchaTriggers['create'] = false; $wgCaptchaTriggers['addurl'] = true; $wgCaptchaTriggers['createaccount'] = true; $wgCaptchaTriggers['badlogin'] = true; Here is another MediaWiki captcha plugin to look at: http://recaptcha.net/plugins/mediawiki/ The official MediaWiki page uses a couple of plugins: ("Other" section) http://www.mediawiki.org/wiki/Special:Version (ConfirmEdit, Newuserlog, and SpamBlacklist) as does Wikipedia: http://en.wikipedia.org/wiki/Special:Version Here is the MediaWiki Combating_spam man page: http://www.mediawiki.org/wiki/Manual:Combating_spam Google found this page which mentions a MediaWiki plugin called "Bad Behavior": http://meredith.wolfwater.com/wordpress/index.php/2006/01/04/wiki-spam-begone/ http://www.bad-behavior.ioerror.us/2007/01/27/bad-behavior-2010/ http://www.homelandstupidity.us/software/bad-behavior/installing-and-using-bad-behavior/on-mediawiki/ (shrug) Markus: > * Martin and me have updated Mediawiki to 1.6.10-SVN. thanks guys. > * I have removed all above mentioned bad users from the DB (they all > subscribe from the *same* email address for verification - how to > block that?). (still 21 new ones today.. grrr) tricks in the mailer or /etc/ are probably too invasive, it really needs to be stopped by the wiki software somehow. Maybe some PHP hack? Unless there is an easy to edit email domain blacklist for that, by hardcoding a solution we just solve today's problem, not tomorrow's. > * I have added that if "User-Agent" is empty, the user will be rejected > (let me know if you have problems with that). I guess someone will one day complain, or worse go away without complaining. no idea what the spambot pretends to be. The spam accounts keep coming in today, so I guess that didn't stop it. :( > * Bonus: thumbnail creation now works :) using something like > [[Image:wxgrass-gis-manager-layer.png|350px]] nice to gain something positive out of this. So can we try installing ConfirmEdit on the currently installed MediaWiki? thanks for spending the time on this, Hamish From neteler at itc.it Tue Oct 2 09:46:41 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Oct 2 09:46:43 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: <20071002201835.31696203.hamish_nospam@yahoo.com> References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> <20071001185716.6862a47c.hamish_nospam@yahoo.com> <20071002201835.31696203.hamish_nospam@yahoo.com> Message-ID: <20071002074640.GC23304@bartok.itc.it> On Tue, Oct 02, 2007 at 09:18:35AM +0200, Hamish wrote: > Markus: > > Would it help to enable a captcha? > > Yes. It would help solve our current problem of creation of fake accounts. > > Markus: > > What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ? > > Looks good! For ConfirmEdit I wouldn't like to turn on the captcha for > "all edits" as that would be too much of a burden, but apparently you can > do it for all edits which include external URLs and for new accounts, > which is an ok compromise. > > And it seems those are the ConfirmEdit defaults already: > $wgCaptchaTriggers['edit'] = false; > $wgCaptchaTriggers['create'] = false; > $wgCaptchaTriggers['addurl'] = true; > $wgCaptchaTriggers['createaccount'] = true; > $wgCaptchaTriggers['badlogin'] = true; We tried it yesterday, but it enabled only the Chinese version. We didn't manage to enforce English or even what the browser says (mine definitely doesn't send "zh"). So we had to remove it. > Here is another MediaWiki captcha plugin to look at: > http://recaptcha.net/plugins/mediawiki/ "(note that this plugin only works with MediaWiki 1.8 or newer)." -> we have 1.6.x. > The official MediaWiki page uses a couple of plugins: ("Other" section) > http://www.mediawiki.org/wiki/Special:Version > (ConfirmEdit, Newuserlog, and SpamBlacklist) SpamBlacklist we also use. ConfirmEdit fails... Not sure how much Newuserlog helps if it isn't automated. but it would be easier to trac the subscriptions. OK, added: http://grass.gdf-hannover.de/wiki/Special:Log/newusers (maybe sysop only) Additionally: I have now added a test to enforce 5 chars minimum length passwords. Before it was 0 length minimum :-(( > > * I have removed all above mentioned bad users from the DB (they all > > subscribe from the *same* email address for verification - how to > > block that?). > > (still 21 new ones today.. grrr) tricks in the mailer or /etc/ are > probably too invasive, it really needs to be stopped by the wiki software > somehow. Maybe some PHP hack? Unless there is an easy to edit email domain > blacklist for that, by hardcoding a solution we just solve today's > problem, not tomorrow's. I am rather surprised not to be able to simply block certain email addresses from ever subscribing. Mailman does have this feature ("ban"). Strange. Banning by IP isn't really helpful here. Anyway, I can wipe out this subscribe bot easily now (and regularly do). > > * I have added that if "User-Agent" is empty, the user will be rejected > > (let me know if you have problems with that). > > I guess someone will one day complain, or worse go away without > complaining. no idea what the spambot pretends to be. The spam accounts > keep coming in today, so I guess that didn't stop it. :( I have disabled the "User-Agent"-is-empty test. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Tue Oct 2 10:32:53 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Oct 2 10:32:54 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> Message-ID: <12994710.post@talk.nabble.com> William Kyngesburye wrote: > > Make now ALWAYS recompiles everything. > I have the same issue on my Linux box. Markus -- View this message in context: http://www.nabble.com/another-make-problem-%28OSX%2C-but-could-be-a-general-problem%29-tf4551133.html#a12994710 Sent from the Grass - Dev mailing list archive at Nabble.com. From glynn at gclements.plus.com Tue Oct 2 10:49:38 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 2 10:49:42 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> Message-ID: <18178.1570.808559.665340@cerise.gclements.plus.com> William Kyngesburye wrote: > Make now ALWAYS recompiles everything. I'm guessing it has something > to do with the recent parallel build/recompile changes. My last cvs > update was a week ago, and it was normal (a few would recompile > regardless of the need, but not everything). > > ie, from a distclean and configure: > > make -> all GRASS is compiled > change a source file or makefile - or not, doesn't matter > make -> all recompiled Odd. Apart from the changes required to support parallel builds, I also made some changes to prevent unnecessary recompilation. For me, about the only part which is re-compiled is the message catalogues. I'll look into it, but it's going to be awkward if I can't reproduce it. A couple of questions: 1. Is this with a MacOSX App build? If so, do you get the same behaviour with a non-App build? 2. Does it help if you change the following in Rules.make from: $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR) $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ -o $(OBJDIR)/$*.o -c $*.c to: $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) $(MKDIR) $(OBJDIR) $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ -o $(OBJDIR)/$*.o -c $*.c ? -- Glynn Clements From glynn at gclements.plus.com Tue Oct 2 10:52:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 2 10:52:33 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: References: <6C7E7036-0562-499D-A2F1-49ECD9DCCBE3@kyngchaos.com> Message-ID: <18178.1740.646310.601122@cerise.gclements.plus.com> Michael Barton wrote: > I've had this problem for ages. I just cd to the d.m directory and type > make. Then all is well. A bit annoying, but not a problem. I probably > shouldn't even bother with this. Are you saying that the problem with d.m.html existed before this weekend? -- Glynn Clements From glynn at gclements.plus.com Tue Oct 2 10:56:30 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 2 10:56:33 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: <16A3A4B9-D546-4CE4-99B6-8A3C4A19008B@uv.es> References: <18177.16022.290809.107029@cerise.gclements.plus.com> <16A3A4B9-D546-4CE4-99B6-8A3C4A19008B@uv.es> Message-ID: <18178.1982.456230.124187@cerise.gclements.plus.com> Agustin Diez Castillo wrote: > > Can you please try the following: > > > > 1. Delete the files: > > > > dist.i686-apple-darwin8.10.1/docs/html/d.m.html > it does exist > > dist.i686-apple-darwin8.10.1/scripts/d.m > it does exist > > gui/tcltk/d.m/d.m.tmp.html > it doesn't exist > > > > 2. Run "make -C gui/tcltk/d.m" > > > > 3. Report any errors, and whether any of the files mentioned in #1 > > above exist. > No errors > make -C gui/tcltk/d.m > if [ ! -d /Users/Shared/grasssource/grass6/dist.i686-apple- > darwin8.10.1/scripts ]; then mkdir -p /Users/Shared/grasssource/ > grass6/dist.i686-apple-darwin8.10.1/scripts; fi > /usr/bin/install -c d.m /Users/Shared/grasssource/grass6/dist.i686- > apple-darwin8.10.1/scripts/d.m > GISRC=/Users/Shared/grasssource/grass6/dist.i686-apple-darwin8.10.1/ > demolocation/.grassrc63 GISBASE=/Users/Shared/grasssource/grass6/ > dist.i686-apple-darwin8.10.1 PATH="/Users/Shared/grasssource/grass6/ > dist.i686-apple-darwin8.10.1/bin:$PATH" DYLD_LIBRARY_PATH="/Users/ > Shared/grasssource/grass6/dist.i686-apple-darwin8.10.1/bin:/Users/ > Shared/grasssource/grass6/dist.i686-apple-darwin8.10.1/lib:" > LC_ALL=C /Users/Shared/grasssource/grass6/dist.i686-apple- > darwin8.10.1/scripts/d.m --html-description < /dev/null | grep -v ' body>\|' > d.m.tmp.html ; true > ../../../tools/mkhtml.sh d.m ; mkdir -p /Users/Shared/grasssource/ > grass6/dist.i686-apple-darwin8.10.1/docs/html ; /usr/bin/install -c - > m 644 d.m.tmp.html /Users/Shared/grasssource/grass6/dist.i686-apple- > darwin8.10.1/docs/html/d.m.html ; for file in *.png *.jpg ; do head - > n 1 $file | grep '^#!' > /dev/null ; if [ $? -ne 0 ] ; then /usr/bin/ > install -c -m 644 $file /Users/Shared/grasssource/grass6/dist.i686- > apple-darwin8.10.1/docs/html ; fi done 2> /dev/null ; true > rm d.m.tmp.html > > > > > 4. Repeat steps 2 and 3. > No problem the second time > > > > This problem only occurs on certain systems (possibly depending upon > > the version of "make"). I can't reproduce it here. Also, it has only > > been reported with regard to d.m and gis.m, although exactly the same > > rules are used for other scripts. > > This has been the first and only time it occurs. I did "make > distclean" before ./configure Can you clarify? Are you saying that even after "make distclean" and "configure", the problem with d.m.html doesn't always occur? -- Glynn Clements From hamish_nospam at yahoo.com Tue Oct 2 11:01:43 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Oct 2 11:01:48 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: <20071002074640.GC23304@bartok.itc.it> Message-ID: <768384.72073.qm@web52701.mail.re2.yahoo.com> Markus: > > > Would it help to enable a captcha? Hamish: > > Yes. It would help solve our current problem of creation of fake accounts. M: > > > What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ? H: > > Looks good! M: > We tried it yesterday, but it enabled only the Chinese version. > We didn't manage to enforce English or even what the browser > says (mine definitely doesn't send "zh"). So we had to remove it. ?! hmph. An idea- my Debian/sarge box once installed a bunch of Chinese versions automatically. It turned out the problem was that the package relied on a meta-package which could be fulfilled by a number of language specific packages. So it installed the first language package on the list, which was Chinese, and hilarity ensued. IIRC we had a similar problem with the Debian GRASS package which depends on "xterm | x-terminal-emulator". In the past we just depended on "x-terminal-emulator" which could pull in something other than xterm that provided x-terminal-emulator, and hilarity ensued. (?) also for ConfirmEdit "The current version(s) require PHP5; for PHP4-compatible versions, use an older version available in the SVN." ? taken from SVN? I see that ConfirmEdit.i18n.php has had many edits in the last 3 weeks. too late for me tonight, but they have an IRC channel for support- http://www.mediawiki.org/wiki/Manual:FAQ#I_have_a_question_not_answered_here._Where_do_I_go_next.3F I would like to keep working on this problem. H: > > Here is another MediaWiki captcha plugin to look at: > > http://recaptcha.net/plugins/mediawiki/ M: > "(note that this plugin only works with MediaWiki 1.8 or newer)." > -> we have 1.6.x. ah. > > The official MediaWiki page uses a couple of plugins: ("Other" section) .. > Not sure how much Newuserlog helps if it isn't automated. > but it would be easier to trac the subscriptions. OK, added: nice. > I am rather surprised not to be able to simply block certain email > addresses from ever subscribing. Mailman does have this feature ("ban"). > Strange. Banning by IP isn't really helpful here. I guess a request upstream is in order. It must happen to others sites too. > Anyway, I can wipe out this subscribe bot easily now (and regularly do). Yea, but it is still an unneeded waste of time & energy so finding an automated solution would be better in the long run. cheers, Hamish ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From neteler at itc.it Tue Oct 2 11:17:33 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Oct 2 11:17:35 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: <768384.72073.qm@web52701.mail.re2.yahoo.com> References: <20071002074640.GC23304@bartok.itc.it> <768384.72073.qm@web52701.mail.re2.yahoo.com> Message-ID: <20071002091732.GA15060@bartok.itc.it> On Tue, Oct 02, 2007 at 11:01:43AM +0200, Hamish wrote: > M: > > > > What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ? > H: > > > Looks good! > M: > > We tried it yesterday, but it enabled only the Chinese version. > > We didn't manage to enforce English or even what the browser > > says (mine definitely doesn't send "zh"). So we had to remove it. > > ?! hmph. > An idea- my Debian/sarge box once installed a bunch of Chinese versions > automatically. It turned out the problem was that the package relied on a > meta-package which could be fulfilled by a number of language specific > packages. So it installed the first language package on the list, which was > Chinese, and hilarity ensued. Maybe you could guide me offlist how to verify that? I think that the machine is a rather minimalistic (sarge) installation. > also for ConfirmEdit "The current version(s) require PHP5; for PHP4-compatible > versions, use an older version available in the SVN." ? > > taken from SVN? I see that ConfirmEdit.i18n.php has had many edits in the last > 3 weeks. Of course we took an older release from SVN :) http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ConfirmEdit/ConfirmEdit.php?view=log#rev19995 Revision 19995 PHP 4 / MW 1.6 compat > too late for me tonight, but they have an IRC channel for support- > http://www.mediawiki.org/wiki/Manual:FAQ#I_have_a_question_not_answered_here._Where_do_I_go_next.3F > > > I would like to keep working on this problem. Me, too, but I also need to do my regular work. Will try again later... cheers, Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From michael.barton at asu.edu Tue Oct 2 13:04:37 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Oct 2 13:08:51 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: <18178.1740.646310.601122@cerise.gclements.plus.com> Message-ID: I guess to be honest, I don't remember if it was d.m.html or another piece. But I always get an error compiling d.m. I have to go to the d.m directory and do a make there. It didn't seem worth bothering anyone about since we're phasing out d.m anyway. Michael On 10/2/07 1:52 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I've had this problem for ages. I just cd to the d.m directory and type >> make. Then all is well. A bit annoying, but not a problem. I probably >> shouldn't even bother with this. > > Are you saying that the problem with d.m.html existed before this > weekend? __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From kwythers at umn.edu Tue Oct 2 13:14:21 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Tue Oct 2 13:14:29 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: References: Message-ID: On Oct 2, 2007, at 6:04 AM, Michael Barton wrote: > I guess to be honest, I don't remember if it was d.m.html or > another piece. > But I always get an error compiling d.m. I have to go to the d.m > directory > and do a make there. It didn't seem worth bothering anyone about > since we're > phasing out d.m anyway. > > Michael > I can confirm that the d.m error has been there for 7-10 days at least. . Kirk > > On 10/2/07 1:52 AM, "Glynn Clements" wrote: > >> >> Michael Barton wrote: >> >>> I've had this problem for ages. I just cd to the d.m directory >>> and type >>> make. Then all is well. A bit annoying, but not a problem. I >>> probably >>> shouldn't even bother with this. >> >> Are you saying that the problem with d.m.html existed before this >> weekend? > > __________________________________________ > 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-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From grass-dev at grass.itc.it Tue Oct 2 13:27:45 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Tue Oct 2 13:18:51 2007 Subject: [GRASS-dev] [grass-code I][497] r.spread not working Message-ID: <20071002112745.A7CC34033D@pyrosoma.intevation.org> code I item #497, was opened at 2007-10-02 13:27 Status: Open Priority: 3 Submitted By: Ljiljana Bodrozic (ljiljana) Assigned to: Nobody (None) Summary: r.spread not working Issue type: module bug Issue status: None GRASS version: 6.1 GRASS component: None Operating system: None Operating system version: GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: In grass vesions higher then 6.0 r.spread module for wildfire spread modeling is not working (freezes) ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=497&group_id=21 From kwythers at umn.edu Tue Oct 2 14:04:00 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Tue Oct 2 14:04:06 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: References: Message-ID: <9FEB7057-F34B-40FB-97C8-BFE02CDCD051@umn.edu> Just rebuilt with: # regexp {nsres= *([0-9]+)} $region dummy oldres1 # regexp {ewres= *([0-9]+)} $region dummy oldres2 # regexp {rows= *([0-9]+)} $region dummy vrows # regexp {cols= *([0-9]+)} $region dummy vcols set reglist [split $region "\n"] foreach line $reglist { set line [string trim $line] set key [lindex [split $line "="] 0] switch $key { nsres {set oldres1 [lindex [split $line "="] 1]} ewres {set oldres2 [lindex [split $line "="] 1]} rows {set vrows [lindex [split $line "="] 1]} cols {set vcols [lindex [split $line "="] 1]} } } Here is the new error (upon starting GmAnim): invalid command name "Proc" invalid command name "Proc" while executing "Proc GmAnim::do_run {} { # procedure that displays maps in an animation and controls the animation global loop global swing global a..." (file "/Applications/GRASS-6.3.app/Contents/MacOS/etc/gm/ animate.tcl" line 635) invoked from within "source /Applications/GRASS-6.3.app/Contents/MacOS/etc/gm/animate.tcl" (in namespace eval "::" script line 1) invoked from within "namespace eval :: $auto_index($name)" (procedure "auto_load" line 13) invoked from within "auto_load $name [uplevel 1 {::namespace current}]" (autoloading "GmAnim::main") invoked from within "GmAnim::main" ("uplevel" body line 1) invoked from within "uplevel \#0 $cmd" (procedure "Button::_release" line 18) invoked from within "Button::_release .mainframe.topf.tb1.bbox4.b0" (command bound to event) On Oct 1, 2007, at 9:17 PM, Michael Barton wrote: > Kirk, > > You seem to be missing a line (maybe my fault). Note the line defining > reglist. > > > Michael > ===================================== > > set reglist [split $region "\n"] > > foreach line $reglist { > set line [string trim $line] > set key [lindex [split $line "="] 0] > switch $key { > nsres {set oldres1 [lindex [split $line "="] 1]} > ewres {set oldres2 [lindex [split $line "="] 1]} > rows {set vrows [lindex [split $line "="] 1]} > cols {set vcols [lindex [split $line "="] 1]} > } > > } > > > > On 10/1/07 6:36 AM, "Kirk Wythers" wrote: > >> >> On Sep 30, 2007, at 11:23 PM, Michael Barton wrote: >> >>> Well, after asking for help, I figured out how to this without the >>> dread >>> regexp ;-). This might even be a bit better routine. >>> >>> Anyway, I can't commit this because I'm out of town, but if anyone >>> wants to >>> try it, you need to change lines in procedure GmAnim::main (module >>> animate.tcl). Replace the commented lines with the uncommented >>> lines below. >>> >>> foreach line $reglist { >>> set line [string trim $line] >>> set key [lindex [split $line "="] 0] >>> switch $key { >>> nsres {set oldres1 [lindex [split $line "="] 1]} >>> ewres {set oldres2 [lindex [split $line "="] 1]} >>> rows {set vrows [lindex [split $line "="] 1]} >>> cols {set vcols [lindex [split $line "="] 1]} >>> } >>> >>> } >>> >>> # regexp {nsres= *([0-9]+)} $region dummy oldres1 >>> # regexp {ewres= *([0-9]+)} $region dummy oldres2 >>> # regexp {rows= *([0-9]+)} $region dummy vrows >>> # regexp {cols= *([0-9]+)} $region dummy vcols >>> >>> >> >> Michael, >> >> Thanks for the email. I made the following changes but ended up with >> a new error. I might have altered the wrong file. Here is what I >> tried. >> >> From the file ~/src_intel/grass-6.3.cvs/gui/tcltk/gis.m/animate.tcl >> >> # set initial canvas geometry to match region >> if {[catch {set region [exec g.region -ugp]} error]} { >> Gm::errmsg $error >> } >> >> # regexp {nsres= *([0-9]+)} $region dummy oldres1 >> # regexp {ewres= *([0-9]+)} $region dummy oldres2 >> # regexp {rows= *([0-9]+)} $region dummy vrows >> # regexp {cols= *([0-9]+)} $region dummy vcols >> >> foreach line $reglist { >> set line [string trim $line] >> set key [lindex [split $line "="] 0] >> switch $key { >> nsres {set oldres1 [lindex [split $line "="] 1]} >> ewres {set oldres2 [lindex [split $line "="] 1]} >> rows {set vrows [lindex [split $line "="] 1]} >> cols {set vcols [lindex [split $line "="] 1]} >> } >> >> } >> >> New error when startring up GmAnim. >> >> can't read "reglist": no such variable >> can't read "reglist": no such variable >> while executing >> "foreach line $reglist { >> set line [string trim $line] >> set key [lindex [split $line "="] 0] >> switch $key { >> nsres {..." >> (procedure "GmAnim::main" line 28) >> invoked from within >> "GmAnim::main" >> ("uplevel" body line 1) >> invoked from within >> "uplevel \#0 $cmd" >> (procedure "Button::_release" line 18) >> invoked from within >> "Button::_release .mainframe.topf.tb1.bbox4.b0" >> (command bound to event) >> >> Perhaps this is not what you intended? >> >> Kirk >> >> >> >> >> > > __________________________________________ > 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-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > From glynn at gclements.plus.com Tue Oct 2 15:20:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 2 15:20:22 2007 Subject: [GRASS-dev] ganim troubles in latest cvs In-Reply-To: <9FEB7057-F34B-40FB-97C8-BFE02CDCD051@umn.edu> References: <9FEB7057-F34B-40FB-97C8-BFE02CDCD051@umn.edu> Message-ID: <18178.17793.343488.158318@cerise.gclements.plus.com> Kirk Wythers wrote: > Just rebuilt with: > > # regexp {nsres= *([0-9]+)} $region dummy oldres1 > # regexp {ewres= *([0-9]+)} $region dummy oldres2 > # regexp {rows= *([0-9]+)} $region dummy vrows > # regexp {cols= *([0-9]+)} $region dummy vcols > > set reglist [split $region "\n"] > > foreach line $reglist { > set line [string trim $line] > set key [lindex [split $line "="] 0] > switch $key { > nsres {set oldres1 [lindex [split $line "="] 1]} > ewres {set oldres2 [lindex [split $line "="] 1]} > rows {set vrows [lindex [split $line "="] 1]} > cols {set vcols [lindex [split $line "="] 1]} > } > > } > > > Here is the new error (upon starting GmAnim): > > invalid command name "Proc" > invalid command name "Proc" > while executing > "Proc GmAnim::do_run {} { > # procedure that displays maps in an animation and controls the animation > global loop > global swing > global a..." > (file "/Applications/GRASS-6.3.app/Contents/MacOS/etc/gm/animate.tcl" line 635) That's something which has occurred at your end. The source file in CVS has "proc" in lower case. -- Glynn Clements From Agustin.Diez at uv.es Tue Oct 2 16:51:04 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Tue Oct 2 16:54:59 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: <18178.1982.456230.124187@cerise.gclements.plus.com> References: <18177.16022.290809.107029@cerise.gclements.plus.com> <16A3A4B9-D546-4CE4-99B6-8A3C4A19008B@uv.es> <18178.1982.456230.124187@cerise.gclements.plus.com> Message-ID: <244A872E-6B84-4684-A20C-5291F205694E@uv.es> > Can you clarify? Are you saying that even after "make distclean" and > "configure", the problem with d.m.html doesn't always occur? No it doesn't, I was clarifying that before the error occurred the first time I had done "make distclean". Now I can compile with no errors but Generated HTML docs in ../dist.i686-apple-darwin8.10.1/docs/html/ index.html ---------------------------------------------------------------------- Following modules are missing the 'description.html' file in src code: d.m ---------------------------------------------------------------------- GRASS GIS compilation log ------------------------- Started compilation: Tue Oct 2 15:59:30 CEST 2007 -- Errors in: No errors detected. > > -- > Glynn Clements > From kwythers at umn.edu Tue Oct 2 16:55:21 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Tue Oct 2 16:55:27 2007 Subject: [GRASS-dev] present state of GmAnim in gui In-Reply-To: References: Message-ID: <8DA6F295-FB2B-429E-BA73-A1D499310BAD@umn.edu> Thanks to everyone who has responded to my GmAnim problem. Here is the latest. Suspecting that I had other issues in the src, I dumped the source, re-downloaded new source from cvs, and ran update -dP. Then I commented out the regex and added Michael's code: # set initial canvas geometry to match region if {[catch {set region [exec g.region -ugp]} error]} { Gm::errmsg $error } #regexp {nsres= *([0-9]+)} $region dummy oldres1 #regexp {ewres= *([0-9]+)} $region dummy oldres2 #regexp {rows= *([0-9]+)} $region dummy vrows #regexp {cols= *([0-9]+)} $region dummy vcols set reglist [split $region "\n"] foreach line $reglist { set line [string trim $line] set key [lindex [split $line "="] 0] switch $key { nsres {set oldres1 [lindex [split $line "="] 1]} ewres {set oldres2 [lindex [split $line "="] 1]} rows {set vrows [lindex [split $line "="] 1]} cols {set vcols [lindex [split $line "="] 1]} } } Presently GmAnim runs (using the same 30s raster from the worldclim database). However I do notice that several of the buttons on the animation window are broken, including the "exit" button, which gives this error: WARNING: nothing removed WARNING: nothing removed while executing "exec g.remove region=$tmpregion --q" (procedure "GmAnim::cmd_exit" line 21) invoked from within "GmAnim::cmd_exit" (command bound to event) As an odd sidenote, the older version of GmAnim (before the animation window was updated to have buttons on the top of the window) worked fine with: regexp {nsres= *([0-9]+)} $region dummy oldres1 regexp {ewres= *([0-9]+)} $region dummy oldres2 regexp {rows= *([0-9]+)} $region dummy vrows regexp {cols= *([0-9]+)} $region dummy vcols From warmerdam at pobox.com Tue Oct 2 16:58:59 2007 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Oct 2 16:59:02 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <20071002195728.31b45442.hamish_nospam@yahoo.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> Message-ID: <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> On 10/1/07, Hamish wrote: > What support software to use seems to be a totally separate issue from > where to host things, as Intevation seems to be happy to provide what we > ask for as best they can, and I guess (but don't know) that the OSGeo > admins would be supportive too. Hamish, By default OSGeo SAC provides Trac+Subversion. If you want substantially different services then it is likely that someone from the GRASS team would need to volunteer to set it up and maintain it. In this regard Intevation could be a better platform. SAC is already somewhat stretched. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From neteler.osgeo at gmail.com Tue Oct 2 17:06:56 2007 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Tue Oct 2 17:07:01 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> Message-ID: <86782b610710020806l3383bb3t81c6355fbd130fd8@mail.gmail.com> On 10/2/07, Frank Warmerdam wrote: > On 10/1/07, Hamish wrote: > > What support software to use seems to be a totally separate issue from > > where to host things, as Intevation seems to be happy to provide what we > > ask for as best they can, and I guess (but don't know) that the OSGeo > > admins would be supportive too. > > Hamish, > > By default OSGeo SAC provides Trac+Subversion. If you want > substantially different services then it is likely that someone from > the GRASS team would need to volunteer to set it up and > maintain it. In this regard Intevation could be a better platform. > SAC is already somewhat stretched. To add confusion: :) the Wiki is not hosted by Intevation, but by GDF Hannover. Markus From neteler at itc.it Tue Oct 2 17:11:20 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Oct 2 17:11:22 2007 Subject: [GRASS-dev] present state of GmAnim in gui In-Reply-To: <8DA6F295-FB2B-429E-BA73-A1D499310BAD@umn.edu> References: <049F0A26-957D-4542-A32E-59683CBA2665@umn.edu> <18175.54430.44379.387499@cerise.gclements.plus.com> <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> <8DA6F295-FB2B-429E-BA73-A1D499310BAD@umn.edu> Message-ID: <13000761.post@talk.nabble.com> Kirk Wythers wrote: > > Thanks to everyone who has responded to my GmAnim problem. Here is > the latest. > ... > Sorry for a stupid comment: why not working with patches against CVS? The current approach seems to be a bit "lossy". patch/diff is fairly easy to use (see SUBMITTING in the main source code directory). Markus -- View this message in context: http://www.nabble.com/ganim-troubles-in-latest-cvs-tf4535542.html#a13000761 Sent from the Grass - Dev mailing list archive at Nabble.com. From kwythers at umn.edu Tue Oct 2 17:21:51 2007 From: kwythers at umn.edu (Kirk Wythers) Date: Tue Oct 2 17:21:55 2007 Subject: [GRASS-dev] present state of GmAnim in gui In-Reply-To: <13000761.post@talk.nabble.com> References: <049F0A26-957D-4542-A32E-59683CBA2665@umn.edu> <18175.54430.44379.387499@cerise.gclements.plus.com> <0A27DE12-8F8E-428D-A34F-83223E0B3187@umn.edu> <8DA6F295-FB2B-429E-BA73-A1D499310BAD@umn.edu> <13000761.post@talk.nabble.com> Message-ID: On Oct 2, 2007, at 10:11 AM, Markus Neteler wrote: > > > > Sorry for a stupid comment: why not working with patches > against CVS? The current approach seems to be a bit "lossy". > > patch/diff is fairly easy to use (see SUBMITTING in the main > source code directory). No worries on the comment. I'll look at SUBMITTING. My only excuse is that on a fast connection and a fast processor, the "lossy" solution takes less than 10 minutes and then I'm sure that all of my potential personal screw ups are gone ;-) From cdavilam at jemila.jazztel.es Tue Oct 2 17:30:06 2007 From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=) Date: Tue Oct 2 17:22:29 2007 Subject: [GRASS-dev] [grass-code I][495] gis.m output window buttons don't fit text width In-Reply-To: References: Message-ID: <470263FE.5030306@jemila.jazztel.es> Michael Barton escribi?: > Carlos, > > May I suggest that "run (background)" might be better translated as > "ejecutar (fondo)" than "ejecutar (segundo plan)" This should fit OK. I think "Segundo plano" is better translation than "fondo" in this case, but anyway you gave me an idea for the solution (2? plano), so thanks. Next question is what may happen in other languages. Carlos From tutey at o2.pl Tue Oct 2 17:50:09 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Oct 2 17:50:14 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <20071001202503.GD17023@bartok.itc.it> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071001202503.GD17023@bartok.itc.it> Message-ID: <470268B1.80903@o2.pl> Markus Neteler wrote: > On Mon, Oct 01, 2007 at 10:09:33PM +0200, Jan-Oliver > Wagner wrote: >> On Saturday 29 September 2007 09:58, Markus Neteler >> wrote: >>> OK, fine (not enabled for GRASS apparently). >> up to project admins to do so. > OK - I am none, so I cannot do anything. > Additionally, there are several useful features either > missing in GForge or not activated (I cannot judge that > since still I don't know what's available and possible). > But I feel that we start to go in circles. Hi FWIW, I just want to let you know that I'm not going to get involved into anything regarding GRASS CMS besides trackers. So if anyone is interested in enabling *and maintaining* SVN, WIKI or anything else at GRASS GForge site just drop me a line and I'll be more than happy to provide admin account for the person, and help as far as I'm competent. So far nobody has volunteered. For details, manuals are here: http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1 Maciek From woklist at kyngchaos.com Tue Oct 2 17:58:29 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Oct 2 17:58:34 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <18178.1570.808559.665340@cerise.gclements.plus.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> Message-ID: <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> On Oct 2, 2007, at 3:49 AM, Glynn Clements wrote: > A couple of questions: > > 1. Is this with a MacOSX App build? If so, do you get the same > behaviour with a non-App build? > Actually, yes. Before I fixed a small problem where the macosx dir didn't build, it was happening. > 2. Does it help if you change the following in Rules.make from: > > $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR) > $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ > -o $(OBJDIR)/$*.o -c $*.c > > to: > > $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) > $(MKDIR) $(OBJDIR) > $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ > -o $(OBJDIR)/$*.o -c $*.c > > ? Much better. Still a few recompiles: various copy files steps libsqlp (recompile) r.terraflow (recompile) (that has its own object targets with a similar "| $(OBJDIR)" in the target deps) nviz (relink) my OSX app build (relink) (my fault for how I set up the makefile) ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From neteler at itc.it Tue Oct 2 18:14:14 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Oct 2 18:14:18 2007 Subject: [GRASS-dev] impending wiki spam bombing In-Reply-To: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> Message-ID: <13001944.post@talk.nabble.com> HamishB wrote: > > Hi, > > I notice over the last day or two a high number of seemingly randomly > generated new user accounts on our wiki site. We can ban these fake > users as they come and hope we don't hit anyone real, but at 10/day > it becomes an ugly chore, time sink, and demotivator. Up til now we've > been getting a few suspect accounts at the rate of around 1/week but no > automated spam. > > We are up to 908 users registered, most appear to be spambot accounts, > but only 41 have been manually blocked. > I have now deleted around 400 suspicious users (like "WkkYbe", "FwfNv7" etc) which were registered without email address. :-) Thanks to SQL no big deal once you know what you are looking for. Markus -- View this message in context: http://www.nabble.com/impending-wiki-spam-bombing-tf4527023.html#a13001944 Sent from the Grass - Dev mailing list archive at Nabble.com. From tutey at o2.pl Tue Oct 2 18:55:40 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Oct 2 18:55:44 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <20071002195728.31b45442.hamish_nospam@yahoo.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> Message-ID: <4702780C.7080904@o2.pl> Hamish wrote: > For my 2c, I like: > * .... bug tracker .... what was wrong with the old one again? 1. spam. 2. Because of the spam, anonymous reporting had to be disabled. Only registered users could edit/post new tickets to RT via the web form/email from then on. 3. None of the GRASS devs was able to create new accounts or do any other admin tasks in RT. I don't remember details why (in theory Markus was one the RT admins, but I recall he complained "something did not work"). 3. RT is not extendible. In GForge one can customize the trackers pretty much. In RT there were only few hardcoded fields. In GForge trackers, there can be any (?) number of fields in each tracker, of 7 different types. 4. Filtering tickets in GForge is more powerful than in RT. 5. In GForge one can turn on/off monitoring of particular tickets, trackers with one click. In RT one had to add or remove his email address manually in the given ticket. There was no way to monitor the whole tracker in RT ('quee' in RT lingo). > The two really annoying things with Gforge bug tracker to me is the > top posting of comments Although I share your feelings, that's a matter of preference IMHO. > and that you can't cc it in posts to the > grass-dev mailing list, you have to use the web form, duplicating > effort and killing casual contributions. That's already known and reported to GForge Intevation maintainers [1]. Also please note the same problem applied to RT in the last days of it's life after a spam attack. There was a suggestion from Intevation this particular problem could be overcome for GForge. It was suggested the mail reply could be experimentaly enabled for GRASS, see [2] (the last post, ie. the first on the top ;)). The oustanding issue hampering the info flow is the inability to CC from the GForge tracker (ie. using the web form). I think this is the only real point where RT beats GForge trackers (assuming the email reply issue could really be fixed, as suggested in [2]). Both issues are also mentioned here [3]. Note there were 2 other serious issues affecting GForge trackers usability and info flow for GRASS, and they've already been fixed by Sascha Wilde of Intevation (Thanks!). [1]http://wald.intevation.org/tracker/?group_id=1&atid=162 [2]http://wald.intevation.org/tracker/index.php?func=detail&aid=85&group_id=1&atid=162 [3]http://grass.gdf-hannover.de/wiki/Tracking#Buggy_bugtracker.3F Maciek From tutey at o2.pl Tue Oct 2 19:07:26 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Oct 2 19:07:29 2007 Subject: [GRASS-dev] porting sites format to new vector In-Reply-To: <470145C7.8040902@laserdata.at> References: <470145C7.8040902@laserdata.at> Message-ID: <47027ACE.2040404@o2.pl> Volker Wichmann wrote: > Hi, > > I'd like to know if there is some kind of 'how-to' about porting a > module that is using the obsolete vector sites format to the latest > vector architecture? I've been searching the web but couldn't find > anything like that. In addition to Martin's and Brad's advices, there is another example of how to get rid of sites dependecy available. Bob Covill has (mostly) done it for NVIZ. The fix is not completely finished, so it was not submitted to CVS. But it's available from patches tracker on [1]. You can fetch the Gp3.c file attached there and compare it with the stock Gp3.c from CVS. Hopefully it'll give you some inspiration. [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=371&group_id=21&atid=205 Maciek From glynn at gclements.plus.com Tue Oct 2 19:30:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 2 19:30:30 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> Message-ID: <18178.32819.389941.767440@cerise.gclements.plus.com> William Kyngesburye wrote: > > A couple of questions: > > > > 1. Is this with a MacOSX App build? If so, do you get the same > > behaviour with a non-App build? > > > Actually, yes. Before I fixed a small problem where the macosx dir > didn't build, it was happening. Is that "yes" to the first or to the second, or both? If this only happens with the App build, then it's (mainly) up to you to solve. I can't test an App build, and it appears to be modifying some of the *.make files. For now, I'm only interested in issues which occur when using the stock build system (i.e. no --enable-macosx-app). > > 2. Does it help if you change the following in Rules.make from: > > > > $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR) > > $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ > > -o $(OBJDIR)/$*.o -c $*.c > > > > to: > > > > $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) > > $(MKDIR) $(OBJDIR) > > $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ > > -o $(OBJDIR)/$*.o -c $*.c > > > > ? > > Much better. Is the "make" program GNU make? Does it come via Apple? Can you try building GNU make from the stock source package and using that? Prerequisites listed to the right of "|" are "order-only"; if necessary, they will be built before the target, but they won't cause the target to be re-compiled. If you're using something other than GNU make (which includes modified versions if the modifications make a difference), then I can't really help. I would rather not unconditionally run mkdir for every object file if it's an issue with one particular make program. > Still a few recompiles: > > various copy files steps > libsqlp (recompile) > r.terraflow (recompile) (that has its own object targets with a > similar "| $(OBJDIR)" in the target deps) > nviz (relink) > my OSX app build (relink) (my fault for how I set up the makefile) The copying steps are a known issue. That's simple to fix; it just means manually re-writing all of the individual targets. NVIZ is also known; NVIZ has its own, non-standard build system which is a complete mess, and I don't touch it if I don't need to. I don't have the issues with r.terraflow (which also has its own, non-standard build system) or sqlp (which is a normal library). sqlp *might* be due to lex/yacc issues (that's the only part that's different from other libraries). If yacc is being re-run, y.tab.h will be updated, which will force the rest of it to be compiled. -- Glynn Clements From michael.barton at asu.edu Tue Oct 2 19:33:22 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Oct 2 19:33:37 2007 Subject: [GRASS-dev] present state of GmAnim in gui In-Reply-To: <8DA6F295-FB2B-429E-BA73-A1D499310BAD@umn.edu> Message-ID: On 10/2/07 7:55 AM, "Kirk Wythers" wrote: > > > Presently GmAnim runs (using the same 30s raster from the worldclim > database). However I do notice that several of the buttons on the > animation window are broken, including the "exit" button, which gives > this error: > > WARNING: nothing removed > WARNING: nothing removed > while executing > "exec g.remove region=$tmpregion --q" > (procedure "GmAnim::cmd_exit" line 21) > invoked from within > "GmAnim::cmd_exit" > (command bound to event) The warning is just that, not an error. But I don't know what is causing this. I'll look into it. > > As an odd sidenote, the older version of GmAnim (before the animation > window was updated to have buttons on the top of the window) worked > fine with: > > regexp {nsres= *([0-9]+)} $region dummy oldres1 > regexp {ewres= *([0-9]+)} $region dummy oldres2 > regexp {rows= *([0-9]+)} $region dummy vrows > regexp {cols= *([0-9]+)} $region dummy vcols The very first version that was disseminated, was written by Glynn as a prototype TclTk replacement for Xganim. When I incorporated it into the overall TclTk GUI, I had to change aspects of how it operated--though not this part. These statements work fine with integer-level resolutions (e.g., 1m, 30m), but seem to have problems with resolutions that are floating point. I'm sure that the regexp statements could be changed to deal with FP data, but I don't know how to do it. So I accomplished this by another route. Michael __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Tue Oct 2 19:36:48 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Oct 2 19:36:51 2007 Subject: [GRASS-dev] GRASS 7 Migration from CVS to SVN - GForge trackers fork In-Reply-To: <4702780C.7080904@o2.pl> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <4702780C.7080904@o2.pl> Message-ID: <470281B0.2040000@o2.pl> Maciej Sieczka wrote: > The oustanding issue hampering the info flow is the > inability to CC from the GForge tracker I forgot to add that this can be workedaround by enabling *all* messages posted from the GForge trackers web form to be forwarded to GRASS dev list. Currently it is disabled (only the initial report is forwarded) as I was told this would be not welcome on such a high-traffic list. Now I'm thinking that maybe the extra traffic is worth it, when the stake is a better info flow? Please let me know what you think. Maciek From wichmann at laserdata.at Tue Oct 2 20:19:15 2007 From: wichmann at laserdata.at (Volker Wichmann) Date: Tue Oct 2 20:18:33 2007 Subject: [GRASS-dev] porting sites format to new vector In-Reply-To: <47027ACE.2040404@o2.pl> References: <470145C7.8040902@laserdata.at> <47027ACE.2040404@o2.pl> Message-ID: <47028BA3.2060805@laserdata.at> Martin, Brad, Maciej, thanks for your references! I will have a look ... maybe I'm able to bring together some useful hints for the wiki. Volker From woklist at kyngchaos.com Tue Oct 2 20:34:35 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Oct 2 20:34:42 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <18178.32819.389941.767440@cerise.gclements.plus.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> Message-ID: On Oct 2, 2007, at 12:30 PM, Glynn Clements wrote: > > William Kyngesburye wrote: > >>> A couple of questions: >>> >>> 1. Is this with a MacOSX App build? If so, do you get the same >>> behaviour with a non-App build? >>> >> Actually, yes. Before I fixed a small problem where the macosx dir >> didn't build, it was happening. > > Is that "yes" to the first or to the second, or both? > > If this only happens with the App build, then it's (mainly) up to you > to solve. I can't test an App build, and it appears to be modifying > some of the *.make files. > > For now, I'm only interested in issues which occur when using the > stock build system (i.e. no --enable-macosx-app). > yes, without OSX app build - all that is really is just another subdir to make, so the libraries and modules are all stock GRASS. >>> 2. Does it help if you change the following in Rules.make from: >>> >>> $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR) >>> $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ >>> -o $(OBJDIR)/$*.o -c $*.c >>> >>> to: >>> >>> $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) >>> $(MKDIR) $(OBJDIR) >>> $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ >>> -o $(OBJDIR)/$*.o -c $*.c >>> >>> ? >> >> Much better. > > Is the "make" program GNU make? Does it come via Apple? Can you try > building GNU make from the stock source package and using that? > > Prerequisites listed to the right of "|" are "order-only"; if > necessary, they will be built before the target, but they won't cause > the target to be re-compiled. > > If you're using something other than GNU make (which includes modified > versions if the modifications make a difference), then I can't really > help. I would rather not unconditionally run mkdir for every object > file if it's an issue with one particular make program. > OSX Tiger/GCC 4 uses GNU Make 3.80. It doesn't look like Apple modified it (like they have for other stuff). ----- 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 From neteler.osgeo at gmail.com Tue Oct 2 21:39:28 2007 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Tue Oct 2 21:39:33 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN - GForge trackers fork In-Reply-To: <470281B0.2040000@o2.pl> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <4702780C.7080904@o2.pl> <470281B0.2040000@o2.pl> Message-ID: <86782b610710021239j60fc77f7ga47f6d172056c9a0@mail.gmail.com> On 10/2/07, Maciej Sieczka wrote: > Maciej Sieczka wrote: > > > The oustanding issue hampering the info flow is the > > inability to CC from the GForge tracker > > I forgot to add that this can be workedaround by enabling > *all* messages posted from the GForge trackers web form to > be forwarded to GRASS dev list. Currently it is disabled > (only the initial report is forwarded) as I was told this > would be not welcome on such a high-traffic list. Now I'm > thinking that maybe the extra traffic is worth it, when the > stake is a better info flow? Please let me know what you think. I think that the problem is the opposite: grass-dev -> GForge doesn't work so that list follow-ups are lost. This worked for RT well (beside the spam which wasn't caught at RT while I manage to catch it entering grass-dev again, so it's a matter of using a good spam filter - see old discussions). Markus From woklist at kyngchaos.com Tue Oct 2 21:52:57 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Oct 2 21:53:03 2007 Subject: [GRASS-dev] installed makefile cleanup In-Reply-To: <18167.4130.819798.161922@cerise.gclements.plus.com> References: <18166.13927.743278.5512@cerise.gclements.plus.com> <6EABE0A5-9598-4014-9959-4F9D6F2474A4@kyngchaos.com> <18167.4130.819798.161922@cerise.gclements.plus.com> Message-ID: I sortof understand this. Until you can work out the necessary changes (if you decide to), how about some minimal changes to the the extension compilation working? Here are my revised changes to get it working: - platform.make.in: RUN_GISBASE = ${ARCH_DISTDIR} RUN_GISRC = ${RUN_GISBASE}/demolocation/.grassrc$ {GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR} this allows those to be overridden together in the make step, yet still keeps the same configured default for a source build. - grass.make.in: add after "ifdef INST_NOW": ifdef INST_XTN ARCH_INC = -I$(ARCH_DISTDIR)/include -I$(MODULE_TOPDIR)/include ARCH_LIBPATH = -L$(ARCH_LIBDIR) -L$(MODULE_TOPDIR)/lib endif to look for includes and libs in both the module source/dist and the installed GRASS - grass.make.in: add at end: ifdef INST_XTN include $(MODULE_TOPDIR)/include/Make/Install_xtn.make endif and have a new Install_xtn.make fragment. This is just a trimmed version of the main makefile with just install targets and any unnecessary bits removed. It expects INST_DIR_XTN to be set in the make command. - module.make: for the bin/pgm and etc/pgm targets, conditionalize the dependencies: ifdef INST_XTN $(BIN)/$(PGM)$(EXE): $(ARCH_CMD_OBJS) else $(BIN)/$(PGM)$(EXE): $(ARCH_CMD_OBJS) $(DEPENDENCIES) endif ... ifdef INST_XTN $(ETC)/$(PGM)$(EXE): $(ARCH_CMD_OBJS) else $(ETC)/$(PGM)$(EXE): $(ARCH_CMD_OBJS) $(DEPENDENCIES) endif since the dependencies are based off ARCH_LIBDIR, which will be in the extension source dir, they won't be found. Then, to compile an extension, cd to its source and: make INST_XTN=y GRASS_HOME=. MODULE_TOPDIR=/path/to/installed/grass RUN_GISBASE=/path/to/installed/grass Note: I still had problems with having an inst_xtn: target (similar to the inst_now target) and putting INST_XTN=y before make. No infinite loop now, but after completing the compilation (successfully) it exits with an error: /Applications/GRASS-6.3.app/Contents/MacOS/tools/mkhtml.sh v.strahler ; mkdir -p ./dist.i686-apple-darwin8.10.1/docs/html ; /usr/ bin/install -c -m 644 v.strahler.tmp.html ./dist.i686-apple- darwin8.10.1/docs/html/v.strahler.html ; for file in *.png *.jpg ; do head -n 1 $file | grep '^#!' > /dev/null ; if [ $? -ne 0 ] ; then / usr/bin/install -c -m 644 $file ./dist.i686-apple-darwin8.10.1/docs/ html ; fi done 2> /dev/null ; true INST_XTN= make make[2]: *** No rule to make target `dist.i686-apple-darwin8.10.1/lib/ libgrass_display.dylib', needed by `dist.i686-apple-darwin8.10.1/bin/ v.strahler'. Stop. make[1]: *** [inst_xtn] Error 2 make: *** [first] Error 2 rm v.strahler.tmp.html It looks like, when done, INST_XTN gets set to something other than "Y" and it tries to do a normal compile (thus trying to compile dependencies). Is there a particular reason for doing it this way, instead of having no extra make target and putting INST_XTN after make? To install the extension in a user-specified location: make INST_XTN=y GRASS_HOME=. MODULE_TOPDIR=/path/to/installed/grass RUN_GISBASE=/path/to/installed/grass INST_DIR_XTN=/path/to/user/xtn/ dir install On Sep 23, 2007, at 8:17 PM, Glynn Clements wrote: ... > > As for the rest of it, we're probably better off starting from basics. > > The following might all be independently variable (with example > locations): > > 1. Where to find the GRASS source tree (/usr/local/src/grass) > 2. Where to find the extension code which is being compiled (/usr/ > local/src/mygrassext) > 3. Where to find output files (/usr/local/src/grass// > OBJ.) > 4. Where to find "part-installed" files (/usr/local/src/grass/ > dist.) > 5. Where to find the installed version of GRASS (/usr/local/grass6.3) > 6. Where to put output files (/usr/local/src/grass// > OBJ.) > 7. Where to put "part-installed" files (/usr/local/src/grass/ > dist.) > 8. Where to install everything (/usr/local/grass6.3) > 9. Where to find the Makefile fragments. > > AFAICT, there are three main cases: > > A. Compiling GRASS from scratch. > B. Compiling additional modules on a system where a compiled GRASS > is already installed. > C. Compiling extensions on a system where a compiled GRASS is > already installed. > ... ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From glynn at gclements.plus.com Tue Oct 2 22:50:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 2 22:50:32 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> Message-ID: <18178.44820.362012.427184@cerise.gclements.plus.com> William Kyngesburye wrote: > > Is the "make" program GNU make? Does it come via Apple? Can you try > > building GNU make from the stock source package and using that? > > > > Prerequisites listed to the right of "|" are "order-only"; if > > necessary, they will be built before the target, but they won't cause > > the target to be re-compiled. > > > > If you're using something other than GNU make (which includes modified > > versions if the modifications make a difference), then I can't really > > help. I would rather not unconditionally run mkdir for every object > > file if it's an issue with one particular make program. > > > OSX Tiger/GCC 4 uses GNU Make 3.80. It doesn't look like Apple > modified it (like they have for other stuff). I have 3.81, and that's the only version for which I can find online documentation. Can you check the 3.80 documentation to ensure that order-only prerequisites are mentioned? They should be described in: 4 Writing Rules 4.3 Types of Prerequisites Other than that, I can only suggest re-building a directory with make debugging enabled (make -d ...). It can generate a lot of output, so pick the smallest case which demonstrates the problem (e.g. a module with only one source file). -- Glynn Clements From glynn at gclements.plus.com Tue Oct 2 23:52:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 2 23:52:21 2007 Subject: [GRASS-dev] installed makefile cleanup In-Reply-To: References: <18166.13927.743278.5512@cerise.gclements.plus.com> <6EABE0A5-9598-4014-9959-4F9D6F2474A4@kyngchaos.com> <18167.4130.819798.161922@cerise.gclements.plus.com> Message-ID: <18178.48530.383591.740860@cerise.gclements.plus.com> William Kyngesburye wrote: > I sortof understand this. Until you can work out the necessary > changes (if you decide to), how about some minimal changes to the the > extension compilation working? Unfortunately, use of the "get it working for now" approach is responsible for much of the current mess. I'd rather take the opportunity to improve matters than to make them worse. > Here are my revised changes to get it > working: > > - platform.make.in: > > RUN_GISBASE = ${ARCH_DISTDIR} > RUN_GISRC = ${RUN_GISBASE}/demolocation/.grassrc${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR} > > this allows those to be overridden together in the make step, yet > still keeps the same configured default for a source build. Seems okay. Although, this should be moved into Grass.make.in, as there are no substitutions. Platform.make.in should just be where configure dumps its output. On the same topic, the following substitutions in Grass.make.in should really go into Platform.make.in: LIB_PREFIX=@GRASS_LIB_PREFIX@ LIB_SUFFIX=@GRASS_LIB_SUFFIX@ GRASS_LIBRARY_TYPE=@GRASS_LIBRARY_TYPE@ The ones related to the version can stay. > - grass.make.in: add after "ifdef INST_NOW": > > ifdef INST_XTN > ARCH_INC = -I$(ARCH_DISTDIR)/include -I$(MODULE_TOPDIR)/include > ARCH_LIBPATH = -L$(ARCH_LIBDIR) -L$(MODULE_TOPDIR)/lib > endif > > to look for includes and libs in both the module source/dist and the > installed GRASS I would rather see additional variables, e.g.: ARCH_INC = -I$(ARCH_DISTDIR)/include -I$(GISBASE)/include ARCH_LIBPATH = -L$(ARCH_DISTDIR)/lib -L$(GISBASE)/lib where $(ARCH_DISTDIR) is where new files are "staged" and $(GISBASE) is where existing files are found. For normal compilation, the two would be equal. When extending an existing installation, $(GISBASE) would refer to the installation while $(ARCH_DISTDIR) refers to the build location. That would eliminate the need to conditionalise the settings. There are quite a few Makefiles which currently use $(GISBASE) instead of $(ARCH_DISTDIR), but that's relatively easy to fix. > - grass.make.in: add at end: > > ifdef INST_XTN > include $(MODULE_TOPDIR)/include/Make/Install_xtn.make > endif > > and have a new Install_xtn.make fragment. This is just a trimmed > version of the main makefile with just install targets and any > unnecessary bits removed. It expects INST_DIR_XTN to be set in the > make command. I'm not sure that this needs to be conditionalised. If there are parts of the top-level Makefile which might be useful to extensions, they should be moved into one of the *.make files (or a new file). In general, the *.make files should define as much as possible unconditionally, and leave it up to either individual Makefiles or the user to decide what actually gets used. > - module.make: for the bin/pgm and etc/pgm targets, conditionalize > the dependencies: > > ifdef INST_XTN > $(BIN)/$(PGM)$(EXE): $(ARCH_CMD_OBJS) > else > $(BIN)/$(PGM)$(EXE): $(ARCH_CMD_OBJS) $(DEPENDENCIES) > endif > > ... > > ifdef INST_XTN > $(ETC)/$(PGM)$(EXE): $(ARCH_CMD_OBJS) > else > $(ETC)/$(PGM)$(EXE): $(ARCH_CMD_OBJS) $(DEPENDENCIES) > endif > > since the dependencies are based off ARCH_LIBDIR, which will be in > the extension source dir, they won't be found. Actually, extensions are the easy case. Dependencies which are part of GRASS should use $(GISBASE), which would refer to the installed version. Dependencies which are part of the extension would use $(ARCH_DISTDIR). The case of extending an existing installation is more tricky, as you could have some of the dependencies in the installation and some in the staging directory (this assumes that you want to be able to build additional libraries, not just modules). But it's not that tricky; we can omit the path from the dependency and use the "vpath" directive, which allows multiple directories to be used for locating dependencies. IOW, GISDEP etc would lose the "$(ARCH_LIBDIR)/" prefix, and we would add e.g.: vpath %.$(LIB_SUFFIX) $(ARCH_LIBDIR):$(GISBASE)/lib [Apparently, we need to use a semicolon on (native) Windows.] In any case, the dependencies aren't critical. We don't actually build the dependencies if they're missing. It just means that if e.g. libgis failed to compile, we abandon trying to build modules straight away, rather than compiling all of the object files then having the linking stage fail. > Then, to compile an extension, cd to its source and: > > make INST_XTN=y GRASS_HOME=. MODULE_TOPDIR=/path/to/installed/grass > RUN_GISBASE=/path/to/installed/grass > > Note: I still had problems with having an inst_xtn: target (similar > to the inst_now target) and putting INST_XTN=y before make. No > infinite loop now, but after completing the compilation > (successfully) it exits with an error: I wouldn't bother with that kind of hack for now. Work on separating the variables so that it can handle mixing files from the installation with those from the extension, and getting the extension to compile into its staging directory. > /Applications/GRASS-6.3.app/Contents/MacOS/tools/mkhtml.sh > v.strahler ; mkdir -p ./dist.i686-apple-darwin8.10.1/docs/html ; /usr/ > bin/install -c -m 644 v.strahler.tmp.html ./dist.i686-apple- > darwin8.10.1/docs/html/v.strahler.html ; for file in *.png *.jpg ; > do head -n 1 $file | grep '^#!' > /dev/null ; if [ $? -ne 0 ] ; then / > usr/bin/install -c -m 644 $file ./dist.i686-apple-darwin8.10.1/docs/ > html ; fi done 2> /dev/null ; true > INST_XTN= make > make[2]: *** No rule to make target `dist.i686-apple-darwin8.10.1/lib/ > libgrass_display.dylib', needed by `dist.i686-apple-darwin8.10.1/bin/ > v.strahler'. Stop. > make[1]: *** [inst_xtn] Error 2 > make: *** [first] Error 2 > rm v.strahler.tmp.html > > It looks like, when done, INST_XTN gets set to something other than > "Y" and it tries to do a normal compile (thus trying to compile > dependencies). > > Is there a particular reason for doing it this way, instead of having > no extra make target and putting INST_XTN after make? AFAICT, the INST_NOW mechanism is designed to first build everything into the installation directory, then re-build (i.e. re-link) into the staging directory (dist.). Running: INST_NOW=y make runs make with INST_NOW=y. The first target which is found is: # first found target first: pre default @if test -n "$(INST_NOW)" ; then \ $(MAKE) inst_now ; \ fi This runs the pre and default targets (in parallel; "pre" should probably come first). Then, it runs "$(MAKE) inst_now", which runs: inst_now: INST_NOW= $(MAKE) IOW, the first pass has INST_NOW=y, while the second has INST_NOW empty. If you're using an identical mechanism with INST_XTN, the second pass is going to fail. -- Glynn Clements From glynn at gclements.plus.com Tue Oct 2 23:59:46 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 2 23:59:48 2007 Subject: [GRASS-dev] macosx compilation error in d.m In-Reply-To: <244A872E-6B84-4684-A20C-5291F205694E@uv.es> References: <18177.16022.290809.107029@cerise.gclements.plus.com> <16A3A4B9-D546-4CE4-99B6-8A3C4A19008B@uv.es> <18178.1982.456230.124187@cerise.gclements.plus.com> <244A872E-6B84-4684-A20C-5291F205694E@uv.es> Message-ID: <18178.48978.100046.301096@cerise.gclements.plus.com> Agustin Diez Castillo wrote: > > Can you clarify? Are you saying that even after "make distclean" and > > "configure", the problem with d.m.html doesn't always occur? > No it doesn't, I was clarifying that before the error occurred the > first time I had done "make distclean". > > Now I can compile with no errors but > > Generated HTML docs in ../dist.i686-apple-darwin8.10.1/docs/html/ > index.html > ---------------------------------------------------------------------- > Following modules are missing the 'description.html' file in src code: > d.m That message indicates that d.m.html was found but is missing the DESCRIPTION section. FWIW, I've since changed the way that the HTML files are generated; pattern rules are no longer used. I don't know if this will actually fix the problem, though. -- Glynn Clements From hamish_nospam at yahoo.com Wed Oct 3 08:07:09 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Oct 3 08:07:35 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> Message-ID: <20071003190709.a2156f76.hamish_nospam@yahoo.com> Frank Warmerdam wrote: > By default OSGeo SAC provides Trac+Subversion. If you want > substantially different services then it is likely that someone from > the GRASS team would need to volunteer to set it up and > maintain it. In this regard Intevation could be a better platform. > SAC is already somewhat stretched. Markus wrote: > the Wiki is not hosted by Intevation, but by GDF Hannover. and Markus largely is the soul who looks after the actual wiki software. So we use a community volunteer already, no change for us besides it makes it easier for others to help. FW: > By default OSGeo SAC provides Trac+Subversion. I notice that http://wiki.osgeo.org is using MediaWiki 1.6.3, admined by Arnulf Christl. http://wiki.osgeo.org/index.php/SAC:Primary_Administrators So perhaps in fact we do not require "substantially different services" after all? Given that, [In theory!, this is not a formal request!] is it possible without installing anything new* to set up a MediaWiki for http://grass.osgeo.org/wiki/ or http://wiki.osgeo.org/grass/ ? Sorry if I miss any nuances about how the OSGeo project hosting is meant to work. [*] our existing install is slightly newer, 1.6.10, so it might be good to update the OSGeo version before any migration. I don't know about MediaWiki's versioning, maybe all 1.6.x are backwards compatible with other 1.6.y and no update is needed?? n.b. We are having problems setting up the 'ConfirmEdit' captcha plugin with 1.6.10 (probably nothing to do with the MediaWiki version); we haven't tried reCaptcha as it requires version 1.8+; and upstream is at version 1.11. FW: > SAC is already somewhat stretched. Understood, and volunteering to help with any grass requests, if needed & in what capacity I can. For now we have a look at what the TracWiki can do. I'm just exploring the MediaWiki option because I personally like it and it is what we use already. thanks, Hamish From hamish_nospam at yahoo.com Wed Oct 3 08:24:31 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Oct 3 08:24:55 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN - GForge trackers fork In-Reply-To: <86782b610710021239j60fc77f7ga47f6d172056c9a0@mail.gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <4702780C.7080904@o2.pl> <470281B0.2040000@o2.pl> <86782b610710021239j60fc77f7ga47f6d172056c9a0@mail.gmail.com> Message-ID: <20071003192431.448b8a12.hamish_nospam@yahoo.com> > > Maciej Sieczka wrote: > > > The oustanding issue hampering the info flow is the > > > inability to CC from the GForge tracker > > > > I forgot to add that this can be workedaround by enabling > > *all* messages posted from the GForge trackers web form to > > be forwarded to GRASS dev list. Currently it is disabled > > (only the initial report is forwarded) as I was told this > > would be not welcome on such a high-traffic list. Now I'm > > thinking that maybe the extra traffic is worth it, when the > > stake is a better info flow? Please let me know what you think. Markus: > I think that the problem is the opposite: > grass-dev -> GForge doesn't work so that list follow-ups are lost. Right. The idea is that the bug ticket is the catch-all for information on the bug, not so much that grass-dev is kept up to date with every minor detail. A button on the web form to cc grass-dev list would be a nice feature if the person doing the update thought it is of interest to the wider community, but isn't critical or as lossy as the info never moving the other direction into the bug ticket. [this is just and idea and would take some coding..] The tracker would be subscribed to the -dev list, and would parse the message subjects for e.g. [issue #...] and file appropriately after stripping most email headers. To avoid spam the tracker software would ignore all email from any other address, and the existing grass-dev spam filters would ensure that no spam gets in. Hamish From tutey at o2.pl Wed Oct 3 08:48:03 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Oct 3 08:48:14 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN - GForge trackers fork In-Reply-To: <86782b610710021239j60fc77f7ga47f6d172056c9a0@mail.gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <4702780C.7080904@o2.pl> <470281B0.2040000@o2.pl> <86782b610710021239j60fc77f7ga47f6d172056c9a0@mail.gmail.com> Message-ID: <47033B23.2000101@o2.pl> Markus Neteler wrote: > On 10/2/07, Maciej Sieczka wrote: >> Maciej Sieczka wrote: >>> The oustanding issue hampering the info flow is the >>> inability to CC from the GForge tracker >> I forgot to add that this can be workedaround by enabling >> *all* messages posted from the GForge trackers web form to >> be forwarded to GRASS dev list. Currently it is disabled >> (only the initial report is forwarded) as I was told this >> would be not welcome on such a high-traffic list. Now I'm >> thinking that maybe the extra traffic is worth it, when the >> stake is a better info flow? Please let me know what you think. > I think that the problem is the opposite: > grass-dev -> GForge doesn't work so that list follow-ups are lost. As I have written in my previous post, it was suggested by Intevation that email reply to GForge trackers could be enabled. See the latest message on [1]. If this is done and I also switch on forwarding all messages entered to GForge trackers via the web form, information flow is saved. > This worked for RT well (beside the spam which wasn't caught > at RT while I manage to catch it entering grass-dev again, so > it's a matter of using a good spam filter - see old discussions). [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=85&group_id=1&atid=162 Maciek From tutey at o2.pl Wed Oct 3 08:59:03 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Oct 3 08:59:12 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN - GForge trackers fork In-Reply-To: <20071003192431.448b8a12.hamish_nospam@yahoo.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <4702780C.7080904@o2.pl> <470281B0.2040000@o2.pl> <86782b610710021239j60fc77f7ga47f6d172056c9a0@mail.gmail.com> <20071003192431.448b8a12.hamish_nospam@yahoo.com> Message-ID: <47033DB7.6070303@o2.pl> Hamish wrote: >>> Maciej Sieczka wrote: >>>> The oustanding issue hampering the info flow is the >>>> inability to CC from the GForge tracker >>> I forgot to add that this can be workedaround by >>> enabling *all* messages posted from the GForge >>> trackers web form to be forwarded to GRASS dev list. >>> Currently it is disabled (only the initial report is >>> forwarded) as I was told this would be not welcome on >>> such a high-traffic list. Now I'm thinking that maybe >>> the extra traffic is worth it, when the stake is a >>> better info flow? Please let me know what you think. > Markus: >> I think that the problem is the opposite: grass-dev -> >> GForge doesn't work so that list follow-ups are lost. > Right. The idea is that... Hamish, please read what I have written in the post before the one Markus replied to and in [1]. [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=85&group_id=1&atid=162 If Intevation are saying it is possible, we only have to ask them to do so. Maciek From glynn at gclements.plus.com Wed Oct 3 11:10:35 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Oct 3 11:10:43 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> Message-ID: <18179.23691.715738.76415@cerise.gclements.plus.com> William Kyngesburye wrote: > On Oct 2, 2007, at 3:50 PM, Glynn Clements wrote: > > > I have 3.81, and that's the only version for which I can find online > > documentation. > > > > Can you check the 3.80 documentation to ensure that order-only > > prerequisites are mentioned? They should be described in: > > > > 4 Writing Rules > > 4.3 Types of Prerequisites > > > Yep, it's there. > > > Other than that, I can only suggest re-building a directory with make > > debugging enabled (make -d ...). It can generate a lot of output, so > > pick the smallest case which demonstrates the problem (e.g. a module > > with only one source file). > > > > I picked the datetime lib (the first module I tried *didn't* recompile). Prerequisite `OBJ.i686-apple-darwin8.10.1' is newer than target `OBJ.i686-apple-darwin8.10.1/between.o'. Must remake target `OBJ.i686-apple-darwin8.10.1/between.o'. This suggests a bug with order-only dependencies. The whole point of order-only dependencies is that make only considers their existence; the timestamp is supposed to be ignored. > Interesting - on a closer look, it seems to be completely recompiling > libraries, but only relinking programs. That's with a make at the > top level. > > If I make an individual library, it also completely recompiles. But > re-making an individual program doesn't even relink, this seems to be > the only correct case. That's particularly strange. The only rule which has $(OBJDIR) as a prerequisite is the one to build object files (in Rules.make): # default cc rules $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR) $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ -o $(OBJDIR)/$*.o -c $*.c But that rule is used for libraries and modules alike. I have no idea why it would behave differently for libraries and for modules. Everything points to this being a "make" bug. Can you try with 3.81 to see if it happens there? Before that, can you try using "make -p" on both a library and a module? -- Glynn Clements From marchesini at unipg.it Wed Oct 3 11:30:50 2007 From: marchesini at unipg.it (ivan marchesini) Date: Wed Oct 3 11:21:54 2007 Subject: [GRASS-dev] v.net.strahler Message-ID: <1191403850.4792.26.camel@ivangeo> Dear Florian... I'm looking for a tool to calculate the strahler order of a network... is your module in grass addons updated??? I have seen it is written in c, but I have no experience with it... should I compile it as usual for new modules of grass??? thank you very much Ivan -- Ti prego di cercare di non inviarmi files .doc, .xls, .ppt, .dwg. Preferisco formati liberi. Please try to avoid to send me .doc, .xls, .ppt, .dwg files. I prefer free formats. http://it.wikipedia.org/wiki/Formato_aperto http://en.wikipedia.org/wiki/Open_format Ivan Marchesini Department of Civil and Environmental Engineering University of Perugia Via G. Duranti 93/a 06125 Perugia (Italy) e-mail: marchesini@unipg.it ivan.marchesini@gmail.com tel: +39(0)755853760 fax (university): +39(0)755853756 fax (home): +39(0)5782830887 jabber: geoivan73@jabber.org From woklist at kyngchaos.com Wed Oct 3 16:05:25 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Oct 3 16:05:35 2007 Subject: [GRASS-dev] installed makefile cleanup In-Reply-To: <18178.48530.383591.740860@cerise.gclements.plus.com> References: <18166.13927.743278.5512@cerise.gclements.plus.com> <6EABE0A5-9598-4014-9959-4F9D6F2474A4@kyngchaos.com> <18167.4130.819798.161922@cerise.gclements.plus.com> <18178.48530.383591.740860@cerise.gclements.plus.com> Message-ID: <4A15BF65-12E0-4F1D-A4BC-245113A2B3EF@kyngchaos.com> On Oct 2, 2007, at 4:52 PM, Glynn Clements wrote: > William Kyngesburye wrote: > >> I sortof understand this. Until you can work out the necessary >> changes (if you decide to), how about some minimal changes to the the >> extension compilation working? > > Unfortunately, use of the "get it working for now" approach is > responsible for much of the current mess. I'd rather take the > opportunity to improve matters than to make them worse. > OK. I guess I'm just being a bit impatient. So, you're working on this now? ;) Or will get to it? I think this can greatly simplify Benjamin's GEM, as well as allow external "extension" building. >> - grass.make.in: add at end: >> >> ifdef INST_XTN >> include $(MODULE_TOPDIR)/include/Make/Install_xtn.make >> endif >> >> and have a new Install_xtn.make fragment. This is just a trimmed >> version of the main makefile with just install targets and any >> unnecessary bits removed. It expects INST_DIR_XTN to be set in the >> make command. >> > > I'm not sure that this needs to be conditionalised. If there are parts > of the top-level Makefile which might be useful to extensions, they > should be moved into one of the *.make files (or a new file). > > In general, the *.make files should define as much as possible > unconditionally, and leave it up to either individual Makefiles or the > user to decide what actually gets used. Just to make sure: the main makefile's install target will override that makefile frag's install target, in a normal build, since the main makefile defines it after this frag is included? ----- 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 From woklist at kyngchaos.com Wed Oct 3 16:33:41 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Oct 3 16:33:51 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <18179.23691.715738.76415@cerise.gclements.plus.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> <18179.23691.715738.76415@cerise.gclements.plus.com> Message-ID: <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> On Oct 3, 2007, at 4:10 AM, Glynn Clements wrote: > But that rule is used for libraries and modules alike. I have no idea > why it would behave differently for libraries and for modules. > > Everything points to this being a "make" bug. Can you try with 3.81 to > see if it happens there? > 3.81 works. There were a couple rebuilds, but that may have been from earlier rebuilds, like sqlp. I verified by building 3.80 from source (complete rebuild, so Apple didn't do anything to make). So, looks like there may have been some bugs in 3.80. But, your average Mac user is not going to want to install a current make. And, since Markus had the same problem, there may be Linux distros that have an older make in their package manager. > Before that, can you try using "make -p" on both a library and a > module? > I remembered to zip it this time :) -------------- next part -------------- A non-text attachment was scrubbed... Name: makedb.txt.zip Type: application/zip Size: 12558 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071003/20c1e639/makedb.txt-0001.zip -------------- next part -------------- ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From warmerdam at pobox.com Wed Oct 3 16:33:57 2007 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Oct 3 16:34:02 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <20071003190709.a2156f76.hamish_nospam@yahoo.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> <20071003190709.a2156f76.hamish_nospam@yahoo.com> Message-ID: <931f8ea90710030733r61bcfdcfm1712c5955236bf70@mail.gmail.com> On 10/2/07, Hamish wrote: > Given that, [In theory!, this is not a formal request!] is it possible > without installing anything new* to set up a MediaWiki for > http://grass.osgeo.org/wiki/ or http://wiki.osgeo.org/grass/ ? Hamish, I anticipate no problem adminstering a mediawiki instance at OSGeo for GRASS. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From glynn at gclements.plus.com Wed Oct 3 19:28:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Oct 3 19:28:13 2007 Subject: [GRASS-dev] installed makefile cleanup In-Reply-To: <4A15BF65-12E0-4F1D-A4BC-245113A2B3EF@kyngchaos.com> References: <18166.13927.743278.5512@cerise.gclements.plus.com> <6EABE0A5-9598-4014-9959-4F9D6F2474A4@kyngchaos.com> <18167.4130.819798.161922@cerise.gclements.plus.com> <18178.48530.383591.740860@cerise.gclements.plus.com> <4A15BF65-12E0-4F1D-A4BC-245113A2B3EF@kyngchaos.com> Message-ID: <18179.53546.241320.569094@cerise.gclements.plus.com> William Kyngesburye wrote: > >> I sortof understand this. Until you can work out the necessary > >> changes (if you decide to), how about some minimal changes to the the > >> extension compilation working? > > > > Unfortunately, use of the "get it working for now" approach is > > responsible for much of the current mess. I'd rather take the > > opportunity to improve matters than to make them worse. > > OK. I guess I'm just being a bit impatient. > > So, you're working on this now? ;) Or will get to it? The latter. I have "Makefile fatigue" right now, and I want to allow people to find any bugs in the most recent bunch of changes. > >> - grass.make.in: add at end: > >> > >> ifdef INST_XTN > >> include $(MODULE_TOPDIR)/include/Make/Install_xtn.make > >> endif > >> > >> and have a new Install_xtn.make fragment. This is just a trimmed > >> version of the main makefile with just install targets and any > >> unnecessary bits removed. It expects INST_DIR_XTN to be set in the > >> make command. > > > > I'm not sure that this needs to be conditionalised. If there are parts > > of the top-level Makefile which might be useful to extensions, they > > should be moved into one of the *.make files (or a new file). > > > > In general, the *.make files should define as much as possible > > unconditionally, and leave it up to either individual Makefiles or the > > user to decide what actually gets used. > > Just to make sure: the main makefile's install target will override > that makefile frag's install target, in a normal build, since the > main makefile defines it after this frag is included? GRASS' top-level Makefile only includes Grass.make and Platform.make. It doesn't include any of the other *.make fragments. In general, try to avoid relying upon overriding rules which are defined in the *.make files. Sometimes, overriding rules is unavoidable (e.g. some modules which don't understand --html-description have to override the htmletc target), but it's best not to rely upon it. Apart from printing a warning (which adds "noise" to the build output), if the two versions have both dependencies and commands, the dependencies get merged (sometimes in ways which make the value of $< etc unpredictable) but the commands get overridden. Also, whenever the generic rule is updated, you often end up having to manually update any local versions. [E.g. I've just extended the "clean" rule to allow a list of subdirectories to be specified as CLEAN_SUBDIRS. Previously, r.terraflow, r.le.setup and v.clean were overriding the clean target to handle subdirectories, which meant that they weren't deleting the $(PGM).tmp.html file.] -- Glynn Clements From glynn at gclements.plus.com Wed Oct 3 20:10:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Oct 3 20:10:53 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> <18179.23691.715738.76415@cerise.gclements.plus.com> <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> Message-ID: <18179.56105.931632.839661@cerise.gclements.plus.com> William Kyngesburye wrote: > > But that rule is used for libraries and modules alike. I have no idea > > why it would behave differently for libraries and for modules. > > > > Everything points to this being a "make" bug. Can you try with 3.81 to > > see if it happens there? > > 3.81 works. There were a couple rebuilds, but that may have been > from earlier rebuilds, like sqlp. I verified by building 3.80 from > source (complete rebuild, so Apple didn't do anything to make). > > So, looks like there may have been some bugs in 3.80. But, your > average Mac user is not going to want to install a current make. A "user" won't care about incremental rebuilds not actually being incremental. They'll "configure; make; make install" then not compile it again (at least, not without [dist]clean first). > And, since Markus had the same problem, there may be Linux distros > that have an older make in their package manager. I missed that. > > Before that, can you try using "make -p" on both a library and a > > module? > > I remembered to zip it this time :) That has the advantage that your message also gets posted to the list rather than being bounced for being too large. Your output has: # Implicit Rules OBJ.i686-apple-darwin8.10.1/%.o: %.c OBJ.i686-apple-darwin8.10.1 # commands to execute (from `../../include/Make/Rules.make', line 23): $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ -o $(OBJDIR)/$*.o -c $*.c while for "make -n -p -C lib/datetime" I get: # Implicit Rules OBJ.i686-pc-linux-gnu/%.o: %.c | OBJ.i686-pc-linux-gnu # commands to execute (from `../../include/Make/Rules.make', line 21): $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ -o $(OBJDIR)/$*.o -c $*.c Note the vertical bar is missing from yours. Can you try the same thing with a module (which doesn't re-compile everything)? If the vertical bar is present for modules and missing for libraries, It may be worth changing the placement of the "include .../Rules.make" in the Lib.make and Module.make files, to see if there's some combination that consistently avoids the bug. I don't particularly want to build $(OBJDIR) "transparently" as part of the %.o:%.c rule, as there is a race condition with parallel builds (multiple processes may try to build the directory concurrently; mkdir considers this a failure). Also, it may be a performance issue on Cygwin. Cygwin's directory operations are extremely inefficient; on a P4/3000, it's quicker to mount the drive via SMB to my P3/800 Linux box and run find/ls/etc there than it is to run the Cygwin versions locally. -- Glynn Clements From rez at touchofmadness.com Wed Oct 3 20:15:18 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Wed Oct 3 20:15:23 2007 Subject: [GRASS-dev] BLAS/LAPACK detection (was: configure fails) In-Reply-To: <18173.6218.121204.633151@cerise.gclements.plus.com> References: <1389.85.10.67.113.1190573958.squirrel@geog-pc40.ulb.ac.be> <1190582634.4349.22.camel@dev64.localdomain> <18171.48522.435225.984210@cerise.gclements.plus.com> <1190955520.4349.245.camel@dev64.localdomain> <18172.49308.435792.213235@cerise.gclements.plus.com> <1190987806.4349.270.camel@dev64.localdomain> <18173.6218.121204.633151@cerise.gclements.plus.com> Message-ID: <1191435318.3194.313.camel@dev64.localdomain> On Fri, 2007-09-28 at 16:05 +0100, Glynn Clements wrote: > Brad Douglas wrote: > > > > > > 1. --with-gfortran should default to "no". The only things which > > > > > should default to yes are those which most users will have and want. > > > > > > > > I'm under the impression that most users have upgraded to GCC >= 4.x. > > > > The reason that the option exists at all is because of autoconf-2.13 > > > > limitations. > > > > > > > > Suggestions are welcome. > > > > > > Regardless of which GCC version people are using (I'm using 3.4.6), > > > there's no need for either --with-g77 or --with-gfortran to be enabled > > > by default. > > > > > > And unless there's some Fortran code still in GRASS (I can't see any), > > > I don't see any need for those options to exist. The AC_CHECK_PROGS > > > for g77/f77 was commented out when we no longer included any Fortran > > > code. 5.3 has some, but 6.x doesn't (AFAICT). > > > > There is not Fortran code in the tree (but I was keeping the option open > > as previously noted). Change committed. > > FWIW, the committed configure and configure.in scripts didn't match > (configure.in had --with-gfortran default to "no", but the actual > configure script still defaulted to "yes"). I have regenerated > configure and committed it (just in case you were wondering what the > change was). FYI, I've been letting others (Markus) commit changes to 'configure'. I don't trust autoconf enough on x86_64 to commit it myself. I should really do a comparison to see if my concerns are without merit. > > > > > LOC_CHECK_INCLUDES() can take a fourth argument comprising code to be > > > > > executed if the check fails. If no such argument is given, a fatal > > > > > error is generated. > > > > > > > > Okay. That helps. I didn't trace through all of the substitutions of > > > > the LOC_() macros and there is almost no documentation. > > > > > > If you only need to set a HAVE_FOO_H macro in config.h, use > > > AC_CHECK_HEADERS instead. > > > > > > LOC_CHECK_INCLUDES is designed for the situation where a header is > > > mandatory. The fourth argument is designed so that you can nest checks > > > for alternate headers (see the FFTW and GLw checks for examples), with > > > a fatal error if none of the alternatives are found. > > > > I do need to set macros in config.h if certain headers are found, but > > without fatalities if they are not. > > Right; AC_CHECK_HEADERS is most suitable for that. For the public record, it is being discussed offline. > > > > I wanted to leave the possibility open, but no, it is not specifically > > > > needed at the present time. > > > > > > Right. If we do ever find a use for a Fortran compiler, the checks > > > should be orthogonal to those required to use Fortran-based libraries > > > (e.g. LAPACK). > > > > Trying to make gfortran work with autoconf-2.13 is a kludge at best. > > Maybe I should remove Fortran entirely? I don't see much possibility > > for using it in the future. > > I wouldn't complicate configure.in with checks for something we aren't > actually using. > > Given our relatively low level of manpower compared to the size of the > code base, we should be more agressive about getting rid of "dead > wood", IMHO. In the event that some old code turns out to be useful to > someone, they can always dig it out of CVS. Noted. I've removed all "might get used in the future" code. > > > Now that other databases can be used, and the option only affects > > > compilation of the actual database driver, it could probably be turned > > > off by default. OTOH, maybe that should wait for 7.x.] > > > > Simply switching the default in configure.in doesn't need to wait for > > 7.x. > > My main concern is that people won't notice that they have suddenly > stopped getting PostgreSQL support until they actually need to use it > and find that it isn't there. In 6.2.x, keep status quo, but I would prefer to turn it off for >= 6.3. PostgreSQL is completely optional. -- 73, de Brad KB8UYR/6 From florian.kindl at uibk.ac.at Wed Oct 3 20:59:04 2007 From: florian.kindl at uibk.ac.at (Florian Kindl) Date: Wed Oct 3 21:13:03 2007 Subject: [GRASS-dev] v.net.strahler In-Reply-To: <1191403850.4792.26.camel@ivangeo> References: <1191403850.4792.26.camel@ivangeo> Message-ID: <20071003185903.GA27692@uibk.ac.at> On Oct 03 [11:30], ivan marchesini wrote: > I'm looking for a tool to calculate the strahler order of a network... > is your module in grass addons updated??? Hi Ivan, the module is rather abandoned than updated. I basically stopped the effort after I saw that it was not what I needed. > I have seen it is written in c, but I have no experience with it... > should I compile it as usual for new modules of grass??? The code is there, waiting for a C wizard to fix some issues, especially outputting to a cat-layer rather than a text file. I didn't manage to make that work, but what is there, should compile, at least. sincelery, FK -- Mag. Florian Kindl Institute of Geography University of Innsbruck -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071003/9c48eec6/attachment.bin From benjamin.ducke at ufg.uni-kiel.de Wed Oct 3 21:13:10 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Wed Oct 3 21:13:14 2007 Subject: [GRASS-dev] Re: [GRASS-user] [off-topic] spoke too soon In-Reply-To: <200710031200.53551.dylan.beaudette@gmail.com> References: <200710031007.27836.dylan.beaudette@gmail.com> <4703DCA8.8090907@ufg.uni-kiel.de> <200710031200.53551.dylan.beaudette@gmail.com> Message-ID: <4703E9C6.7050707@ufg.uni-kiel.de> [taking this over to the devel list] Parsing GRASS colour rules is very simple. It's all in the GRASS Programmer's Manual. Full docs for CPT format are here: http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node58.html (section 4.15 of the GMT docs) Apparently, GMT supports HSV schemes, as well. QUESTIONS: 1. Does GRASS also support colour models other than RGB? 2. Is '%" treated like a comment in the GRASS 'colr' files? 3. Is '#' as a comment indicator also OK in 'colr' files? 4. GMT also has labels for colour ranges. Would it be a good idea to transfer those to the raster file (given that there is no category labelling already or the user chooses to overwrite it)? Benjamin Dylan Beaudette wrote: > On Wednesday 03 October 2007, Benjamin Ducke wrote: >> Good stuff >> >> All the palettes are available in GMT color format, which is just plain >> ASCII and very similar to GRASS' own colour rule files in the 'cols' >> database elements. The only major difference seems to be three >> additional lines at the end of the file specifying colours for >> foreground, background and no data areas which could simply be >> discarded. > > Indeed. Will have to poke around in the r.colors source -- anyone an expert on > how the rules file is parsed? > >> So how about adding an option cpt=filename to r.colors, to set the >> color rules for a raster map from a GMT ASCII file? > > I think that this would be a great addition. The GMT folks might like it as > well. > >> The best of these styles could still be hardcoded into r.colors' >> database. > > Agreed. > >> Benjamin >> >> >> P.S.: Some of these palettes actually have licenses attached to them. >> What sort of a world do we live in that requires the most trivial >> things to be licensed? Come on people, you can give _some_ things to >> the public domain w/o conditions ... > > My thoughts exactly- however you are going to have to pay-up if you decide to > implement this idea! j/k > > Dylan > >> Dylan Beaudette wrote: >>> Sorry about those last two messages. My fingers where too fast for my >>> brain, and inadvertently caused the keys ctrl-enter to be pressed (curse >>> you Kmail!). >>> >>> What I had tried to mention was the collection of color palette files >>> here: >>> >>> http://sview01.wiredworkplace.net/pub/cpt-city/ >>> >>> Perhaps we can convert a pile of these into GRASS-compatible color rules >>> files. >>> >>> Cheers, >>> >>> Dylan > > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From woklist at kyngchaos.com Wed Oct 3 21:54:18 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Oct 3 21:54:30 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <18179.56105.931632.839661@cerise.gclements.plus.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> <18179.23691.715738.76415@cerise.gclements.plus.com> <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> <18179.56105.931632.839661@cerise.gclements.plus.com> Message-ID: <93BB1547-A2A6-4C7A-A5D0-29DE1509AB15@kyngchaos.com> On Oct 3, 2007, at 1:10 PM, Glynn Clements wrote: > A "user" won't care about incremental rebuilds not actually being > incremental. They'll "configure; make; make install" then not compile > it again (at least, not without [dist]clean first). > True. If it's unfixable, I can keep using the current up-to-date make. We'd have to recommend to other devs to update their make. >> And, since Markus had the same problem, there may be Linux distros >> that have an older make in their package manager. > > I missed that. > http://grass.itc.it/pipermail/grass-dev/2007-October/033237.html > Note the vertical bar is missing from yours. Can you try the same > thing with a module (which doesn't re-compile everything)? > It's also missing the pipe: -------------- next part -------------- A non-text attachment was scrubbed... Name: makedb_mod.txt.zip Type: application/zip Size: 11907 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071003/2846342c/makedb_mod.txt-0001.zip -------------- next part -------------- I preceded the pipe with a backslash in Rules.make - now it keeps the pipe and libraries aren't recompiled. But, this doesn't work in 3.81, so it doesn't look like a usable solution. ----- 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 From hamish_nospam at yahoo.com Thu Oct 4 07:20:00 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Oct 4 07:20:07 2007 Subject: [GRASS-dev] Re: [GRASS-user] [off-topic] spoke too soon In-Reply-To: <4703E9C6.7050707@ufg.uni-kiel.de> References: <200710031007.27836.dylan.beaudette@gmail.com> <4703DCA8.8090907@ufg.uni-kiel.de> <200710031200.53551.dylan.beaudette@gmail.com> <4703E9C6.7050707@ufg.uni-kiel.de> Message-ID: <20071004182000.594c022e.hamish_nospam@yahoo.com> Benjamin Ducke wrote: > 1. Does GRASS also support colour models other than RGB? AFAIK, no. (but see r.his, d.his, d.rgb, i.his.rgb, i.rgb.his, ...) CMYK is not supported. (but you can process the 4 channels as 4 different n-bit CELL raster maps if you like) > 2. Is '%" treated like a comment in the GRASS 'colr' files? No. > 3. Is '#' as a comment indicator also OK in 'colr' files? Yes. Blank lines are ok too. currently lib/gis/color_rules.c uses fgets(), so only UNIX newlines are accepted. Any reason not to make that use G_getl2()? > 4. GMT also has labels for colour ranges. Would it be a good > idea to transfer those to the raster file (given that there > is no category labelling already or the user chooses to > overwrite it)? an interesting idea, but let's get the color table working first before we worry about that too much. (I'm working on a proof of concept shell script first) Hamish From hamish_nospam at yahoo.com Thu Oct 4 08:37:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Oct 4 08:37:16 2007 Subject: [GRASS-dev] Re: [GRASS-user] [off-topic] spoke too soon In-Reply-To: <20071004182000.594c022e.hamish_nospam@yahoo.com> Message-ID: <757518.162.qm@web52705.mail.re2.yahoo.com> Hamish wrote: > > 2. Is '%" treated like a comment in the GRASS 'colr' files? > > No. > > > 3. Is '#' as a comment indicator also OK in 'colr' files? > > Yes. Blank lines are ok too. Oh sorry, I was talking about input color rules files, not colr/ files. Let the libgis fns deal with colr/, we shouldn't touch them. We use "r.colors rules=filename" instead. I now have a working .cpt -> grass color rules file, it will either output to a ascii file, stdout, &/or apply them to an existing raster map. I am working on a stretch flag as the GMT rules seem randomly to use ranges of -1 to 1 or 0.0 to 1.0, or 0 to 32, etc. and only the global elevation in meters rules are currently of use (but they look nice!) Hamish ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From michael.barton at asu.edu Thu Oct 4 08:46:31 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Oct 4 08:46:38 2007 Subject: [GRASS-dev] Re: [GRASS-user] [off-topic] spoke too soon In-Reply-To: <4703E9C6.7050707@ufg.uni-kiel.de> Message-ID: Please see below On 10/3/07 12:13 PM, "Benjamin Ducke" wrote: > [taking this over to the devel list] > > Parsing GRASS colour rules is very simple. It's all in the > GRASS Programmer's Manual. > > Full docs for CPT format are here: > > http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node58.html > > (section 4.15 of the GMT docs) > > Apparently, GMT supports HSV schemes, as well. > > QUESTIONS: > > 1. Does GRASS also support colour models other than RGB? GRASS color names (e.g., red, blue, yellow) > 2. Is '%" treated like a comment in the GRASS 'colr' files? It is treated like a percent. 0% black 50% red 100% green is translated as make the lowest (0%) value black and grade to red at the median value (50%), then continue to grade to blue to the highest value (100%) > 3. Is '#' as a comment indicator also OK in 'colr' files? I don't think this is accepted. But try and see. > 4. GMT also has labels for colour ranges. Would it be a good > idea to transfer those to the raster file (given that there > is no category labelling already or the user chooses to > overwrite it)? Not sure what you mean here. Replace the label value with the RBG value? Michael > > Benjamin > > Dylan Beaudette wrote: >> On Wednesday 03 October 2007, Benjamin Ducke wrote: >>> Good stuff >>> >>> All the palettes are available in GMT color format, which is just plain >>> ASCII and very similar to GRASS' own colour rule files in the 'cols' >>> database elements. The only major difference seems to be three >>> additional lines at the end of the file specifying colours for >>> foreground, background and no data areas which could simply be >>> discarded. >> >> Indeed. Will have to poke around in the r.colors source -- anyone an expert >> on >> how the rules file is parsed? >> >>> So how about adding an option cpt=filename to r.colors, to set the >>> color rules for a raster map from a GMT ASCII file? >> >> I think that this would be a great addition. The GMT folks might like it as >> well. >> >>> The best of these styles could still be hardcoded into r.colors' >>> database. >> >> Agreed. >> >>> Benjamin >>> >>> >>> P.S.: Some of these palettes actually have licenses attached to them. >>> What sort of a world do we live in that requires the most trivial >>> things to be licensed? Come on people, you can give _some_ things to >>> the public domain w/o conditions ... >> >> My thoughts exactly- however you are going to have to pay-up if you decide to >> implement this idea! j/k >> >> Dylan >> >>> Dylan Beaudette wrote: >>>> Sorry about those last two messages. My fingers where too fast for my >>>> brain, and inadvertently caused the keys ctrl-enter to be pressed (curse >>>> you Kmail!). >>>> >>>> What I had tried to mention was the collection of color palette files >>>> here: >>>> >>>> http://sview01.wiredworkplace.net/pub/cpt-city/ >>>> >>>> Perhaps we can convert a pile of these into GRASS-compatible color rules >>>> files. >>>> >>>> Cheers, >>>> >>>> Dylan >> >> >> __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Thu Oct 4 11:20:44 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Oct 4 11:20:49 2007 Subject: [GRASS-dev] GMT color tables & r.colors bug Message-ID: <20071004222044.095fc3b0.hamish_nospam@yahoo.com> Hi, I have now put my GMT color table importing shell script up on the wiki addons site. I called it r.cpt2grass (suggestions for a better name are welcome) http://grass.gdf-hannover.de/wiki/GRASS_AddOns#Raster_add-ons There seems to be a bug in r.colors in 6.2 and 6.3. e.g. for a CELL map containing values of [0-255], if the rules file looks like this: 0% 0:0:0 37.5% 255:0:0 37.5% 255:0:0 75% 255:255:0 75% 255:255:0 100% 255:255:255 the colr/ file looks like this: % 0 191.25 0:0 95.625:255:0:0 95.625:255:0:0 191.25:255:255:0 ie the last 100% rule is forgotten. Same if I give it real values: G63> r.colors gebco_bathy col=rules << EOF > 0 0:0:0 95.625 255:0:0 > 95.625 255:0:0 191.25 255:255:0 > 191.25 255:255:0 255 255:255:255 > EOF WARNING: Your color rules do not cover the whole range of data! (rules 0.000000 to 191.250000 but data 0.000000 to 255.000000) ??? the usual way to give percentage is typically 1 rule per line, which is why we haven't noticed this before: 0% 0:0:0 37.5% 255:0:0 75% 255:255:0 100% 255:255:255 GEBCO data + GMT_haxby.cpt looks pretty cool. HSV is not supported, for that we'd need some small m.hsv2rgb module or utility in $GISBASE/etc/. (with a reverse transform flag) example C++ code: (unknown license) http://ilab.usc.edu/wiki/index.php/HSV_And_H2SV_Color_Space There are a couple of nice GMT color tables that use HSV. CMYK is defined in the spec, but I haven't come across anything that uses it yet. And I have not seen any that use labels either, so won't worry about that for now. enjoy, Hamish ps- GRASS> r.cpt2grass --help Description: Convert or apply a GMT color table to a GRASS raster map Usage: r.cpt2grass [-s] input=string [map=string] [output=string] [--verbose] [--quiet] Flags: -s Stretch color scale to match map data extent Parameters: input Name of input GMT color table (.cpt file) map Raster map to apply it to output Name for new rules file, or "-" for stdout From hamish_nospam at yahoo.com Thu Oct 4 11:32:31 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Oct 4 11:32:36 2007 Subject: [GRASS-dev] call for more screenshots Message-ID: <20071004223231.cdae5100.hamish_nospam@yahoo.com> Hi, the new screenshots page is coming along well I think. The front page is pretty much done. http://grass.itc.it/screenshots/ (probably nothing new there if you looked last time) I've gotten sidetracked so haven't done anymore populating it, but thanks to the folks who have sent suggestions already. I haven't forgotten those (yet :), I'll get to them soon. For anyone else who has some ideas, please help out by posting URLs and images directly to this page on the wiki: http://grass.gdf-hannover.de/wiki/Screenshot_suggestions It's much less likely to get forgotten if it is posted there. >From there we can clean them up and move them over to the main website. thanks, Hamish From glynn at gclements.plus.com Thu Oct 4 13:02:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Oct 4 13:02:20 2007 Subject: [GRASS-dev] Re: [GRASS-user] [off-topic] spoke too soon In-Reply-To: <4703E9C6.7050707@ufg.uni-kiel.de> References: <200710031007.27836.dylan.beaudette@gmail.com> <4703DCA8.8090907@ufg.uni-kiel.de> <200710031200.53551.dylan.beaudette@gmail.com> <4703E9C6.7050707@ufg.uni-kiel.de> Message-ID: <18180.51258.18413.923193@cerise.gclements.plus.com> Benjamin Ducke wrote: > [taking this over to the devel list] > > Parsing GRASS colour rules is very simple. It's all in the > GRASS Programmer's Manual. > > Full docs for CPT format are here: > > http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node58.html > > (section 4.15 of the GMT docs) > > Apparently, GMT supports HSV schemes, as well. > > QUESTIONS: > > 1. Does GRASS also support colour models other than RGB? No. It supports R/G/B, or a single (monochrome) intensity, or a named colour. Converting HSV->RGB on input won't produce the same result if GMT interpolates the values in HSV space. Extending the core GRASS colour handling to allow HSV colour rules isn't feasible, IMHO. If you want to import HSV colour tables, the segments will need to be subdivided to an adequate resolution. > 2. Is '%" treated like a comment in the GRASS 'colr' files? > 3. Is '#' as a comment indicator also OK in 'colr' files? The format of "colr" files isn't relevant. Those files are read and written by libgis; the file format isn't considered a public interface. The input format used by r.colors (lib/gis/color_rules.c) is considered a public interface. That format uses # for comments, while % is used for percentages. > 4. GMT also has labels for colour ranges. Would it be a good > idea to transfer those to the raster file (given that there > is no category labelling already or the user chooses to > overwrite it)? Maybe, but that isn't the job of r.colors; if you want to add that feature, create a separate module (which could import both the colour and label information). -- Glynn Clements From glynn at gclements.plus.com Thu Oct 4 13:53:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Oct 4 13:54:01 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <93BB1547-A2A6-4C7A-A5D0-29DE1509AB15@kyngchaos.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> <18179.23691.715738.76415@cerise.gclements.plus.com> <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> <18179.56105.931632.839661@cerise.gclements.plus.com> <93BB1547-A2A6-4C7A-A5D0-29DE1509AB15@kyngchaos.com> Message-ID: <18180.54358.477131.681551@cerise.gclements.plus.com> William Kyngesburye wrote: > > Note the vertical bar is missing from yours. Can you try the same > > thing with a module (which doesn't re-compile everything)? > > It's also missing the pipe: It's missing, but that case *doesn't* recompile everything? Ugh; this is getting confusing. > I preceded the pipe with a backslash in Rules.make - now it keeps the > pipe and libraries aren't recompiled. But, this doesn't work in > 3.81, so it doesn't look like a usable solution. Okay, how about this: # default cc rules ifeq ($(MAKE_VERSION),3.81) $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR) $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ -o $(OBJDIR)/$*.o -c $*.c else $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) $(MAKE) $(OBJDIR) $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ -o $(OBJDIR)/$*.o -c $*.c endif ? This is less than ideal, as it will revert to the old form for 3.82, but I can't think of a simple way to check for >= 3.81 (especially considering that the version might not actually be a number, e.g. 3.81-r1 or similar). -- Glynn Clements From glynn at gclements.plus.com Thu Oct 4 14:41:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Oct 4 14:41:06 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <18178.32819.389941.767440@cerise.gclements.plus.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> Message-ID: <18180.57184.640351.718493@cerise.gclements.plus.com> Glynn Clements wrote: > sqlp *might* be due to lex/yacc issues (that's the only part that's > different from other libraries). It was due to lex/yacc issues. > If yacc is being re-run, y.tab.h will > be updated, which will force the rest of it to be compiled. What was happening is that Rules.make has: ifndef LOCAL_HEADERS LOCAL_HEADERS = $(wildcard *.h) endif and: $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR) On initial compilation, y.tab.h doesn't exist, so it isn't included in $(LOCAL_HEADERS). [This is a common pitfall of using $(wildcard ...). It only returns what exists right now, omitting files which may be generated later.] If $(OBJDIR)/y.tab.o isn't the first object file, then y.tab.h may[1] end up being newer than some of the object files. On a second run, y.tab.h is now a dependency for all object files, so any which are older than y.tab.h will be re-compiled. [1] File timestamps typically have a resolution of one second, so it's probabilistic as to whether it's actually older. The fix was to add $(EXTRA_HEADERS) as a dependency of $(OBJDIR)/%.o, so that y.tab.h can be added even when it doesn't exist. This will force y.tab.h to be generated before any of the object files, so y.tab.h will be older. -- Glynn Clements From woklist at kyngchaos.com Thu Oct 4 16:27:03 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Oct 4 16:27:19 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <18180.54358.477131.681551@cerise.gclements.plus.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> <18179.23691.715738.76415@cerise.gclements.plus.com> <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> <18179.56105.931632.839661@cerise.gclements.plus.com> <93BB1547-A2A6-4C7A-A5D0-29DE1509AB15@kyngchaos.com> <18180.54358.477131.681551@cerise.gclements.plus.com> Message-ID: <4CF13205-3E3A-4BA3-BA27-5CDC05E1046A@kyngchaos.com> On Oct 4, 2007, at 6:53 AM, Glynn Clements wrote: > William Kyngesburye wrote: > >>> Note the vertical bar is missing from yours. Can you try the same >>> thing with a module (which doesn't re-compile everything)? >> >> It's also missing the pipe: > > It's missing, but that case *doesn't* recompile everything? Ugh; this > is getting confusing. Indeed, very strange. Odd that it took them 4 years to release 3.81 with that fixed. >> I preceded the pipe with a backslash in Rules.make - now it keeps the >> pipe and libraries aren't recompiled. But, this doesn't work in >> 3.81, so it doesn't look like a usable solution. > > Okay, how about this: > > # default cc rules > ifeq ($(MAKE_VERSION),3.81) > $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) | $(OBJDIR) > $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ > -o $(OBJDIR)/$*.o -c $*.c > else > $(OBJDIR)/%.o : %.c $(LOCAL_HEADERS) > $(MAKE) $(OBJDIR) > $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(EXTRA_INC) $(INC) \ > -o $(OBJDIR)/$*.o -c $*.c > endif > > ? > > This is less than ideal, as it will revert to the old form for 3.82, > but I can't think of a simple way to check for >= 3.81 (especially > considering that the version might not actually be a number, e.g. > 3.81-r1 or similar). That works, but ugly and doesn't cover the future is probably not what we want to do. (I saw some .1 versions in the make downloads) I'd be happy with the unconditional pipe and recommending to developers to upgrade their make and not worrying about the 1-shot user builds. Markus: have you been following this? What's your make version, and does your linux package manager have a new version? Or is it otherwise easily updated? I wonder what version other linux distros are at? ----- 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 From grass-bugs at intevation.de Thu Oct 4 17:19:27 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Thu Oct 4 17:19:28 2007 Subject: [GRASS-dev] [bug #1470] (grass) full floats support for r.colors, please Message-ID: <20071004151927.3E304602A2E@lists.intevation.de> guest wrote (Thu, Dec 5 2002 12:34:54): > Wouldn't it be awfully nice to have r.colors color=grey.eq|grey.log|random etc > working for rasters of floats? Glynn added flags -e and -g to to r.colors few weeks ago, which allow to equalize any color table now, and floating point rasters are supported too. An outstanding issue is 'random' colortable for floating point rasters. I don't if this is possible. Still only integer rasters are supported. Maciek -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Thu Oct 4 18:38:23 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Oct 4 18:40:50 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <18167.5602.661916.834459@cerise.gclements.plus.com> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> Message-ID: <470516FF.9030606@club.worldonline.be> On 24/09/07 03:41, Glynn Clements wrote: > Moritz Lennert wrote: > >>> My next suggestion is to re-write xdr_stdio to use read() and write() >>> instead of fread() and fwrite(), e.g.: >>> >>> - if (fread((caddr_t)lp, sizeof(long), 1, (FILE *)xdrs->x_private) != 1) >>> + if (read(fileno((FILE *)xdrs->x_private), (caddr_t)lp, sizeof(long)) != >>> sizeof(long)) >> That seems to work ! > > Now that's strange. I was expecting it to provide more information on > the errors, not to work. > > On Unix, read/write can return short counts on pipes. If a process > tries to write 4 bytes to a pipe, and there's only enough space for 2 > bytes, write() will return 2 rather than waiting for the pipe to > drain. Similarly if you try to read more data than is available in the > pipe. > > If you want to block until the requested amount of data has been read > or written, you need to either use readn/writen (which are > non-standard), or implement them yourself, e.g.: > > ssize_t readn(int fd, void *buf, size_t count) > { > ssize_t total = 0; > > while (total < count) > { > ssize_t n = read(fd, (char *) buf + total, count - total) > if (n < 0) > return n; > if (n == 0) > break; > total += n; > } > > return total; > } > > ssize_t writen(int fd, const void *buf, size_t count) > { > ssize_t total = 0; > > while (total < count) > { > ssize_t n = write(fd, (const char *) buf + total, count - total) > if (n < 0) > return n; > if (n == 0) > break; > total += n; > } > > return total; > } > > The above assumes that non-blocking I/O hasn't been enabled for the > descriptor. If it has, you need to either disable it for the duration > of the function or use select() or poll() to wait until the descriptor > is ready. > >> I'll post new binaries as soon as compilation is over, so that others can >> test as well. > > If you want to test it, I'd suggest reducing the size of the pipes in > lib/db/dbmi_client/start.c. A larger pipe won't prevent errors, but it > may make them less likely to show up. > I changes the values in lines 146 & 147 and went down all the way to 2 ( from the current setting of 250000): I cannot reproduce the deadlock...v.out.ogr works as it should. So, where should we go from here ? Is it still wiser to implement readn/writen as you suggest above ? If yes, where and how do I see if non-blocking I/O is enabled or not (on MSDN it says: "In multithreaded programs, no locking is performed. The file descriptors returned are newly opened and should not be referenced by any thread until after the _pipe call is complete." - Is this what you mean ?) ? Benjamin, could you try the simple write/read (instead of fwrite/fread) solution, so that we can make sure that this works for someone else ? Moritz From benjamin.ducke at ufg.uni-kiel.de Thu Oct 4 20:43:50 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Oct 4 20:43:55 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <470516FF.9030606@club.worldonline.be> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> Message-ID: <47053466.5090405@ufg.uni-kiel.de> I'd love to give this a spin on a Win2000 and XP box. Unfortunately, I don't have acccess to one right now. Moritz, could you email all the files you changed? I will try to get hold of a Windows machine to compile and test as soon as possible. Benjamin Moritz Lennert wrote: > On 24/09/07 03:41, Glynn Clements wrote: >> Moritz Lennert wrote: >> >>>> My next suggestion is to re-write xdr_stdio to use read() and write() >>>> instead of fread() and fwrite(), e.g.: >>>> >>>> - if (fread((caddr_t)lp, sizeof(long), 1, (FILE >>>> *)xdrs->x_private) != 1) >>>> + if (read(fileno((FILE *)xdrs->x_private), (caddr_t)lp, >>>> sizeof(long)) != >>>> sizeof(long)) >>> That seems to work ! >> >> Now that's strange. I was expecting it to provide more information on >> the errors, not to work. >> >> On Unix, read/write can return short counts on pipes. If a process >> tries to write 4 bytes to a pipe, and there's only enough space for 2 >> bytes, write() will return 2 rather than waiting for the pipe to >> drain. Similarly if you try to read more data than is available in the >> pipe. >> >> If you want to block until the requested amount of data has been read >> or written, you need to either use readn/writen (which are >> non-standard), or implement them yourself, e.g.: >> >> ssize_t readn(int fd, void *buf, size_t count) >> { >> ssize_t total = 0; >> >> while (total < count) >> { >> ssize_t n = read(fd, (char *) buf + total, count - total) >> if (n < 0) >> return n; >> if (n == 0) >> break; >> total += n; >> } >> >> return total; >> } >> >> ssize_t writen(int fd, const void *buf, size_t count) >> { >> ssize_t total = 0; >> >> while (total < count) >> { >> ssize_t n = write(fd, (const char *) buf + total, count - total) >> if (n < 0) >> return n; >> if (n == 0) >> break; >> total += n; >> } >> >> return total; >> } >> >> The above assumes that non-blocking I/O hasn't been enabled for the >> descriptor. If it has, you need to either disable it for the duration >> of the function or use select() or poll() to wait until the descriptor >> is ready. >> >>> I'll post new binaries as soon as compilation is over, so that others >>> can >>> test as well. >> >> If you want to test it, I'd suggest reducing the size of the pipes in >> lib/db/dbmi_client/start.c. A larger pipe won't prevent errors, but it >> may make them less likely to show up. >> > > I changes the values in lines 146 & 147 and went down all the way to 2 ( > from the current setting of 250000): I cannot reproduce the > deadlock...v.out.ogr works as it should. > > So, where should we go from here ? Is it still wiser to implement > readn/writen as you suggest above ? If yes, where and how do I see if > non-blocking I/O is enabled or not (on MSDN it says: "In multithreaded > programs, no locking is performed. The file descriptors returned are > newly opened and should not be referenced by any thread until after the > _pipe call is complete." - Is this what you mean ?) ? > > Benjamin, could you try the simple write/read (instead of fwrite/fread) > solution, so that we can make sure that this works for someone else ? > > Moritz > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From epatton at nrcan.gc.ca Thu Oct 4 21:37:25 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Oct 4 21:37:29 2007 Subject: [GRASS-dev] Grass 6.3-cvs fails to preserve database connection changes Message-ID: Hi, I noticed that Grass 6.3 cvs doesn't 'remember' the database changes that were applied during the last session: >db.connect -p driver:dbf database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ schema: group: >db.connect driver=sqlite database=/home/epatton/Projects/FundyBathy/2007006/databases/BOF_2007.db >db.connect -p driver:sqlite database:/home/epatton/Projects/FundyBathy/2007006/databases/BOF_2007.db schema: group: (exit Grass63, then start it again) >db.connect -p driver:dbf database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ schema: group: I've tried setting my database changes via the gui as well, with no difference. I've double-checked that sqlite database I'm trying to connect to is where I pointed to. Shouldn't Grass preserve the database settings from session-to-session? Thanks, ~ Eric. From neteler at itc.it Thu Oct 4 21:49:34 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Oct 4 21:49:38 2007 Subject: [GRASS-dev] Grass 6.3-cvs fails to preserve database connection changes In-Reply-To: References: Message-ID: <20071004194934.GA25484@bartok.itc.it> On Thu, Oct 04, 2007 at 09:37:25PM +0200, Patton, Eric wrote: > Hi, > > I noticed that Grass 6.3 cvs doesn't 'remember' the database changes that were applied during the last session: > > >db.connect -p > driver:dbf > database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ > schema: > group: > > >db.connect driver=sqlite database=/home/epatton/Projects/FundyBathy/2007006/databases/BOF_2007.db > >db.connect -p > driver:sqlite > database:/home/epatton/Projects/FundyBathy/2007006/databases/BOF_2007.db > schema: > group: > > (exit Grass63, then start it again) > > >db.connect -p > driver:dbf > database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ > schema: > group: > > > I've tried setting my database changes via the gui as well, with no difference. I've double-checked that sqlite database I'm trying to connect to is where I pointed to. Shouldn't Grass preserve the database settings from session-to-session? Absolutely. I was also suprised yesterday and added a workaround in lib/init/init.sh (to restore DBF if the VAR file is missing). But I wonder what is deleting this file. This is a pretty new bug. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From glynn at gclements.plus.com Thu Oct 4 23:28:51 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Oct 4 23:29:11 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <470516FF.9030606@club.worldonline.be> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> Message-ID: <18181.23315.935184.421493@cerise.gclements.plus.com> Moritz Lennert wrote: > So, where should we go from here ? Is it still wiser to implement > readn/writen as you suggest above ? This is where it gets awkward. GRASS uses XDR/RPC for two purposes: libgis uses it for reading and writing FP raster maps, and DBMI uses it for communication between the client and driver. Changing the XDR library to use read/write will probably kill performance for raster I/O, as you lose the buffering. DBMI disables buffering on the streams, so the lack of buffering won't matter for DBMI. OTOH, the raster I/O only uses XDR on files, so the problems with fread/fwrite on pipes don't apply there. My preferred approach would be to change lib/db/dbmi_base to simply not use XDR (that isn't anywhere near as much work as it might sound). As the driver and client always run on the same system, it doesn't matter if the protocol is platform-dependent (I have no idea what Radim was thinking when he decided to use XDR for the DBMI communication). The dbmi_base library uses the following functions from XDR: xdr_char xdr_double xdr_float xdr_int xdr_short xdr_string xdrstdio_create The first five all simply read/write the specified value in a fixed (i.e. non-platform-dependent) format; i.e. convert to big-endian order, and convert FP values to IEEE format. For DBMI, we can just use the host's native format, so the first five all amount to calling read/write on the value. xdr_string is slightly more complex: read/write the length (including the terminating NUL) as an unsigned int, followed by the bytes. xdrstdio_create just sets everything up so that the read/write operations go through fread/fwrite (as opposed to e.g. xdrmem_create which sets up for reading/writing from memory). IOW, the actual implementation of an XDR replacement is trivial. So trivial that you would just inline most of it into the db__{send,recv}_* functions. It's changing the dbmi_base library to use it which will be most of the work. You would probably want separate put/get functions rather than the XDR mechanism of setting the "direction" when creating the XDR object and having a single function for both read and write. E.g. db__send_int() would change from: int db__send_int(int n) { XDR xdrs; int stat; stat = DB_OK; xdr_begin_send (&xdrs); if(!xdr_int (&xdrs, &n)) stat = DB_PROTOCOL_ERR; xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); return stat; } to something like: int db__send_int(int n) { int stat = DB_OK; if (!db__send(&n, sizeof(n))) stat = DB_PROTOCOL_ERR; if (stat == DB_PROTOCOL_ERR) db_protocol_error(); return stat; } with db__send() defined as: int db__send(void *buf, size_t size) { return writen(_send_fd, buf, size) == size; } [Actually, you would probably inline writen() here, as this is the only place it would be used.] > If yes, where and how do I see if non-blocking I/O is enabled or not There is no need; the descriptors for the DBMI pipes will never be non-blocking. I was just commenting that a "real" readn/writen implementation (as is found on some Unices) is a bit more complex, but we don't need that for our purposes. > (on MSDN it says: "In multithreaded > programs, no locking is performed. The file descriptors returned are > newly opened and should not be referenced by any thread until after the > _pipe call is complete." - Is this what you mean ?) ? No, that's something else, and isn't relevant here. -- Glynn Clements From smitch at mac.com Fri Oct 5 04:08:30 2007 From: smitch at mac.com (Scott Mitchell) Date: Fri Oct 5 04:09:11 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <4CF13205-3E3A-4BA3-BA27-5CDC05E1046A@kyngchaos.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> <18179.23691.715738.76415@cerise.gclements.plus.com> <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> <18179.56105.931632.839661@cerise.gclements.plus.com> <93BB1547-A2A6-4C7A-A5D0-29DE1509AB15@kyngchaos.com> <18180.54358.477131.681551@cerise.gclements.plus.com> <4CF13205-3E3A-4BA3-BA27-5CDC05E1046A@kyngchaos.com> Message-ID: <98F2157D-DFB3-447A-888E-1A5DE4CA3966@mac.com> On Oct 4, 2007, at 10:27 , William Kyngesburye wrote: >> >> This is less than ideal, as it will revert to the old form for 3.82, >> but I can't think of a simple way to check for >= 3.81 (especially >> considering that the version might not actually be a number, e.g. >> 3.81-r1 or similar). > > That works, but ugly and doesn't cover the future is probably not > what we want to do. (I saw some .1 versions in the make downloads) > > I'd be happy with the unconditional pipe and recommending to > developers to upgrade their make and not worrying about the 1-shot > user builds. > ... > > I wonder what version other linux distros are at? Ugh, all my machines use 3.80 Debian 3.1, Fedora 5, MacOSX Tiger BUT I've been conservative with my upgrades, leading to package databases that are no longer actively maintained. Debian 4.0 is the current stable, and it's at make 3.81-2. Fedora 7 also uses 3.81. So if Apple would just update the Dev Tools, we wouldn't need to install our own, but that's (I'm guessing) waiting for the new OS release. I guess I should find some time for upgrades. Cheers, Scott From mlennert at club.worldonline.be Fri Oct 5 10:16:27 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Oct 5 10:18:58 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <18181.23315.935184.421493@cerise.gclements.plus.com> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> Message-ID: <4705F2DB.4070301@club.worldonline.be> On 04/10/07 23:28, Glynn Clements wrote: > Moritz Lennert wrote: > >> So, where should we go from here ? Is it still wiser to implement >> readn/writen as you suggest above ? > > This is where it gets awkward. Reading on below it actually seems quite straightforward. ;-) > GRASS uses XDR/RPC for two purposes: libgis uses it for reading and > writing FP raster maps, and DBMI uses it for communication between > the client and driver. So we should probably thoroughly test libgis' uses of it in windows. What would be the best way to do this (i.e. in which circumstances/modules is the xdr part of libgis called) ? [...] > My preferred approach would be to change lib/db/dbmi_base to simply > not use XDR (that isn't anywhere near as much work as it might > sound). > > As the driver and client always run on the same system, it doesn't > matter if the protocol is platform-dependent (I have no idea what > Radim was thinking when he decided to use XDR for the DBMI > communication). I always had the same question, but (in my ignorance) I thought that it might make a difference if the actual database was on a different system. If it doesn't, then let's drop xdr for DBMI (we do really need it for libgis, I suppose ?). > > The dbmi_base library uses the following functions from XDR: > > xdr_char xdr_double xdr_float xdr_int xdr_short > > xdr_string > > xdrstdio_create > > The first five all simply read/write the specified value in a fixed > (i.e. non-platform-dependent) format; i.e. convert to big-endian > order, and convert FP values to IEEE format. For DBMI, we can just > use the host's native format, so the first five all amount to calling > read/write on the value. > > xdr_string is slightly more complex: read/write the length (including > the terminating NUL) as an unsigned int, followed by the bytes. > > xdrstdio_create just sets everything up so that the read/write > operations go through fread/fwrite (as opposed to e.g. xdrmem_create > which sets up for reading/writing from memory). > > IOW, the actual implementation of an XDR replacement is trivial. So > trivial that you would just inline most of it into the > db__{send,recv}_* functions. > > It's changing the dbmi_base library to use it which will be most of > the work. You would probably want separate put/get functions rather > than the XDR mechanism of setting the "direction" when creating the > XDR object and having a single function for both read and write. > > E.g. db__send_int() would change from: > > int db__send_int(int n) { XDR xdrs; int stat; stat = DB_OK; > xdr_begin_send (&xdrs); if(!xdr_int (&xdrs, &n)) stat = > DB_PROTOCOL_ERR; xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) > db_protocol_error(); return stat; } > > to something like: > > int db__send_int(int n) { int stat = DB_OK; if (!db__send(&n, > sizeof(n))) stat = DB_PROTOCOL_ERR; if (stat == DB_PROTOCOL_ERR) > db_protocol_error(); return stat; } > > with db__send() defined as: > > int db__send(void *buf, size_t size) { return writen(_send_fd, buf, > size) == size; } > > [Actually, you would probably inline writen() here, as this is the > only place it would be used.] > I will need a while understanding this, especially understanding which files need replacement. Currently we have the following files in dbmi_base (ls -1 xdr*): xdr.h xdr.c xdrchar.c xdrcolumn.c xdrdatetime.c xdrdouble.c xdrfloat.c xdrhandle.c xdrindex.c xdrint.c xdrprocedure.c xdrshort.c xdrstring.c xdrtable.c xdrtoken.c xdrvalue.c of these only the following reference xdr.h ( grep -l xdr.h *.c) xdr.c xdrchar.c xdrdouble.c xdrfloat.c xdrint.c xdrprocedure.c xdrshort.c xdrstring.c xdrchar.c, xdrdouble.c, xdrfloat.c, xdrint.c, xdrshort.c, xdrstring.c contain the functions you explain how to change above. The only place where they are called is in the macros.h in the same directory. I imagine that xdr.c and xdrprocedure.c can just go to the bin. So "all" we need to do is create new files containing the functions called in macros.h according to the model you describe above. What about the other xdr* files which do not actually directly use any xdr calls (xdrhandle.c, xdrindex.c, xdrtable.c, xdrtoken.c, xdrvalue.c). Should we just leave them as they are ? Should we rename them to avoid future confusion ? Moritz From mlennert at club.worldonline.be Fri Oct 5 10:19:34 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Oct 5 10:22:04 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <47053466.5090405@ufg.uni-kiel.de> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <47053466.5090405@ufg.uni-kiel.de> Message-ID: <4705F396.7050808@club.worldonline.be> On 04/10/07 20:43, Benjamin Ducke wrote: > I'd love to give this a spin on a Win2000 and XP box. > Unfortunately, I don't have acccess to one right now. > > Moritz, could you email all the files you changed? > I will try to get hold of a Windows machine to compile > and test as soon as possible. All you need is the attached diff to xdr_stdio.c. However, Glynn has suggested dropping xdr altogether for dbmi communication, so this will become obsolete. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: xdr_stdio.diff Type: text/x-patch Size: 1162 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071005/869e2ad9/xdr_stdio.bin From benjamin.ducke at ufg.uni-kiel.de Fri Oct 5 12:35:29 2007 From: benjamin.ducke at ufg.uni-kiel.de (benjamin.ducke@ufg.uni-kiel.de) Date: Fri Oct 5 12:35:32 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <4705F396.7050808@club.worldonline.be> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <47053466.5090405@ufg.uni-kiel.de> <4705F396.7050808@club.worldonline.be> Message-ID: <2659.128.40.195.179.1191580529.squirrel@webmail.mail.uni-kiel.de> OK, how about putting some defs into xdr_stdio.c, so that unbuffered i/o only gets compiled on Win32? For the time being, this would mean losing raster performance on native win, but in exchange having full vector functionality. Not a bad deal until xdr_stdio.c gets a full re-write, I would think. Ben > On 04/10/07 20:43, Benjamin Ducke wrote: >> I'd love to give this a spin on a Win2000 and XP box. >> Unfortunately, I don't have acccess to one right now. >> >> Moritz, could you email all the files you changed? >> I will try to get hold of a Windows machine to compile >> and test as soon as possible. > > All you need is the attached diff to xdr_stdio.c. > > However, Glynn has suggested dropping xdr altogether for dbmi > communication, so this will become obsolete. > > Moritz > From epatton at nrcan.gc.ca Fri Oct 5 15:13:54 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Fri Oct 5 15:14:34 2007 Subject: [GRASS-dev] Grass 6.3-cvs fails to preserve databaseconnection changes References: <20071004194934.GA25484@bartok.itc.it> Message-ID: Ok, thanks for the confirmation. I'll file an official bug report, then. ~ Eric. -----Original Message----- From: Markus Neteler [mailto:neteler@itc.it] Sent: Thu 10/4/2007 4:49 PM To: Patton, Eric Cc: grassuser@grass.itc.it; grass-dev@grass.itc.it Subject: Re: [GRASS-dev] Grass 6.3-cvs fails to preserve databaseconnection changes On Thu, Oct 04, 2007 at 09:37:25PM +0200, Patton, Eric wrote: > Hi, > > I noticed that Grass 6.3 cvs doesn't 'remember' the database changes that were applied during the last session: > > >db.connect -p > driver:dbf > database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ > schema: > group: > > >db.connect driver=sqlite database=/home/epatton/Projects/FundyBathy/2007006/databases/BOF_2007.db > >db.connect -p > driver:sqlite > database:/home/epatton/Projects/FundyBathy/2007006/databases/BOF_2007.db > schema: > group: > > (exit Grass63, then start it again) > > >db.connect -p > driver:dbf > database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ > schema: > group: > > > I've tried setting my database changes via the gui as well, with no difference. I've double-checked that sqlite database I'm trying to connect to is where I pointed to. Shouldn't Grass preserve the database settings from session-to-session? Absolutely. I was also suprised yesterday and added a workaround in lib/init/init.sh (to restore DBF if the VAR file is missing). But I wonder what is deleting this file. This is a pretty new bug. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From grass-dev at grass.itc.it Fri Oct 5 15:28:25 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Fri Oct 5 15:19:19 2007 Subject: [GRASS-dev] [grass-code I][502] Grass 6.3 fails to apply database connection changes via db.connect Message-ID: <20071005132825.E8F4B402CF@pyrosoma.intevation.org> code I item #502, was opened at 2007-10-05 10:28 Status: Open Priority: 3 Submitted By: Eric Patton (eric) Assigned to: Nobody (None) Summary: Grass 6.3 fails to apply database connection changes via db.connect Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: None Operating system: Linux Operating system version: Ubuntu 7.04 GRASS CVS checkout date, if applies (YYMMDD): 071005 Initial Comment: I noticed that Grass 6.3 cvs doesn't 'remember' the database changes that were applied during the last session: >db.connect -p driver:dbf database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ schema: group: >db.connect driver=sqlite database=/home/epatton/Projects/FundyBathy/2007006/databases/BOF_2007.db >db.connect -p driver:sqlite database:/home/epatton/Projects/FundyBathy/2007006/databases/BOF_2007.db schema: group: (exit Grass63, then start it again) >db.connect -p driver:dbf database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ schema: group: I've tried setting my database changes via the gui as well, with no difference. I've double-checked that sqlite database I'm trying to connect to is where I pointed to. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=502&group_id=21 From mlennert at club.worldonline.be Fri Oct 5 16:02:57 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Oct 5 16:05:28 2007 Subject: [GRASS-dev] [grass-code I][502] Grass 6.3 fails to apply database connection changes via db.connect In-Reply-To: <20071005132825.E8F4B402CF@pyrosoma.intevation.org> References: <20071005132825.E8F4B402CF@pyrosoma.intevation.org> Message-ID: <47064411.7000906@club.worldonline.be> On 05/10/07 15:28, grass-dev@grass.itc.it wrote: > code I item #502, was opened at 2007-10-05 10:28 Status: Open > Priority: 3 Submitted By: Eric Patton (eric) Assigned to: Nobody > (None) Summary: Grass 6.3 fails to apply database connection changes > via db.connect Issue type: module bug Issue status: None GRASS > version: CVS HEAD GRASS component: None Operating system: Linux > Operating system version: Ubuntu 7.04 GRASS CVS checkout date, if > applies (YYMMDD): 071005 > > > Initial Comment: I noticed that Grass 6.3 cvs doesn't 'remember' the > database changes that were applied during the last session: > Markus wrote: > Absolutely. I was also suprised yesterday and added a workaround > in lib/init/init.sh (to restore DBF if the VAR file is missing). > But I wonder what is deleting this file. This is a pretty new bug. I actually have the feeling that your workaround actually is the problem. You added this to init.sh: # predefine DBF driver if DB connection not defined echo "DB_DRIVER: dbf" > "$LOCATION/VAR" echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" mkdir "$LOCATION"/dbf But I don't see any conditioning around this, so IIUC driver and database will always be set to dbf of the mapset at each startup. It probably needs a test for the dbf directory around it. Something like (not a bash expert): if [ ! -e $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/]; then echo "DB_DRIVER: dbf" > "$LOCATION/VAR" echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" mkdir "$LOCATION"/dbf fi Moritz From mlennert at club.worldonline.be Fri Oct 5 16:11:28 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Oct 5 16:14:00 2007 Subject: [GRASS-dev] [grass-code I][502] Grass 6.3 fails to apply database connection changes via db.connect In-Reply-To: <47064411.7000906@club.worldonline.be> References: <20071005132825.E8F4B402CF@pyrosoma.intevation.org> <47064411.7000906@club.worldonline.be> Message-ID: <47064610.40002@club.worldonline.be> Replying to myself after rereading what I wrote: On 05/10/07 16:02, Moritz Lennert wrote: > > > But I don't see any conditioning around this, so IIUC driver and > database will always be set to dbf of the mapset at each startup. It > probably needs a test for the dbf directory around it. Something like > (not a bash expert): > > if [ ! -e $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/]; > then > echo "DB_DRIVER: dbf" > "$LOCATION/VAR" > echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> > "$LOCATION/VAR" > mkdir "$LOCATION"/dbf > fi > No, this should be if [ ! -e $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/]; then mkdir "$LOCATION"/dbf fi And $LOCATION/VAR variables should only be preset to the dbf driver if for any reason it is empty, if at all. Moritz From glynn at gclements.plus.com Fri Oct 5 17:04:42 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Oct 5 17:04:54 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <4705F2DB.4070301@club.worldonline.be> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> <4705F2DB.4070301@club.worldonline.be> Message-ID: <18182.21130.817195.328481@cerise.gclements.plus.com> Moritz Lennert wrote: > >> So, where should we go from here ? Is it still wiser to implement > >> readn/writen as you suggest above ? > > > > This is where it gets awkward. > > Reading on below it actually seems quite straightforward. ;-) > > > GRASS uses XDR/RPC for two purposes: libgis uses it for reading and > > writing FP raster maps, and DBMI uses it for communication between > > the client and driver. > > So we should probably thoroughly test libgis' uses of it in windows. I don't think that this is necessary. AFAICT, stdio works okay on files; it's only on pipes where it misbehaves. Actually, libgis uses xdrmem_create() to create a memory stream; it doesn't use xdrstdio at all. So ignore what I said about removing the buffering being a performance hit for raster I/O. > What would be the best way to do this (i.e. in which > circumstances/modules is the xdr part of libgis called) ? XDR is used for reading and writing FP maps. > > My preferred approach would be to change lib/db/dbmi_base to simply > > not use XDR (that isn't anywhere near as much work as it might > > sound). > > > > As the driver and client always run on the same system, it doesn't > > matter if the protocol is platform-dependent (I have no idea what > > Radim was thinking when he decided to use XDR for the DBMI > > communication). > > I always had the same question, but (in my ignorance) I thought that it > might make a difference if the actual database was on a different > system. No; the driver does the actual database I/O. XDR is only used for the communication between the client and the driver. [The vector library has its own "portable" I/O routines for reading and writing vector files, which are entirely unrelated to XDR or DBMI.] > If it doesn't, then let's drop xdr for DBMI (we do really need > it for libgis, I suppose ?). The libgis raster I/O functions use it to ensure that the format of FP rasters isn't platform-dependent (it uses its own encoding/decoding routines for integers). Having said that, if you only care about platforms which use IEEE-754 format for floating-point (which is every common architecture except for VAX), the only thing that XDR actually does is to convert 32- and 64-bit quantities to big-endian. The only thing that using XDR really gets us is the ability to have FP maps which are portable between VAX and non-VAX systems. > > The dbmi_base library uses the following functions from XDR: > > > > xdr_char xdr_double xdr_float xdr_int xdr_short > > > > xdr_string > > > > xdrstdio_create > > > > The first five all simply read/write the specified value in a fixed > > (i.e. non-platform-dependent) format; i.e. convert to big-endian > > order, and convert FP values to IEEE format. For DBMI, we can just > > use the host's native format, so the first five all amount to calling > > read/write on the value. > > > > xdr_string is slightly more complex: read/write the length (including > > the terminating NUL) as an unsigned int, followed by the bytes. > > > > xdrstdio_create just sets everything up so that the read/write > > operations go through fread/fwrite (as opposed to e.g. xdrmem_create > > which sets up for reading/writing from memory). > > > > IOW, the actual implementation of an XDR replacement is trivial. So > > trivial that you would just inline most of it into the > > db__{send,recv}_* functions. > > > > It's changing the dbmi_base library to use it which will be most of > > the work. You would probably want separate put/get functions rather > > than the XDR mechanism of setting the "direction" when creating the > > XDR object and having a single function for both read and write. > > > > E.g. db__send_int() would change from: > > > > int db__send_int(int n) { XDR xdrs; int stat; stat = DB_OK; > > xdr_begin_send (&xdrs); if(!xdr_int (&xdrs, &n)) stat = > > DB_PROTOCOL_ERR; xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) > > db_protocol_error(); return stat; } > > > > to something like: > > > > int db__send_int(int n) { int stat = DB_OK; if (!db__send(&n, > > sizeof(n))) stat = DB_PROTOCOL_ERR; if (stat == DB_PROTOCOL_ERR) > > db_protocol_error(); return stat; } > > > > with db__send() defined as: > > > > int db__send(void *buf, size_t size) { return writen(_send_fd, buf, > > size) == size; } > > > > [Actually, you would probably inline writen() here, as this is the > > only place it would be used.] > > I will need a while understanding this, especially understanding which > files need replacement. > > Currently we have the following files in dbmi_base (ls -1 xdr*): > > xdr.h > xdr.c > xdrchar.c > xdrcolumn.c > xdrdatetime.c > xdrdouble.c > xdrfloat.c > xdrhandle.c > xdrindex.c > xdrint.c > xdrprocedure.c > xdrshort.c > xdrstring.c > xdrtable.c > xdrtoken.c > xdrvalue.c > > > of these only the following reference xdr.h ( grep -l xdr.h *.c) > > xdr.c > xdrchar.c > xdrdouble.c > xdrfloat.c > xdrint.c > xdrprocedure.c > xdrshort.c > xdrstring.c > > > xdrchar.c, xdrdouble.c, xdrfloat.c, xdrint.c, xdrshort.c, xdrstring.c > contain the functions you explain how to change above. The only place > where they are called is in the macros.h in the same directory. I > imagine that xdr.c and xdrprocedure.c can just go to the bin. xdrprocedure.c can stay. db__start_procedure_call() uses the DB_* macros rather than XDR. db__recv_procnum() is almost the same as db__recv_int(), except that it passes the success/failure code back to the caller rather than processing it itself. [When the client terminates the communication, the driver will typically be waiting for db__recv_procnum() to return the next request from the client, so in this specific case EOF needs to be treated as a termination request rather than as an error. Getting EOF anywhere else is an error.] xdr.c would be where db__send() and db__recv() go in place of the xdr_{begin,end}_{send,recv} functions.. > So "all" we need to do is create new files containing the functions > called in macros.h according to the model you describe above. I would be inclined to modify the existing files to use the new db__{send,recv} functions in place of XDR functions. There's no harm in leaving the "xdr" prefix in their names for now (once we move to SVN, they can be renamed without losing the change history). > What about the other xdr* files which do not actually directly use any > xdr calls (xdrhandle.c, xdrindex.c, xdrtable.c, xdrtoken.c, xdrvalue.c). > Should we just leave them as they are ? Should we rename them to avoid > future confusion ? Leave them alone. -- Glynn Clements From twiens at interbaun.com Fri Oct 5 19:32:55 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Fri Oct 5 19:32:09 2007 Subject: [GRASS-dev] r.neighbors help file Message-ID: <20071005113255.7b243bab.twiens@interbaun.com> I noticed that the options listed in the help are based odd number up to 25. However, at least with the 6.3 cvs version, any value is accepted and in looking at the code there is not apparent reason larger values shouldn't work. I tried it and it seems to run fine and accurately with values of 31 or 35. Am I missing something or does the help page need to be updated? T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From glynn at gclements.plus.com Sat Oct 6 00:23:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Oct 6 00:24:00 2007 Subject: [GRASS-dev] r.neighbors help file In-Reply-To: <20071005113255.7b243bab.twiens@interbaun.com> References: <20071005113255.7b243bab.twiens@interbaun.com> Message-ID: <18182.47485.382985.848817@cerise.gclements.plus.com> Trevor Wiens wrote: > I noticed that the options listed in the help are based odd number up > to 25. However, at least with the 6.3 cvs version, any value is > accepted and in looking at the code there is not apparent reason > larger values shouldn't work. I tried it and it seems to run fine and > accurately with values of 31 or 35. > > Am I missing something or does the help page need to be updated? Fixed in CVS. -- Glynn Clements From twiens at interbaun.com Sat Oct 6 00:40:23 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Sat Oct 6 00:39:36 2007 Subject: [GRASS-dev] r.neighbors help file In-Reply-To: <18182.47485.382985.848817@cerise.gclements.plus.com> References: <20071005113255.7b243bab.twiens@interbaun.com> <18182.47485.382985.848817@cerise.gclements.plus.com> Message-ID: <20071005164023.4c06d5e7.twiens@interbaun.com> On Fri, 5 Oct 2007 23:23:57 +0100 Glynn Clements wrote: > > Trevor Wiens wrote: > > > I noticed that the options listed in the help are based odd number up > > to 25. However, at least with the 6.3 cvs version, any value is > > accepted and in looking at the code there is not apparent reason > > larger values shouldn't work. I tried it and it seems to run fine and > > accurately with values of 31 or 35. > > > > Am I missing something or does the help page need to be updated? > > Fixed in CVS. I just checked http://www.grass.itc.it/grass63/manuals/html63_user/r.neighbors.html and found the following text in the options section of the help page. Neighborhood Size: The neighborhood size specifies which cells surrounding any given cell fall into the neighborhood for that cell. The size must be an odd integer. Options are: 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, and 25. For example, T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From glynn at gclements.plus.com Sat Oct 6 02:19:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Oct 6 02:19:54 2007 Subject: [GRASS-dev] r.neighbors help file In-Reply-To: <20071005164023.4c06d5e7.twiens@interbaun.com> References: <20071005113255.7b243bab.twiens@interbaun.com> <18182.47485.382985.848817@cerise.gclements.plus.com> <20071005164023.4c06d5e7.twiens@interbaun.com> Message-ID: <18182.54440.389822.483567@cerise.gclements.plus.com> Trevor Wiens wrote: > > > I noticed that the options listed in the help are based odd number up > > > to 25. However, at least with the 6.3 cvs version, any value is > > > accepted and in looking at the code there is not apparent reason > > > larger values shouldn't work. I tried it and it seems to run fine and > > > accurately with values of 31 or 35. > > > > > > Am I missing something or does the help page need to be updated? > > > > Fixed in CVS. > > I just checked > > http://www.grass.itc.it/grass63/manuals/html63_user/r.neighbors.html > > and found the following text in the options section of the help page. > > Neighborhood Size: The neighborhood size specifies which cells > surrounding any given cell fall into the neighborhood for that cell. > The size must be an odd integer. Options are: 1, 3, 5, 7, 9, 11, 13, > 15, 17, 19, 21, 23, and 25. For example, Yes; that's the part that I've just fixed in CVS (the description.html file). The online documentation is taken from the weekly builds, so it will take up to a week before the latest change appears online. -- Glynn Clements From smitch at mac.com Sat Oct 6 02:22:00 2007 From: smitch at mac.com (Scott Mitchell) Date: Sat Oct 6 02:22:21 2007 Subject: [GRASS-dev] r.neighbors help file In-Reply-To: <20071005164023.4c06d5e7.twiens@interbaun.com> References: <20071005113255.7b243bab.twiens@interbaun.com> <18182.47485.382985.848817@cerise.gclements.plus.com> <20071005164023.4c06d5e7.twiens@interbaun.com> Message-ID: On 5 Oct 2007, at 18:40, Trevor Wiens wrote: > On Fri, 5 Oct 2007 23:23:57 +0100 > Glynn Clements wrote: > >> Trevor Wiens wrote: >> >>> I noticed that the options listed in the help are based odd >>> number up >>> to 25. However, at least with the 6.3 cvs version, any value is >>> accepted and in looking at the code there is not apparent reason >>> larger values shouldn't work. I tried it and it seems to run fine >>> and >>> accurately with values of 31 or 35. >>> >>> Am I missing something or does the help page need to be updated? >> >> Fixed in CVS. > > I just checked > > http://www.grass.itc.it/grass63/manuals/html63_user/r.neighbors.html > > and found the following text in the options section of the help page. > > Neighborhood Size: The neighborhood size specifies which cells > surrounding any given cell fall into the neighborhood for that > cell. The size must be an odd integer. Options are: 1, 3, 5, 7, 9, > 11, 13, 15, 17, 19, 21, 23, and 25. For example, It just needs time to propagate - Glynn has changed the description.html in the source directory for that module to read: "The neighborhood size specifies which cells surrounding any given cell fall into the neighborhood for that cell. The size must be an odd integer. For example," ... The web site is built from the CVS tree once per day (if I recall correctly), unless Markus manually runs the update script. Therefore it will take a while before the correction shows up on grass.itc.it, and then perhaps another day before it shows up mirror sites. Apologies if I've missed your point... Scott From twiens at interbaun.com Sat Oct 6 02:53:50 2007 From: twiens at interbaun.com (twiens) Date: Sat Oct 6 02:45:53 2007 Subject: [GRASS-dev] r.neighbors help file Message-ID: <4706dc9e.10a.65e0.30101@interbaun.com> ----- Original Message Follows ----- From: Glynn Clements To: Trevor Wiens Cc: grass-dev@grass.itc.it Subject: Re: [GRASS-dev] r.neighbors help file Date: Sat, 6 Oct 2007 01:19:52 +0100 > Trevor Wiens wrote: > > > > > I noticed that the options listed in the help are > > > > based odd number up to 25. However, at least with > > > > the 6.3 cvs version, any value is accepted and in > > > > looking at the code there is not apparent reason > larger values shouldn't work. I tried it and it seems to > > > > run fine and accurately with values of 31 or 35. > > > > > > > > Am I missing something or does the help page need to > > > be updated? > > > Fixed in CVS. > > > > I just checked > > > > > http://www.grass.itc.it/grass63/manuals/html63_user/r.neighbors.html > > > > and found the following text in the options section of > > the help page. > > Neighborhood Size: The neighborhood size specifies which > > cells surrounding any given cell fall into the > > neighborhood for that cell. The size must be an odd > > integer. Options are: 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, > 21, 23, and 25. For example, > > Yes; that's the part that I've just fixed in CVS (the > description.html file). > > The online documentation is taken from the weekly builds, > so it will take up to a week before the latest change > appears online. > Sorry Glynn, just my ignorance showing again. Thanks for fixing it. T -- Trevor Wiens twiens@interbaun.com From hamish_nospam at yahoo.com Sat Oct 6 04:56:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Oct 6 04:56:32 2007 Subject: [GRASS-dev] [grass-code I][502] Grass 6.3 fails to apply database connection changes via db.connect In-Reply-To: <47064610.40002@club.worldonline.be> Message-ID: <274130.18834.qm@web52704.mail.re2.yahoo.com> Moritz Lennert wrote: > > But I don't see any conditioning around this, so IIUC driver and > > database will always be set to dbf of the mapset at each startup. It > > probably needs a test for the dbf directory around it. Something like > > (not a bash expert): .. > if [ ! -e $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/]; > then > mkdir "$LOCATION"/dbf > fi > > And $LOCATION/VAR variables should only be preset to the dbf driver if > for any reason it is empty, if at all. * you need a space before the closing "]" in the if statement * you need to "quote" variable paths, they may have a space in them * test if it's a dir, not a file (in unix everything is a file) so the above would look like ... LOCATION="$GISDBASE/$LOCATION_NAME/$MAPSET" ... if [ ! -d "$LOCATION/dbf" ] ; then mkdir "$LOCATION"/dbf fi But I'm really not sure that we do need to automatically make dbf/ dirs for each new mapset, or even create a VAR file in the mapset before it is needed. The user may never use the DBF driver, or for that matter any database if they just stick to raster maps. As usual, it's better to fix the bug at the source and strictly follow good design principals as opposed to debating work-arounds. Hamish ____________________________________________________________________________________ Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html From hamish_nospam at yahoo.com Sat Oct 6 05:48:53 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Oct 6 05:48:56 2007 Subject: [GRASS-dev] [grass-code I][502] Grass 6.3 fails to apply database connection changes via db.connect In-Reply-To: <47064610.40002@club.worldonline.be> Message-ID: <895558.39057.qm@web52704.mail.re2.yahoo.com> there is a bug in init.sh, VAR is overwritten with DBF stuff on startup, even if you start grass with: $ grass63 spearfish60/user1 the $MAPSET/VAR file now has a timestamp of when you (just) started GRASS.. Hamish ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow From hamish_nospam at yahoo.com Sat Oct 6 07:09:41 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Oct 6 07:09:44 2007 Subject: [GRASS-dev] [grass-code I][502] Grass 6.3 fails to apply database connection changes via db.connect In-Reply-To: <47064411.7000906@club.worldonline.be> Message-ID: <451760.55210.qm@web52702.mail.re2.yahoo.com> > > code I item #502, was opened at 2007-10-05 10:28 Status: Open > > (None) Summary: Grass 6.3 fails to apply database connection changes > > via db.connect .. > > Initial Comment: I noticed that Grass 6.3 cvs doesn't 'remember' the > > database changes that were applied during the last session: > Markus wrote: > > Absolutely. I was also suprised yesterday and added a workaround > > in lib/init/init.sh (to restore DBF if the VAR file is missing). > > But I wonder what is deleting this file. This is a pretty new bug. Moritz Lennert wrote: > I actually have the feeling that your workaround actually is the > problem. You added this to init.sh: > > # predefine DBF driver if DB connection not defined > echo "DB_DRIVER: dbf" > "$LOCATION/VAR" > echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> > "$LOCATION/VAR" > mkdir "$LOCATION"/dbf > > But I don't see any conditioning around this, so IIUC driver and > database will always be set to dbf of the mapset at each startup. It > probably needs a test for the dbf directory around it. Something like > (not a bash expert): Right. I added conditioning around that but then commented the whole bunch out. The VAR file and $MAPSET/dbf/ dir should be created on demand, not automatically. Apparently Markus found a second bug for which this was a repair for, and apparently that bug is still out in the wild and needs to be fixed. ?? Or maybe now everything is back to normal?? [leaving bug report open and commented out code in init.sh until we know] Hamish ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ From neteler at itc.it Sat Oct 6 09:45:19 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Oct 6 09:45:22 2007 Subject: [GRASS-dev] Re: impending wiki spam bombing In-Reply-To: <20071002091732.GA15060@bartok.itc.it> References: <20070927201214.df09a4d8.hamish_nospam@yahoo.com> <20071001185506.3f7b50cd.hamish_nospam@yahoo.com> <20071001185716.6862a47c.hamish_nospam@yahoo.com> <20071002201835.31696203.hamish_nospam@yahoo.com> <20071002074640.GC23304@bartok.itc.it> <768384.72073.qm@web52701.mail.re2.yahoo.com> <20071002091732.GA15060@bartok.itc.it> Message-ID: <13071467.post@talk.nabble.com> The GRASS Wiki is now protected by a captcha. I have deleted all translations of the help text to avoid below mentioned problem. Please try and report... Markus Markus Neteler wrote: > > On Tue, Oct 02, 2007 at 11:01:43AM +0200, Hamish wrote: >> M: >> > > > What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ? >> H: >> > > Looks good! >> M: >> > We tried it yesterday, but it enabled only the Chinese version. >> > We didn't manage to enforce English or even what the browser >> > says (mine definitely doesn't send "zh"). So we had to remove it. >> >> ?! hmph. >> An idea- my Debian/sarge box once installed a bunch of Chinese versions >> automatically. It turned out the problem was that the package relied on a >> meta-package which could be fulfilled by a number of language specific >> packages. So it installed the first language package on the list, which >> was >> Chinese, and hilarity ensued. > > Maybe you could guide me offlist how to verify that? I think that > the machine is a rather minimalistic (sarge) installation. > >> also for ConfirmEdit "The current version(s) require PHP5; for >> PHP4-compatible >> versions, use an older version available in the SVN." ? >> >> taken from SVN? I see that ConfirmEdit.i18n.php has had many edits in the >> last >> 3 weeks. > > Of course we took an older release from SVN :) > http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ConfirmEdit/ConfirmEdit.php?view=log#rev19995 > Revision 19995 > PHP 4 / MW 1.6 compat > >> too late for me tonight, but they have an IRC channel for support- >> http://www.mediawiki.org/wiki/Manual:FAQ#I_have_a_question_not_answered_here._Where_do_I_go_next.3F >> >> >> I would like to keep working on this problem. > > Me, too, but I also need to do my regular work. > Will try again later... > > cheers, > Markus > -- View this message in context: http://www.nabble.com/impending-wiki-spam-bombing-tf4527023.html#a13071467 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sat Oct 6 09:53:28 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Oct 6 09:53:30 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.119, 1.120 In-Reply-To: <20071006050500.3E70B60016E@lists.intevation.de> References: <20071006050500.3E70B60016E@lists.intevation.de> Message-ID: <20071006075328.GA23910@bartok.itc.it> On Sat, Oct 06, 2007 at 07:05:00AM +0200, grass@intevation.de wrote: > Author: hamish > > Update of /grassrepository/grass6/lib/init > In directory doto:/tmp/cvs-serv6411 > > Modified Files: > init.sh > Log Message: > add test so don't overwrite VAR file without testing. I just commented the whole > thing out though after fixing it, as the VAR and $MAPSET/dbf/ should be > created on demand. To a raster-only or postgres-only user they are just > file pollution. code bug #502 > > > Index: init.sh > =================================================================== > RCS file: /grassrepository/grass6/lib/init/init.sh,v > retrieving revision 1.119 > retrieving revision 1.120 > diff -u -d -r1.119 -r1.120 > --- init.sh 3 Oct 2007 08:30:48 -0000 1.119 > +++ init.sh 6 Oct 2007 05:04:58 -0000 1.120 > @@ -495,9 +495,10 @@ > cp "$GISDBASE/$LOCATION_NAME/PERMANENT/WIND" "$LOCATION/WIND" > echo "Missing WIND file fixed" > # predefine DBF driver > - echo "DB_DRIVER: dbf" > "$LOCATION/VAR" > - echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" > - mkdir "$LOCATION"/dbf > + # why is this needed ?? > + #echo "DB_DRIVER: dbf" > "$LOCATION/VAR" > + #echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" > + #mkdir "$LOCATION"/dbf This is needed, if you start GRASS from CMD line with full path to a non-existing mapset (which is then created). So this should be restored somehow. Above was there for many months without problems. The recent problem seems to arise from a different modification. Markus PS: I find init.sh rather overloaded and hard to understand. ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From mlennert at club.worldonline.be Sat Oct 6 22:32:06 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sat Oct 6 22:34:43 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.119, 1.120 In-Reply-To: <20071006075328.GA23910@bartok.itc.it> References: <20071006050500.3E70B60016E@lists.intevation.de> <20071006075328.GA23910@bartok.itc.it> Message-ID: <55788.85.10.65.176.1191702726.squirrel@geog-pc40.ulb.ac.be> On Sat, October 6, 2007 09:53, Markus Neteler wrote: > On Sat, Oct 06, 2007 at 07:05:00AM +0200, grass@intevation.de wrote: >> Author: hamish >> >> Update of /grassrepository/grass6/lib/init >> In directory doto:/tmp/cvs-serv6411 >> >> Modified Files: >> init.sh >> Log Message: >> add test so don't overwrite VAR file without testing. I just commented >> the whole >> thing out though after fixing it, as the VAR and $MAPSET/dbf/ should be >> created on demand. To a raster-only or postgres-only user they are just >> file pollution. code bug #502 >> >> >> Index: init.sh >> =================================================================== >> RCS file: /grassrepository/grass6/lib/init/init.sh,v >> retrieving revision 1.119 >> retrieving revision 1.120 >> diff -u -d -r1.119 -r1.120 >> --- init.sh 3 Oct 2007 08:30:48 -0000 1.119 >> +++ init.sh 6 Oct 2007 05:04:58 -0000 1.120 >> @@ -495,9 +495,10 @@ >> cp "$GISDBASE/$LOCATION_NAME/PERMANENT/WIND" >> "$LOCATION/WIND" >> echo "Missing WIND file fixed" >> # predefine DBF driver >> - echo "DB_DRIVER: dbf" > "$LOCATION/VAR" >> - echo "DB_DATABASE: >> \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" >> - mkdir "$LOCATION"/dbf >> + # why is this needed ?? >> + #echo "DB_DRIVER: dbf" > "$LOCATION/VAR" >> + #echo "DB_DATABASE: >> \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" >> + #mkdir "$LOCATION"/dbf > > > This is needed, if you start GRASS from CMD line with > full path to a non-existing mapset (which is then created). Why is the dbf path creation needed ? You might never want to use dbf on this new mapset... I guess the automatic dbf path creation should be part of db.connect... > Above was there for many months without problems. The recent > problem seems to arise from a different modification. Yes, the revision just before (http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/init/init.sh.diff?r1=1.118&r2=1.119): =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/init/init.sh,v retrieving revision 1.118 retrieving revision 1.119 diff -u -r1.118 -r1.119 --- grass6/lib/init/init.sh 2007/09/20 14:18:01 1.118 +++ grass6/lib/init/init.sh 2007/10/03 08:30:48 1.119 @@ -1,7 +1,7 @@ #!/bin/sh ############################################################################# # -# $Id: init.sh,v 1.118 2007/09/20 14:18:01 moritz Exp $ +# $Id: init.sh,v 1.119 2007/10/03 08:30:48 markus Exp $ # # MODULE: GRASS Initialization # AUTHOR(S): Original author unknown - probably CERL @@ -685,6 +685,11 @@ echo "Building user fontcap ..." g.mkfontcap fi + +# predefine DBF driver if DB connection not defined +echo "DB_DRIVER: dbf" > "$LOCATION/VAR" +echo "DB_DATABASE: \$GISDBASE/\$LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" +mkdir "$LOCATION"/dbf trap "" 2 3 15 Moritz From mlennert at club.worldonline.be Sat Oct 6 22:41:30 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sat Oct 6 22:44:08 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <2659.128.40.195.179.1191580529.squirrel@webmail.mail.uni-kiel.de> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <47053466.5090405@ufg.uni-kiel.de> <4705F396.7050808@club.worldonline.be> <2659.128.40.195.179.1191580529.squirrel@webmail.mail.uni-kiel.de> Message-ID: <35917.85.10.65.176.1191703290.squirrel@geog-pc40.ulb.ac.be> On Fri, October 5, 2007 12:35, benjamin.ducke@ufg.uni-kiel.de wrote: > OK, how about putting some defs into xdr_stdio.c, so that > unbuffered i/o only gets compiled on Win32? No need as we supply a special static version of libxdr with wingrass. So whatever we do there does not affect other versions of GRASS. > For the time being, this would mean losing raster performance > on native win, but in exchange having full vector functionality. > Not a bad deal until xdr_stdio.c gets a full re-write, I would > think. Actually, as Glynn points out, we do not even have a performance loss since libgis does not use pipes. So the current wingrass version should work without any problems. However, I agree with Glynn that the ideal solution is to just get rid of xdr for DBMI communication. Moritz From hamish_nospam at yahoo.com Sat Oct 6 23:04:40 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Oct 6 23:04:43 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.119, 1.120 In-Reply-To: <55788.85.10.65.176.1191702726.squirrel@geog-pc40.ulb.ac.be> Message-ID: <714310.28349.qm@web52704.mail.re2.yahoo.com> Markus: > > Above was there for many months without problems. The recent > > problem seems to arise from a different modification. Moritz: > Yes, the revision just before > (http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/init/init.sh.diff?r1=1.118&r2=1.119): ie the missing check for the existence of VAR before overwriting the file. H ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From neteler at itc.it Sun Oct 7 00:41:23 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Oct 7 00:41:26 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.119, 1.120 In-Reply-To: <714310.28349.qm@web52704.mail.re2.yahoo.com> References: <20071006075328.GA23910@bartok.itc.it> <55788.85.10.65.176.1191702726.squirrel@geog-pc40.ulb.ac.be> <714310.28349.qm@web52704.mail.re2.yahoo.com> Message-ID: <13078288.post@talk.nabble.com> HamishB wrote: > > Markus: >> > Above was there for many months without problems. The recent >> > problem seems to arise from a different modification. > > Moritz: >> Yes, the revision just before >> > (http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/init/init.sh.diff?r1=1.118&r2=1.119): > > ie the missing check for the existence of VAR before overwriting the file. > Would like to check that but...: Python Exception Occurred Traceback (most recent call last): File "/home/www/viewcvs/lib/viewcvs.py", line 2630, in run_cgi main() File "/home/www/viewcvs/lib/viewcvs.py", line 2608, in main view_diff(request, full_name[:-5]) File "/home/www/viewcvs/lib/viewcvs.py", line 2335, in view_diff if revcmp(rev1, rev2) > 0: File "/home/www/viewcvs/lib/viewcvs.py", line 1098, in revcmp rev2 = map(int, string.split(rev2, '.')) ValueError: invalid literal for int(): 119) Ouch? Markus PS: Martin has prepared a CVS backup via rsync and with viewCVS: http://josef.fsv.cvut.cz/cgi-bin/viewcvs.cgi/grass6/lib/init/init.sh?root=grass&r1=1.118&r2=1.119 So, seems to be my fault (the overwrite, not that the VAR file disappears!) -- View this message in context: http://www.nabble.com/Re%3A--GRASS-CVS--hamish%3A-grass6-lib-init-init.sh%2C-1.119%2C-1.120-tf4579018.html#a13078288 Sent from the Grass - Dev mailing list archive at Nabble.com. From hamish_nospam at yahoo.com Sun Oct 7 05:05:02 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Oct 7 05:05:05 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <4CF13205-3E3A-4BA3-BA27-5CDC05E1046A@kyngchaos.com> Message-ID: <919878.33722.qm@web52705.mail.re2.yahoo.com> William Kyngesburye wrote: > Indeed, very strange. Odd that it took them 4 years to release 3.81 > with that fixed. I'd be a bit surprised if there a make bug could survive for that long which wasn't widely known and we happened to be one of the few software builds affected by it. > I'd be happy with the unconditional pipe and recommending to > developers to upgrade their make and not worrying about the 1-shot > user builds. Maybe not as much for Mac-land, but for othe UNIXs worrying about self compiles is a big deal. > I wonder what version other linux distros are at? Debian Etch (stable): 3.81-2 Debian Sarge (old stable): 3.80-9 Debian unstable: 3.81-3 latest CVS builds fine on Etch, and it did work fine on Sarge last time I tried. I can try again on Sarge with the latest CVS if it helps, let me know. Hamish ____________________________________________________________________________________ Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html From hamish_nospam at yahoo.com Sun Oct 7 05:07:11 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Oct 7 05:07:13 2007 Subject: [GRASS-dev] [bug #1470] (grass) full floats support for r.colors, please In-Reply-To: <20071004151927.3E304602A2E@lists.intevation.de> Message-ID: <339607.41634.qm@web52709.mail.re2.yahoo.com> Maciek Sieczka wrote: > An outstanding issue is 'random' colortable for floating point rasters. I > don't if this is possible. Still only integer rasters are supported. you could do it by splitting into ranges first, e.g. like r.stats or d.histogram's nsteps= option. Hamish ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow From woklist at kyngchaos.com Sun Oct 7 06:03:05 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Oct 7 06:03:27 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <98F2157D-DFB3-447A-888E-1A5DE4CA3966@mac.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <266BA8C2-5031-468F-B146-BEDF61AD8A3C@kyngchaos.com> <18179.23691.715738.76415@cerise.gclements.plus.com> <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> <18179.56105.931632.839661@cerise.gclements.plus.com> <93BB1547-A2A6-4C7A-A5D0-29DE1509AB15@kyngchaos.com> <18180.54358.477131.681551@cerise.gclements.plus.com> <4CF13205-3E3A-4BA3-BA27-5CDC05E1046A@kyngchaos.com> <98F2157D-DFB3-447A-888E-1A5DE4CA3966@mac.com> Message-ID: On Oct 4, 2007, at 9:08 PM, Scott Mitchell wrote: >> I wonder what version other linux distros are at? > > Ugh, all my machines use 3.80 > > Debian 3.1, Fedora 5, MacOSX Tiger > So, do you have the incremental compile problem on any of these? If you run make immediately after a successful make, does it recompile everything? > BUT I've been conservative with my upgrades, leading to package > databases that are no longer actively maintained. Debian 4.0 is > the current stable, and it's at make 3.81-2. Fedora 7 also uses 3.81. > > So if Apple would just update the Dev Tools, we wouldn't need to > install our own, but that's (I'm guessing) waiting for the new OS > release. yeah, hopefully Apple updates make in Leopard. I think Apple aims for stability thru the life of the major OS version. Towards the end of the version lifecycle things can seem wildly out of date, and Tiger has had an unusually long life. On Oct 6, 2007, at 10:05 PM, Hamish wrote: > William Kyngesburye wrote: >> I'd be happy with the unconditional pipe and recommending to >> developers to upgrade their make and not worrying about the 1-shot >> user builds. > > Maybe not as much for Mac-land, but for othe UNIXs worrying about > self compiles > is a big deal. Well, I think on any system it's not a big problem when you just configure-make-install - you don't see the problem. That's what I meant by a 1-shot build. > >> I wonder what version other linux distros are at? > > Debian Etch (stable): 3.81-2 > Debian Sarge (old stable): 3.80-9 > Debian unstable: 3.81-3 > > latest CVS builds fine on Etch, and it did work fine on Sarge last > time I > tried. I can try again on Sarge with the latest CVS if it helps, > let me know. Just to make sure, the simplest way to check is after a successful make, run make again and see if everything recompiles. I asked about versions, but forgot to ask if others had the problem on systems with make 3.80. I wonder if it really is just an OSX make glitch. ----- 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 From hamish_nospam at yahoo.com Sun Oct 7 12:15:00 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Oct 7 12:15:02 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: Message-ID: <430024.45800.qm@web52707.mail.re2.yahoo.com> Hi, I notice with the latest CVS that "g.module.tmp.html" files are left in each module directory after a build. ? Hamish ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From hamish_nospam at yahoo.com Sun Oct 7 13:06:01 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Oct 7 13:06:04 2007 Subject: [GRASS-dev] r.cats -> r.category + enhancements In-Reply-To: Message-ID: <923178.14954.qm@web52709.mail.re2.yahoo.com> Hi, if there are no objections I will rename r.cats to be r.category (to match v.category), leaving a r.cats symlink for backwards compatibility for the duration of GRASS 6.x. In addition I mean to move/copy the copy cats from raster= option from r.support to r.category and add a rules= option to import category labels from a file. (r.support raster= is not in 6.2.x so no crime to move it, although if someone cares we can copy it with a note that it will be removed for GRASS 7; or maybe r.suppport is a better place for these things, not r.cats? but r.support is already crowded) I am unsure if it is better for the import format to match the current r.cats output format, or to try and follow what r.reclass has. For FP maps we will have to accept "a thru bLabel" as well as "aLabel" input rules. ( comes from the fs= option) Note the category labels can be matched to FP ranges, see the nice writeup in the GRASS 5.0 programmers' manual section 5.4. (I expect in the 6 prog manual too but I don't have that on hand right now) ideas welcome, Hamish ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From hamish_nospam at yahoo.com Sun Oct 7 13:22:54 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Oct 7 13:22:57 2007 Subject: [GRASS-dev] r.cats -> r.category + enhancements In-Reply-To: <923178.14954.qm@web52709.mail.re2.yahoo.com> Message-ID: <261050.82824.qm@web52701.mail.re2.yahoo.com> Hamish wrote: > In addition I mean to move/copy the copy cats from raster= option from > r.support to r.category and add a rules= option to import category labels > from a file. I forgot to mention that I'll make it easier to use dynamic labels too. (currently there and working*, but somewhat hidden) [*] but not for ps.map yet, see RT bug report #2437 http://intevation.de/rt/webrt?serial_num=2437 Hamish ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From glynn at gclements.plus.com Sun Oct 7 16:42:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Oct 7 16:43:11 2007 Subject: [GRASS-dev] [bug #1470] (grass) full floats support for r.colors, please In-Reply-To: <339607.41634.qm@web52709.mail.re2.yahoo.com> References: <20071004151927.3E304602A2E@lists.intevation.de> <339607.41634.qm@web52709.mail.re2.yahoo.com> Message-ID: <18184.61524.611410.94359@cerise.gclements.plus.com> Hamish wrote: > > An outstanding issue is 'random' colortable for floating point rasters. I > > don't if this is possible. Still only integer rasters are supported. > > you could do it by splitting into ranges first, e.g. like r.stats or > d.histogram's nsteps= option. You can even use the map's quantisation rules. But the main issue is whether it's sensible to assign a random colour table to an FP map. IMHO, a random colour table only makes sense if the number of categories is small. If there are many categories (e.g. an integer DEM), it's likely that the "clusters" of adjacent, same-valued cells will actually be individual cells. In that situation, a random colour table will just give you "snow". A secondary consideration is that a random colour table requires one rule for each category, which can result in very large colour tables, which can be slow to create (IIRC, the time taken to create a colour table is proportional to the square of the number of entries). IOW a random colour table only makes sense if the data consists of discrete categories rather than a scalar value. Integer maps can be either categories or scalars, but FP maps are always scalars. -- Glynn Clements From glynn at gclements.plus.com Sun Oct 7 17:05:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Oct 7 17:05:18 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <430024.45800.qm@web52707.mail.re2.yahoo.com> References: <430024.45800.qm@web52707.mail.re2.yahoo.com> Message-ID: <18184.62887.437020.283970@cerise.gclements.plus.com> Hamish wrote: > I notice with the latest CVS that "g.module.tmp.html" files are left in each > module directory after a build. Yep. Arguably, they should be. In general, anything which could be re-used if make is re-run should be left around until "make clean" is run. If the description.html files were handled consistently (some are called description.html, some are named after the program, e.g. r.mapcalc.html; some are complete HTML files, some expect to be merged with the .tmp.html file), the rule to build the final .html file would have both fragments as prerequisites. If you modify description.html then re-build the final .html file, it would use the existing .tmp.html file rather than repeating the --html-description step. This doesn't happen at present, as there's no way to determine which files tools/mkhtml.sh will actually use (it handles several cases depending upon which files already exist), so description.html isn't listed as a prerequisite. It may be useful in the future, though. It would be easy enough to have the htmlgen step remove them if they're causing problems. The only situation where they would be regenerated unnecessarily is if you need to rebuild the .html file and the program itself hasn't changed, which isn't likely. Currently, they aren't explicitly mentioned in the Makefiles because they aren't always created/used. A few programs don't understand --html-description, which created no end of problems with trying to come up with sane rules for building the HTML files. -- Glynn Clements From glynn at gclements.plus.com Sun Oct 7 17:10:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Oct 7 17:10:43 2007 Subject: [GRASS-dev] r.cats -> r.category + enhancements In-Reply-To: <923178.14954.qm@web52709.mail.re2.yahoo.com> References: <923178.14954.qm@web52709.mail.re2.yahoo.com> Message-ID: <18184.63205.36260.271750@cerise.gclements.plus.com> Hamish wrote: > if there are no objections I will rename r.cats to be r.category (to match > v.category), leaving a r.cats symlink for backwards compatibility for the > duration of GRASS 6.x. > > In addition I mean to move/copy the copy cats from raster= option from > r.support to r.category and add a rules= option to import category labels from > a file. FWIW, I've written an r.support.cats module, but haven't tested it or committed it yet. I've attached it in case you want to use it for a base. > I am unsure if it is better for the import format to match the current r.cats > output format, or to try and follow what r.reclass has. For FP maps we will > have to accept "a thru bLabel" as well as "aLabel" input rules. ( > comes from the fs= option) I used essentially the existing format, without the header. Each line is either value:label or min:max:label (for ranges). -- Glynn Clements -------------- next part -------------- A non-text attachment was scrubbed... Name: r.support.cats.tar.gz Type: application/octet-stream Size: 1480 bytes Desc: r.support.cats Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071007/b31971f9/r.support.cats.tar.obj From glynn at gclements.plus.com Sun Oct 7 17:13:50 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Oct 7 17:14:05 2007 Subject: [GRASS-dev] another make problem (OSX, but could be a general problem) In-Reply-To: <919878.33722.qm@web52705.mail.re2.yahoo.com> References: <4CF13205-3E3A-4BA3-BA27-5CDC05E1046A@kyngchaos.com> <919878.33722.qm@web52705.mail.re2.yahoo.com> Message-ID: <18184.63406.331542.877901@cerise.gclements.plus.com> Hamish wrote: > > Indeed, very strange. Odd that it took them 4 years to release 3.81 > > with that fixed. > > I'd be a bit surprised if there a make bug could survive for that long which > wasn't widely known and we happened to be one of the few software builds > affected by it. There are a lot of features in GNU make which aren't widely used. E.g. anything which isn't used by the Makefiles which automake generates won't affect most FOSS software, and a lot of non-automake software tries to work with other make programs. > > I'd be happy with the unconditional pipe and recommending to > > developers to upgrade their make and not worrying about the 1-shot > > user builds. > > Maybe not as much for Mac-land, but for othe UNIXs worrying about self compiles > is a big deal. The issue is with re-compilation. Unnecessary rebuilding isn't a problem for a "one-shot" build (configure;make;make install;make clean). -- Glynn Clements From michael.barton at asu.edu Sun Oct 7 22:48:12 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Oct 7 22:48:19 2007 Subject: [GRASS-dev] OK to compile on Mac? Message-ID: William I've been sort of following your work with Glynn to improve Mac compiling. If I compile from CVS today, will it work OK as before or am I likely to run into trouble? Michael __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071007/3fdb123d/attachment.html From glynn at gclements.plus.com Sun Oct 7 23:04:50 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Oct 7 23:05:11 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <18181.23315.935184.421493@cerise.gclements.plus.com> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> Message-ID: <18185.18930.6475.865204@cerise.gclements.plus.com> Glynn Clements wrote: > My preferred approach would be to change lib/db/dbmi_base to simply > not use XDR (that isn't anywhere near as much work as it might sound). I have attached a patch to do this. I haven't committed it yet in case it breaks anything (and if it breaks anything, it may break a lot of things). Could someone familiar with DBMI and vectors test it out? -- Glynn Clements -------------- next part -------------- Index: include/proto_dbmi.h =================================================================== RCS file: /grassrepository/grass6/include/proto_dbmi.h,v retrieving revision 1.28 diff -u -r1.28 proto_dbmi.h --- include/proto_dbmi.h 27 Jun 2007 16:31:51 -0000 1.28 +++ include/proto_dbmi.h 7 Oct 2007 20:50:35 -0000 @@ -245,19 +245,19 @@ int db__send_column_value P((dbColumn *column )); int db__send_datetime P((dbDateTime *t )); int db__send_double P((double d )); -int db__send_double_array P((double *x , int n )); +int db__send_double_array P((const double *x , int n )); int db__send_failure P((void )); int db__send_float P((float d )); -int db__send_float_array P((float *x , int n )); +int db__send_float_array P((const float *x , int n )); int db__send_handle P((dbHandle *handle )); int db__send_index P((dbIndex *index )); int db__send_index_array P((dbIndex *list , int count )); int db__send_int P((int n )); -int db__send_int_array P((int *x , int n )); +int db__send_int_array P((const int *x , int n )); int db__send_procedure_not_implemented P((int n )); int db__send_procedure_ok P((int n )); int db__send_short P((int n )); -int db__send_short_array P((short *x , int n )); +int db__send_short_array P((const short *x , int n )); int db__send_string P((dbString *x )); int db__send_string_array P((dbString *a , int count )); int db__send_success P((void )); Index: lib/db/dbmi_base/xdr.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdr.c,v retrieving revision 1.5 diff -u -r1.5 xdr.c --- lib/db/dbmi_base/xdr.c 26 Apr 2007 16:44:44 -0000 1.5 +++ lib/db/dbmi_base/xdr.c 7 Oct 2007 20:50:35 -0000 @@ -15,47 +15,84 @@ *****************************************************************************/ #include "xdr.h" +#ifdef __MINGW32__ +#define USE_STDIO 0 +#define USE_READN 1 +#else +#define USE_STDIO 1 +#define USE_READN 0 +#endif + +#ifndef USE_STDIO +#include +#endif + static FILE *_send, *_recv; -void -db__set_protocol_fds (FILE *send, FILE *recv) -{ - _send = send; - _recv = recv; -} +#if USE_READN -int -xdr_begin_send(XDR *xdrs) +static ssize_t readn(int fd, void *buf, size_t count) { - xdrstdio_create (xdrs, _send, XDR_ENCODE); + ssize_t total = 0; + + while (total < count) + { + ssize_t n = read(fd, (char *) buf + total, count - total) + if (n < 0) + return n; + if (n == 0) + break; + total += n; + } - return 0; + return total; } -int -xdr_begin_recv(XDR *xdrs) +static ssize_t writen(int fd, const void *buf, size_t count) { - xdrstdio_create (xdrs, _recv, XDR_DECODE); + ssize_t total = 0; - return 0; + while (total < count) + { + ssize_t n = write(fd, (const char *) buf + total, count - total) + if (n < 0) + return n; + if (n == 0) + break; + total += n; + } + + return total; } -int -xdr_end_send(XDR *xdrs) -{ - fflush(_send); - xdr_destroy (xdrs); +#endif - return 0; +void +db__set_protocol_fds (FILE *send, FILE *recv) +{ + _send = send; + _recv = recv; } -int -xdr_end_recv(XDR *xdrs) +int db__send(const void *buf, size_t size) { - xdr_destroy (xdrs); - - return 0; +#if USE_STDIO + return fwrite(buf, 1, size, _send) == size; +#elif USE_READN + return writen(fileno(_send), buf, size) == size; +#else + return write(fileno(_send), buf, size) == size; +#endif } - +int db__recv(void *buf, size_t size) +{ +#if USE_STDIO + return fread(buf, 1, size, _recv) == size; +#elif USE_READN + return readn(fileno(_recv), buf, size) == size; +#else + return read(fileno(_recv), buf, size) == size; +#endif +} Index: lib/db/dbmi_base/xdr.h =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdr.h,v retrieving revision 1.5 diff -u -r1.5 xdr.h --- lib/db/dbmi_base/xdr.h 9 Feb 2006 03:08:54 -0000 1.5 +++ lib/db/dbmi_base/xdr.h 7 Oct 2007 20:50:35 -0000 @@ -1,13 +1,6 @@ -#ifdef __MINGW32__ -#include -#include -#else -#include -#endif - +#include #include -int xdr_begin_send(XDR *xdrs); -int xdr_begin_recv(XDR *xdrs); -int xdr_end_send(XDR *xdrs); -int xdr_end_recv(XDR *xdrs); +extern int db__send(const void *, size_t); +extern int db__recv(void *, size_t); + Index: lib/db/dbmi_base/xdrchar.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdrchar.c,v retrieving revision 1.2 diff -u -r1.2 xdrchar.c --- lib/db/dbmi_base/xdrchar.c 5 Oct 2006 06:13:28 -0000 1.2 +++ lib/db/dbmi_base/xdrchar.c 7 Oct 2007 20:50:35 -0000 @@ -4,17 +4,11 @@ int db__send_char(int d) { - XDR xdrs; - int stat; - char c; + int stat = DB_OK; + char c = (char) d; - stat = DB_OK; - c = d; - - xdr_begin_send (&xdrs); - if(!xdr_char (&xdrs, &c)) + if (!db__send(&c, sizeof(c))) stat = DB_PROTOCOL_ERR; - xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -26,14 +20,10 @@ int db__recv_char (char *d) { - XDR xdrs; - int stat; + int stat = DB_OK; - stat = DB_OK; - xdr_begin_recv (&xdrs); - if(!xdr_char (&xdrs, d)) + if (!db__recv(d, sizeof(*d))) stat = DB_PROTOCOL_ERR; - xdr_end_recv (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); Index: lib/db/dbmi_base/xdrdouble.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdrdouble.c,v retrieving revision 1.2 diff -u -r1.2 xdrdouble.c --- lib/db/dbmi_base/xdrdouble.c 5 Oct 2006 06:13:28 -0000 1.2 +++ lib/db/dbmi_base/xdrdouble.c 7 Oct 2007 20:50:35 -0000 @@ -1,20 +1,13 @@ -#include #include "xdr.h" int -db__send_double(d) - double d; +db__send_double(double d) { - XDR xdrs; - int stat; + int stat = DB_OK; - stat = DB_OK; - - xdr_begin_send (&xdrs); - if(!xdr_double (&xdrs, &d)) + if (!db__send(&d, sizeof(d))) stat = DB_PROTOCOL_ERR; - xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -25,14 +18,10 @@ int db__recv_double (double *d) { - XDR xdrs; - int stat; + int stat = DB_OK; - stat = DB_OK; - xdr_begin_recv (&xdrs); - if(!xdr_double (&xdrs, d)) + if (!db__recv(d, sizeof(*d))) stat = DB_PROTOCOL_ERR; - xdr_end_recv (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -42,27 +31,15 @@ int -db__send_double_array (double *x, int n) +db__send_double_array (const double *x, int n) { - XDR xdrs; - int i; - int stat; - - stat = DB_OK; + int stat = DB_OK; - xdr_begin_send (&xdrs); - - if(!xdr_int (&xdrs, &n)) + if (!db__send(&n, sizeof(n))) stat = DB_PROTOCOL_ERR; - for (i = 0; stat == DB_OK && i < n; i++) - { - if(!xdr_double (&xdrs, x)) - stat = DB_PROTOCOL_ERR; - x++; - } - - xdr_end_send (&xdrs); + if (!db__send(x, n * sizeof(*x))) + stat = DB_PROTOCOL_ERR; if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -75,50 +52,22 @@ int db__recv_double_array (double **x, int *n) { - XDR xdrs; - int i, count, stat; - double y, *a; - - *x = NULL; - *n = 0; - - stat = DB_OK; - xdr_begin_recv (&xdrs); - if (xdr_int (&xdrs, &count)) - { - if (count <= 0) - stat = DB_PROTOCOL_ERR; - a = (double *)db_calloc (count, sizeof (double)); - if (a == NULL && stat == DB_OK) - stat = DB_MEMORY_ERR; - - for (i = 0; i < count; i++) - { - if (!xdr_double (&xdrs, &y)) - { - stat = DB_PROTOCOL_ERR; - break; - } - if (a) a[i] = y; - } - if (stat != DB_OK) - { - if (a != NULL) free(a); - a = NULL; - } - } - else - stat = DB_PROTOCOL_ERR; - - if (stat == DB_OK) - { - *x = a; - *n = count; - } - else if (stat == DB_PROTOCOL_ERR) - db_protocol_error(); + int stat = DB_OK; + int count = 0; + double *a = NULL; + + if (!db__recv(&count, sizeof(count))) + stat = DB_PROTOCOL_ERR; + + *n = count; - xdr_end_recv (&xdrs); + *x = a = (double *) db_calloc(count, sizeof(*a)); + + if (!db__recv(a, count * sizeof(*a))) + stat = DB_PROTOCOL_ERR; + + if (stat == DB_PROTOCOL_ERR) + db_protocol_error(); return stat; } Index: lib/db/dbmi_base/xdrfloat.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdrfloat.c,v retrieving revision 1.1 diff -u -r1.1 xdrfloat.c --- lib/db/dbmi_base/xdrfloat.c 22 May 2003 13:58:00 -0000 1.1 +++ lib/db/dbmi_base/xdrfloat.c 7 Oct 2007 20:50:35 -0000 @@ -1,113 +1,74 @@ -#include #include "xdr.h" -int db__send_float(float d) -{ - XDR xdrs; - int stat; - stat = DB_OK; +int +db__send_float(float d) +{ + int stat = DB_OK; - xdr_begin_send (&xdrs); - if(!xdr_float (&xdrs, &d)) + if (!db__send(&d, sizeof(d))) stat = DB_PROTOCOL_ERR; - xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); + return stat; } -int db__recv_float (float *d) +int +db__recv_float (float *d) { - XDR xdrs; - int stat; + int stat = DB_OK; - stat = DB_OK; - xdr_begin_recv (&xdrs); - if(!xdr_float (&xdrs, d)) + if (!db__recv(d, sizeof(*d))) stat = DB_PROTOCOL_ERR; - xdr_end_recv (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); + return stat; } -int db__send_float_array (float *x, int n) -{ - XDR xdrs; - int i; - int stat; - - stat = DB_OK; - xdr_begin_send (&xdrs); +int +db__send_float_array (const float *x, int n) +{ + int stat = DB_OK; - if(!xdr_int (&xdrs, &n)) + if (!db__send(&n, sizeof(n))) stat = DB_PROTOCOL_ERR; - for (i = 0; stat == DB_OK && i < n; i++) - { - if(!xdr_float (&xdrs, x)) - stat = DB_PROTOCOL_ERR; - x++; - } - xdr_end_send (&xdrs); + if (!db__send(x, n * sizeof(*x))) + stat = DB_PROTOCOL_ERR; if (stat == DB_PROTOCOL_ERR) db_protocol_error(); + return stat; } /* returns an allocated array of floats */ /* caller is responsible for free() */ - -int db__recv_float_array (float **x, int *n) +int +db__recv_float_array (float **x, int *n) { - XDR xdrs; - int i, count, stat; - float y, *a; - - *x = NULL; - *n = 0; - - stat = DB_OK; - xdr_begin_recv (&xdrs); - if (xdr_int (&xdrs, &count)) - { - if (count <= 0) - stat = DB_PROTOCOL_ERR; - a = (float *)db_calloc (count, sizeof (float)); - if (a == NULL && stat == DB_OK) - stat = DB_MEMORY_ERR; - - for (i = 0; i < count; i++) - { - if (!xdr_float (&xdrs, &y)) - { - stat = DB_PROTOCOL_ERR; - break; - } - if (a) a[i] = y; - } - if (stat != DB_OK) - { - if (a != NULL) free(a); - a = NULL; - } - } - else - stat = DB_PROTOCOL_ERR; - - if (stat == DB_OK) - { - *x = a; - *n = count; - } - else if (stat == DB_PROTOCOL_ERR) + int stat = DB_OK; + int count = 0; + float *a = NULL; + + if (!db__recv(&count, sizeof(count))) + stat = DB_PROTOCOL_ERR; + + *n = count; + + *x = a = (float *) db_calloc(count, sizeof(*a)); + + if (!db__recv(a, count * sizeof(*a))) + stat = DB_PROTOCOL_ERR; + + if (stat == DB_PROTOCOL_ERR) db_protocol_error(); - xdr_end_recv (&xdrs); return stat; } + Index: lib/db/dbmi_base/xdrint.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdrint.c,v retrieving revision 1.2 diff -u -r1.2 xdrint.c --- lib/db/dbmi_base/xdrint.c 5 Oct 2006 06:13:28 -0000 1.2 +++ lib/db/dbmi_base/xdrint.c 7 Oct 2007 20:50:35 -0000 @@ -1,37 +1,27 @@ -#include #include "xdr.h" int db__send_int(int n) { - XDR xdrs; - int stat; + int stat = DB_OK; - stat = DB_OK; - - xdr_begin_send (&xdrs); - if(!xdr_int (&xdrs, &n)) + if (!db__send(&n, sizeof(n))) stat = DB_PROTOCOL_ERR; - xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); + return stat; } int db__recv_int (int *n) { - XDR xdrs; - int stat; + int stat = DB_OK; - stat = DB_OK; - - xdr_begin_recv (&xdrs); - if(!xdr_int (&xdrs, n)) + if (!db__recv(n, sizeof(*n))) stat = DB_PROTOCOL_ERR; - xdr_end_recv (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -40,28 +30,19 @@ } int -db__send_int_array (int *x, int n) +db__send_int_array (const int *x, int n) { - XDR xdrs; - int i; - int stat; - - stat = DB_OK; - - xdr_begin_send (&xdrs); - if(!xdr_int (&xdrs, &n)) - stat = DB_PROTOCOL_ERR; - for (i = 0; stat == DB_OK && i < n; i++) - { - if(!xdr_int (&xdrs, x)) - stat = DB_PROTOCOL_ERR; - x++; - } + int stat = DB_OK; + + if (!db__send(&n, sizeof(n))) + stat = DB_PROTOCOL_ERR; - xdr_end_send (&xdrs); + if (!db__send(x, n * sizeof(*x))) + stat = DB_PROTOCOL_ERR; if (stat == DB_PROTOCOL_ERR) db_protocol_error(); + return stat; } @@ -70,51 +51,22 @@ int db__recv_int_array (int **x, int *n) { - XDR xdrs; - int i, count, stat; - int y, *a; - - *x = NULL; - *n = 0; - - stat = DB_OK; - xdr_begin_recv (&xdrs); - if (xdr_int (&xdrs, &count)) - { - if (count <= 0) - stat = DB_PROTOCOL_ERR; - - a = (int *)db_calloc (count, sizeof (int)); - if (a == NULL && stat == DB_OK) - stat = DB_MEMORY_ERR; - - for (i = 0; i < count; i++) - { - if (!xdr_int (&xdrs, &y)) - { - stat = DB_PROTOCOL_ERR; - break; - } - if (a) a[i] = y; - } - if (stat != DB_OK) - { - if (a != NULL) free(a); - a = NULL; - } - } - else - stat = DB_PROTOCOL_ERR; - - if (stat == DB_OK) - { - *x = a; - *n = count; - } - else if (stat == DB_PROTOCOL_ERR) - db_protocol_error(); + int stat = DB_OK; + int count = 0; + int *a = NULL; - xdr_end_recv (&xdrs); + if (!db__recv(&count, sizeof(count))) + stat = DB_PROTOCOL_ERR; + + *n = count; + + *x = a = (int *) db_calloc(count, sizeof(*a)); + + if (!db__recv(a, count * sizeof(*a))) + stat = DB_PROTOCOL_ERR; + + if (stat == DB_PROTOCOL_ERR) + db_protocol_error(); return stat; } Index: lib/db/dbmi_base/xdrprocedure.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdrprocedure.c,v retrieving revision 1.2 diff -u -r1.2 xdrprocedure.c --- lib/db/dbmi_base/xdrprocedure.c 5 Oct 2006 06:13:28 -0000 1.2 +++ lib/db/dbmi_base/xdrprocedure.c 7 Oct 2007 20:50:35 -0000 @@ -35,15 +35,10 @@ int db__recv_procnum (int *n) { - XDR xdrs; - int stat; + int stat = DB_OK; - stat = DB_OK; - - xdr_begin_recv (&xdrs); - if(!xdr_int (&xdrs, n)) + if (!db__recv(n, sizeof(*n))) stat = DB_EOF; - xdr_end_recv (&xdrs); return stat; } Index: lib/db/dbmi_base/xdrshort.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdrshort.c,v retrieving revision 1.2 diff -u -r1.2 xdrshort.c --- lib/db/dbmi_base/xdrshort.c 5 Oct 2006 06:13:28 -0000 1.2 +++ lib/db/dbmi_base/xdrshort.c 7 Oct 2007 20:50:35 -0000 @@ -5,18 +5,11 @@ int db__send_short(int n) { - XDR xdrs; - int stat; - short h; + int stat = DB_OK; + short h = (short) n; - h = n; - - stat = DB_OK; - - xdr_begin_send (&xdrs); - if(!xdr_short (&xdrs, &h)) + if (!db__send(&h, sizeof(h))) stat = DB_PROTOCOL_ERR; - xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -27,15 +20,10 @@ int db__recv_short (short *n) { - XDR xdrs; - int stat; + int stat = DB_OK; - stat = DB_OK; - - xdr_begin_recv (&xdrs); - if(!xdr_short (&xdrs, n)) + if (!db__recv(n, sizeof(*n))) stat = DB_PROTOCOL_ERR; - xdr_end_recv (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -44,25 +32,15 @@ } int -db__send_short_array (short *x, int n) +db__send_short_array (const short *x, int n) { - XDR xdrs; - int i; - int stat; - - stat = DB_OK; - - xdr_begin_send (&xdrs); - if(!xdr_int (&xdrs, &n)) - stat = DB_PROTOCOL_ERR; - for (i = 0; stat == DB_OK && i < n; i++) - { - if(!xdr_short (&xdrs, x)) - stat = DB_PROTOCOL_ERR; - x++; - } + int stat = DB_OK; + + if (!db__send(&n, sizeof(n))) + stat = DB_PROTOCOL_ERR; - xdr_end_send (&xdrs); + if (!db__send(x, n * sizeof(*x))) + stat = DB_PROTOCOL_ERR; if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -70,56 +48,28 @@ return stat; } -/* returns an allocated array of shorts */ +/* returns an allocated array of ints */ /* caller is responsible for free() */ int db__recv_short_array (short **x, int *n) { - XDR xdrs; - int i, count, stat; - short y, *a; - - *x = NULL; - *n = 0; - - stat = DB_OK; - xdr_begin_recv (&xdrs); - if (xdr_int (&xdrs, &count)) - { - if (count <= 0) - stat = DB_PROTOCOL_ERR; - - a = (short *)db_calloc (count, sizeof (short)); - if (a == NULL && stat == DB_OK) - stat = DB_MEMORY_ERR; - - for (i = 0; i < count; i++) - { - if (!xdr_short (&xdrs, &y)) - { - stat = DB_PROTOCOL_ERR; - break; - } - if (a) a[i] = y; - } - if (stat != DB_OK) - { - if (a != NULL) free(a); - a = NULL; - } - } - else - stat = DB_PROTOCOL_ERR; - - if (stat == DB_OK) - { - *x = a; - *n = count; - } - else if (stat == DB_PROTOCOL_ERR) - db_protocol_error(); + int stat = DB_OK; + int count = 0; + short *a = NULL; + + if (!db__recv(&count, sizeof(count))) + stat = DB_PROTOCOL_ERR; + + *n = count; + + *x = a = (short *) db_calloc(count, sizeof(*a)); + + if (!db__recv(a, count * sizeof(*a))) + stat = DB_PROTOCOL_ERR; - xdr_end_recv (&xdrs); + if (stat == DB_PROTOCOL_ERR) + db_protocol_error(); return stat; } + Index: lib/db/dbmi_base/xdrstring.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdrstring.c,v retrieving revision 1.2 diff -u -r1.2 xdrstring.c --- lib/db/dbmi_base/xdrstring.c 5 Oct 2006 06:13:28 -0000 1.2 +++ lib/db/dbmi_base/xdrstring.c 7 Oct 2007 20:50:35 -0000 @@ -1,5 +1,4 @@ #include -#include #include "xdr.h" @@ -57,24 +56,18 @@ int db__send_string(dbString *x) { - XDR xdrs; - int len; - int stat; - char *s; - + int stat = DB_OK; + const char *s = db_get_string(x); + int len = s ? strlen(s) + 1 : 1; - stat = DB_OK; + if (!s) + s = ""; /* don't send a NULL string */ - s = db_get_string (x); - if (s == NULL) s = ""; /* can't send a NULL string */ - len = strlen(s)+1; - - xdr_begin_send (&xdrs); - if(!xdr_int (&xdrs, &len)) + if (!db__send(&len, sizeof(len))) stat = DB_PROTOCOL_ERR; - else if(!xdr_string (&xdrs, &s, len)) + + if (!db__send(s, len)) stat = DB_PROTOCOL_ERR; - xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); @@ -94,27 +87,24 @@ int db__recv_string(dbString *x) { - XDR xdrs; + int stat = DB_OK; int len; - int stat; char *s; - stat = DB_OK; - xdr_begin_recv (&xdrs); - if(!xdr_int (&xdrs, &len) || len <= 0) /* len will include the null byte */ - { + if (!db__recv(&len, sizeof(len))) + stat = DB_PROTOCOL_ERR; + + if (len <= 0) /* len will include the null byte */ + stat = DB_PROTOCOL_ERR; + + if (db_enlarge_string(x, len) != DB_OK) stat = DB_PROTOCOL_ERR; - } - else - { - stat = db_enlarge_string (x, len); - } s = db_get_string(x); - if(stat == DB_OK && !xdr_string (&xdrs, &s, len)) + + if (!db__recv(s, len)) stat = DB_PROTOCOL_ERR; - xdr_end_recv (&xdrs); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); From woklist at kyngchaos.com Sun Oct 7 23:07:09 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Oct 7 23:07:28 2007 Subject: [GRASS-dev] OK to compile on Mac? In-Reply-To: References: Message-ID: <7D4333A4-8D1E-48F5-AB70-1C6C77A1579B@kyngchaos.com> There is no problem in the actual compiling. The problem is the old make on OSX will recompile *everything* after a successful make if you run make again (like you might do when you modify a source file, but then you could make individual modules to avoid recompiling everything). On Oct 7, 2007, at 3:48 PM, Michael Barton wrote: > William > > I've been sort of following your work with Glynn to improve Mac > compiling. If I compile from CVS today, will it work OK as before > or am I likely to run into trouble? > > Michael > ----- 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 From glynn at gclements.plus.com Mon Oct 8 01:51:56 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 8 01:52:11 2007 Subject: [GRASS-dev] OK to compile on Mac? In-Reply-To: <7D4333A4-8D1E-48F5-AB70-1C6C77A1579B@kyngchaos.com> References: <7D4333A4-8D1E-48F5-AB70-1C6C77A1579B@kyngchaos.com> Message-ID: <18185.28956.811256.819648@cerise.gclements.plus.com> William Kyngesburye wrote: > There is no problem in the actual compiling. The problem is the old > make on OSX will recompile *everything* after a successful make if > you run make again (like you might do when you modify a source file, > but then you could make individual modules to avoid recompiling > everything). Actually, the current CVS version of Rules.make contains the check for "ifeq ($(MAKE_VERSION),3.81)", so that shouldn't occur. OTOH, there may be some inefficiency with make versions other than 3.81, as it will attempt to create $(OBJDIR) (via a recursive make invocation) for each object file. -- Glynn Clements From michael.barton at asu.edu Mon Oct 8 07:13:14 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Oct 8 07:13:31 2007 Subject: [GRASS-dev] OK to compile on Mac? In-Reply-To: <7D4333A4-8D1E-48F5-AB70-1C6C77A1579B@kyngchaos.com> Message-ID: I had no problem compiling, except the normal d.m error. Michael On 10/7/07 2:07 PM, "William Kyngesburye" wrote: > There is no problem in the actual compiling. The problem is the old > make on OSX will recompile *everything* after a successful make if > you run make again (like you might do when you modify a source file, > but then you could make individual modules to avoid recompiling > everything). > > On Oct 7, 2007, at 3:48 PM, Michael Barton wrote: > >> William >> >> I've been sort of following your work with Glynn to improve Mac >> compiling. If I compile from CVS today, will it work OK as before >> or am I likely to run into trouble? >> >> Michael >> > ----- > 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 > > __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Mon Oct 8 07:13:46 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 8 07:13:53 2007 Subject: [GRASS-dev] can there be spaces in DBF table names? Message-ID: <20071008181346.4f1a02d1.hamish_nospam@yahoo.com> Hi, I just tried importing a DBF file with v.in.db. It failed with: DBMI-DBF driver error: SQL parser error: in statement: select Sample_id, Longitude, Latitude from ss ll Error in db_open_select_cursor() ERROR: Cannot open select cursor: 'select Sample_id, Longitude, Latitude from ss ll' The table is in a file called "ss ll.dbf". If I rename it to remove the space in the name it works fine. Is this a quoting problem in GRASS or an illegal DBF table name? ? thanks Hamish From rez at touchofmadness.com Mon Oct 8 08:00:57 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Oct 8 08:01:00 2007 Subject: [GRASS-dev] can there be spaces in DBF table names? In-Reply-To: <20071008181346.4f1a02d1.hamish_nospam@yahoo.com> References: <20071008181346.4f1a02d1.hamish_nospam@yahoo.com> Message-ID: <1191823257.2958.333.camel@dev64.localdomain> On Mon, 2007-10-08 at 18:13 +1300, Hamish wrote: > Hi, > > I just tried importing a DBF file with v.in.db. It failed with: > > DBMI-DBF driver error: > SQL parser error: > in statement: > select Sample_id, Longitude, Latitude from ss ll > Error in db_open_select_cursor() > > ERROR: Cannot open select cursor: 'select Sample_id, Longitude, Latitude > from ss ll' > > > The table is in a file called "ss ll.dbf". > If I rename it to remove the space in the name it works fine. > Is this a quoting problem in GRASS or an illegal DBF table name? Yes, it's a quoting problem. SQL statements with spaces need to be enclosed with double quotes. -- 73, de Brad KB8UYR/6 From mlennert at club.worldonline.be Mon Oct 8 09:38:54 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Oct 8 09:41:41 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <18185.18930.6475.865204@cerise.gclements.plus.com> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> <18185.18930.6475.865204@cerise.gclements.plus.com> Message-ID: <4709DE8E.6010204@club.worldonline.be> On 07/10/07 23:04, Glynn Clements wrote: > Glynn Clements wrote: > >> My preferred approach would be to change lib/db/dbmi_base to simply >> not use XDR (that isn't anywhere near as much work as it might sound). > > I have attached a patch to do this. I haven't committed it yet in case > it breaks anything (and if it breaks anything, it may break a lot of > things). > > Could someone familiar with DBMI and vectors test it out? Thanks a lot ! I will test as soon as I find the time, latest tonight. Moritz From hamish_nospam at yahoo.com Mon Oct 8 12:03:25 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 8 12:03:30 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.119, 1.120 In-Reply-To: <20071006075328.GA23910@bartok.itc.it> References: <20071006050500.3E70B60016E@lists.intevation.de> <20071006075328.GA23910@bartok.itc.it> Message-ID: <20071008230325.3c9fae0a.hamish_nospam@yahoo.com> Markus Neteler wrote: > > Author: hamish .. > > Modified Files: > > init.sh > > Log Message: > > add test so don't overwrite VAR file without testing. I just > > commented the whole thing out though after fixing it, as the VAR and > > $MAPSET/dbf/ should be created on demand. To a raster-only or > > postgres-only user they are just file pollution. code bug #502 > > > > Index: init.sh > > =================================================================== > > RCS file: /grassrepository/grass6/lib/init/init.sh,v > > retrieving revision 1.119 > > retrieving revision 1.120 > > diff -u -d -r1.119 -r1.120 > > --- init.sh 3 Oct 2007 08:30:48 -0000 1.119 > > +++ init.sh 6 Oct 2007 05:04:58 -0000 1.120 > > @@ -495,9 +495,10 @@ > > cp "$GISDBASE/$LOCATION_NAME/PERMANENT/WIND" > > "$LOCATION/WIND" echo "Missing WIND file fixed" > > # predefine DBF driver > > - echo "DB_DRIVER: dbf" > "$LOCATION/VAR" > > - echo "DB_DATABASE: \$GISDBASE/\ > > $LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" > > - mkdir "$LOCATION"/dbf > > + # why is this needed ?? > > + #echo "DB_DRIVER: dbf" > "$LOCATION/VAR" > > + #echo "DB_DATABASE: \$GISDBASE/\ > > $LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" > > + #mkdir "$LOCATION"/dbf > Markus: > This is needed, if you start GRASS from CMD line with > full path to a non-existing mapset (which is then created). > So this should be restored somehow. so #typo user:~ $ grass63 grassdata/spearfish60/user11 Is meant to create: grassdata/spearfish60/user11/VAR grassdata/spearfish60/user11/WIND grassdata/spearfish60/user11/dbf/ (current CVS makes the new mapset but not the VAR and dbf/) ? I would think we should throw an error if the mapset doesn't exist (typo), and some '-n' flag is needed to create a new mapset from the command line. ? And don't create the VAR and dbf/ until needed. (why do those need to exist before any vector maps with tables are created?) ? Hamish From mlennert at club.worldonline.be Mon Oct 8 14:12:02 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Oct 8 14:14:48 2007 Subject: [GRASS-dev] trouble with man page generation Message-ID: <470A1E92.1090906@club.worldonline.be> Glynn, I have the feeling the latest change in the man/Makefile [1] has introduced a bug. When I run make in that directory nothing happens. When I use the previous version of the Makefile, man pages get created. Moritz [1] http://freegis.org/cgi-bin/viewcvs.cgi/grass6/man/Makefile.diff?r1=1.5&r2=1.6 From tutey at o2.pl Mon Oct 8 17:27:17 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 8 17:27:37 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] martinl: grass6/vector/v.edit a2b.c... In-Reply-To: <20071008091557.22B69602A28@lists.intevation.de> References: <20071008091557.22B69602A28@lists.intevation.de> Message-ID: <470A4C55.5000102@o2.pl> grass@intevation.de wrote: > Snapping to vertex enabled, also possibility to snap to > the features in background map(s). Hi Martin! This is great! I've been always missing the ability to snap to features in the background when digitizing in v.digit/QGIS GRASS Edit. Snap to vertices is also cool. Good job. Maciek From glynn at gclements.plus.com Mon Oct 8 17:37:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 8 17:37:12 2007 Subject: [GRASS-dev] trouble with man page generation In-Reply-To: <470A1E92.1090906@club.worldonline.be> References: <470A1E92.1090906@club.worldonline.be> Message-ID: <18186.20124.439032.715901@cerise.gclements.plus.com> Moritz Lennert wrote: > I have the feeling the latest change in the man/Makefile [1] has > introduced a bug. When I run make in that directory nothing happens. > When I use the previous version of the Makefile, man pages get created. Which version of make are you using? Also, do the manual pages already exist? They won't be re-created if they're newer than the HTML files (the previous version would always re-create them). -- Glynn Clements From grass-dev at grass.itc.it Mon Oct 8 18:26:12 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Mon Oct 8 18:26:20 2007 Subject: [GRASS-dev] [grass-code R][506] v.what.rast should be able to use other methods like bilinear Message-ID: <20071008162612.C397C4031D@pyrosoma.intevation.org> code R item #506, was opened at 2007-10-08 09:26 Status: Open Priority: 3 Submitted By: William Perkins (perk) Assigned to: Nobody (None) Summary: v.what.rast should be able to use other methods like bilinear Issue status: None GRASS component: vector Operating system: all Operating system version: Initial Comment: I would like to be able to sample a raster map using bilinear interpolation at points in a vector map. I want the resulting raster value to end up in an attribute column of the vector map. With existing 6.3 tools, this becomes a several step process. v.what.rast does what I need, but only with nearest neighbor sampling. I could use v.sample, but that creates a new map/table, and the only way to get the attribute back to the original map is to use an SQL join, which is unsupported in dbf and sqlite databases. v.drape could also be used, but it also creates a new vector map, which has to replace the original, and sometimes the raster information does not make sense as a Z-coordinate. I've made some changes to v.sample so that it will update a column (and not create a new map). However, I think the cleanest approach would be to have a new option for v.what.rast. Furthermore, IMHO, v.rast.what should, through options, do whatever v.sample does and v.sample should be be eliminated. Thanks. Bill ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=188&aid=506&group_id=21 From dylan.beaudette at gmail.com Mon Oct 8 19:43:01 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Oct 8 19:40:43 2007 Subject: [GRASS-dev] r.cats -> r.category + enhancements In-Reply-To: <923178.14954.qm@web52709.mail.re2.yahoo.com> References: <923178.14954.qm@web52709.mail.re2.yahoo.com> Message-ID: <200710081043.01358.dylan.beaudette@gmail.com> On Sunday 07 October 2007, Hamish wrote: > Hi, > > if there are no objections I will rename r.cats to be r.category (to match > v.category), leaving a r.cats symlink for backwards compatibility for the > duration of GRASS 6.x. > > In addition I mean to move/copy the copy cats from raster= option from > r.support to r.category and add a rules= option to import category labels > from a file. > (r.support raster= is not in 6.2.x so no crime to move it, although if > someone cares we can copy it with a note that it will be removed for GRASS > 7; or maybe r.suppport is a better place for these things, not r.cats? but > r.support is already crowded) > > I am unsure if it is better for the import format to match the current > r.cats output format, or to try and follow what r.reclass has. For FP maps > we will have to accept "a thru bLabel" as well as "aLabel" input > rules. ( comes from the fs= option) > > Note the category labels can be matched to FP ranges, see the nice writeup > in the GRASS 5.0 programmers' manual section 5.4. (I expect in the 6 prog > manual too but I don't have that on hand right now) > > > ideas welcome, > Hamish > This sounds like a great addition. Assigning labels to FP ranges, or even a simple approach to assigning labels to integer maps would be useful. Thanks! Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 From mlennert at club.worldonline.be Mon Oct 8 20:56:30 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Oct 8 20:59:17 2007 Subject: [GRASS-dev] trouble with man page generation In-Reply-To: <18186.20124.439032.715901@cerise.gclements.plus.com> References: <470A1E92.1090906@club.worldonline.be> <18186.20124.439032.715901@cerise.gclements.plus.com> Message-ID: <1408.85.10.67.131.1191869790.squirrel@geog-pc40.ulb.ac.be> On Mon, October 8, 2007 17:37, Glynn Clements wrote: > > Moritz Lennert wrote: > >> I have the feeling the latest change in the man/Makefile [1] has >> introduced a bug. When I run make in that directory nothing happens. >> When I use the previous version of the Makefile, man pages get created. > > Which version of make are you using? GNU Make 3.81 > > Also, do the manual pages already exist? They won't be re-created if > they're newer than the HTML files (the previous version would always > re-create them). Running make distclean, then configure & make, I get no errors during compilation, but there is no man directory in dist.i486-pc-linux-gnu/. When I revert to the previous version of the Makefile, I get dist.i486-pc-linux-gnu/man/man1 populated with the man pages. I'm no expert in Makefiles at all, but in the current version we have [...] MANPAGES := $(patsubst $(HTMLDIR)/%.html,$(MANDIR)/%.$(SECT),$(wildcard $(HTMLDIR)/*.html)) include $(MODULE_TOPDIR)/include/Make/Dir.make default: $(MANPAGES) $(MANDIR): $(MKDIR) $(MANDIR) $(MANDIR)/%.$(SECT): $(HTMLDIR)/%.html | $(MANDIR) The default is $(MANPAGES), is this a valid target ? Moritz From mlennert at club.worldonline.be Mon Oct 8 21:27:34 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Oct 8 21:30:21 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <18185.18930.6475.865204@cerise.gclements.plus.com> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> <18185.18930.6475.865204@cerise.gclements.plus.com> Message-ID: <1546.85.10.67.131.1191871654.squirrel@geog-pc40.ulb.ac.be> On Sun, October 7, 2007 23:04, Glynn Clements wrote: > > Glynn Clements wrote: > >> My preferred approach would be to change lib/db/dbmi_base to simply >> not use XDR (that isn't anywhere near as much work as it might sound). > > I have attached a patch to do this. I haven't committed it yet in case > it breaks anything (and if it breaks anything, it may break a lot of > things). > > Could someone familiar with DBMI and vectors test it out? > > Index: lib/db/dbmi_base/xdr.c > =================================================================== > RCS file: /grassrepository/grass6/lib/db/dbmi_base/xdr.c,v > retrieving revision 1.5 > diff -u -r1.5 xdr.c > --- lib/db/dbmi_base/xdr.c 26 Apr 2007 16:44:44 -0000 1.5 > +++ lib/db/dbmi_base/xdr.c 7 Oct 2007 20:50:35 -0000 > @@ -15,47 +15,84 @@ > *****************************************************************************/ > #include "xdr.h" > > +#ifdef __MINGW32__ > +#define USE_STDIO 0 > +#define USE_READN 1 > +#else > +#define USE_STDIO 1 > +#define USE_READN 0 > +#endif > + > +#ifndef USE_STDIO > +#include > +#endif > + > static FILE *_send, *_recv; > > -void > -db__set_protocol_fds (FILE *send, FILE *recv) > -{ > - _send = send; > - _recv = recv; > -} > +#if USE_READN > > -int > -xdr_begin_send(XDR *xdrs) > +static ssize_t readn(int fd, void *buf, size_t count) > { > - xdrstdio_create (xdrs, _send, XDR_ENCODE); > + ssize_t total = 0; > + > + while (total < count) > + { > + ssize_t n = read(fd, (char *) buf + total, count - total) the MINGW compiler complains about a missing ';' at the end here. gcc under linux doesn't...don't know why. > + ssize_t n = write(fd, (const char *) buf + total, count - total) same here Moritz From neteler at itc.it Mon Oct 8 22:07:03 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Oct 8 22:07:06 2007 Subject: [GRASS-dev] [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.119, 1.120 In-Reply-To: <20071008230325.3c9fae0a.hamish_nospam@yahoo.com> References: <20071006075328.GA23910@bartok.itc.it> <20071008230325.3c9fae0a.hamish_nospam@yahoo.com> Message-ID: <13103885.post@talk.nabble.com> HamishB wrote: > > Markus Neteler wrote: >> > Author: hamish > .. >> > Modified Files: >> > init.sh >> > Log Message: >> > add test so don't overwrite VAR file without testing. I just >> > commented the whole thing out though after fixing it, as the VAR and >> > $MAPSET/dbf/ should be created on demand. To a raster-only or >> > postgres-only user they are just file pollution. code bug #502 >> > >> > Index: init.sh >> > =================================================================== >> > RCS file: /grassrepository/grass6/lib/init/init.sh,v >> > retrieving revision 1.119 >> > retrieving revision 1.120 >> > diff -u -d -r1.119 -r1.120 >> > --- init.sh 3 Oct 2007 08:30:48 -0000 1.119 >> > +++ init.sh 6 Oct 2007 05:04:58 -0000 1.120 >> > @@ -495,9 +495,10 @@ >> > cp "$GISDBASE/$LOCATION_NAME/PERMANENT/WIND" >> > "$LOCATION/WIND" echo "Missing WIND file fixed" >> > # predefine DBF driver >> > - echo "DB_DRIVER: dbf" > "$LOCATION/VAR" >> > - echo "DB_DATABASE: \$GISDBASE/\ >> > $LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" >> > - mkdir "$LOCATION"/dbf >> > + # why is this needed ?? >> > + #echo "DB_DRIVER: dbf" > "$LOCATION/VAR" >> > + #echo "DB_DATABASE: \$GISDBASE/\ >> > $LOCATION_NAME/\$MAPSET/dbf/" >> "$LOCATION/VAR" >> > + #mkdir "$LOCATION"/dbf >> > Markus: >> This is needed, if you start GRASS from CMD line with >> full path to a non-existing mapset (which is then created). >> So this should be restored somehow. > > so > > #typo > user:~ $ grass63 grassdata/spearfish60/user11 > > Is meant to create: > grassdata/spearfish60/user11/VAR > grassdata/spearfish60/user11/WIND > grassdata/spearfish60/user11/dbf/ > > > (current CVS makes the new mapset but not the VAR and dbf/) > > ? > Yes, because only then it becomes a valid mapset without subsequent errors. HamishB wrote: > > I would think we should throw an error if the mapset doesn't exist > (typo), and some '-n' flag is needed to create a new mapset from the > command line. > ? > OK, sounds reasonable to me (less surprises in the script behaviour). HamishB wrote: > > And don't create the VAR and dbf/ until needed. (why do those need to > exist before any vector maps with tables are created?) > ? > Because any db./v. command will fail if those aren't present. DBF is the default (still). Costs only a very few bytes. Alternatively, fix all commands to auto-create when VAR and dbf/ are needed but I suspect that this would be lots of work. Better do it in one place right at the beginning (then we can also easily switch to SQLite as default DB driver in future. Markus -- View this message in context: http://www.nabble.com/Re%3A--GRASS-CVS--hamish%3A-grass6-lib-init-init.sh%2C-1.119%2C-1.120-tf4579018.html#a13103885 Sent from the Grass - Dev mailing list archive at Nabble.com. From tutey at o2.pl Mon Oct 8 22:08:59 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 8 22:09:06 2007 Subject: [GRASS-dev] db.execute segfaults on simplest SQL query Message-ID: <470A8E5B.5090107@o2.pl> This works: $ v.db.select pts_out col=rast_val rast_val 108.3656 102.906 41.60993 but, it's SQL counterpart segfaults: $ echo "SELECT rast_val FROM pts_out" | db.execute Segmentation fault dbmi: Protocol error ERROR: Error while executing: 'SELECT rast_val FROM pts_out ' DBF driver. Tested with latest 6.3 CVS. Has been the same in 6.3 CVS of 17.09.2007 at least and 6.2.2 CVS of 13.09.2007. Shall I open a ticket in the tracker? If more info or test dataset is needed pls let me know. Maciek From mlennert at club.worldonline.be Mon Oct 8 22:11:01 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Oct 8 22:13:48 2007 Subject: [GRASS-dev] wingrass: problems with some Makefiles Message-ID: <1695.85.10.67.131.1191874261.squirrel@geog-pc40.ulb.ac.be> Hello, Trying to recompile in windows (mingw), I get the errors in the attached log, which I never saw before and which seem to be linked to recent changes in Makefiles. For one, it seems like the mingw make version (GNU Make version 3.79.1; Built for i686-pc-msys) has some trouble with '|' in these files, but that is only an uneducated guess. r.terraflow has never compiled, but it used to be a different error (see http://moritz.homelinux.org/grass/wingrass/winmakeerror.log). Any ideas ? configure is launched as follows: ./configure --prefix=c:/grass --with-includes=/c/grasslibs/include --with-libs=/c/grasslibs/lib --with-cxx --without-jpeg --without-tiff -with-postgres --with-postgres-libs=/c/Programme/PostgreSQL/8.2/lib --with-postgres-includes=/c/Programme/PostgreSQL/8.2/include --with-sqlite --with-sqlite-includes=/c/MinGW/include --with-sqlite-libs=/c/MinGW/lib --with-opengl=windows --without-fftw --without-x --enable-x11=no --enable-shared=yes --with-tcltk-includes=/c/tcl/include --with-tcltk-libs=/c/tcl/bin --with-freetype --with-freetype-includes=/c/grasslibs/include/freetype2 --with-fftw --with-proj-share=/c/grass/share/proj Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: wingrass_errors.log Type: application/octet-stream Size: 10403 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071008/a1ce11c7/wingrass_errors-0001.obj From neteler at itc.it Mon Oct 8 22:15:29 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Oct 8 22:15:31 2007 Subject: [GRASS-dev] db.execute segfaults on simplest SQL query In-Reply-To: <470A8E5B.5090107@o2.pl> References: <470A8E5B.5090107@o2.pl> Message-ID: <20071008201529.GC24895@bartok.itc.it> Remember that v.db.select can follow to tables in different mapsets while the db.* command cannot. Can this be the issue? If not, could you provide some code to repeat in Spearfish or North Carolina dataset? Markus On Mon, Oct 08, 2007 at 10:08:59PM +0200, Maciej Sieczka wrote: > This works: > > $ v.db.select pts_out col=rast_val > rast_val > 108.3656 > 102.906 > 41.60993 > > but, it's SQL counterpart segfaults: > > $ echo "SELECT rast_val FROM pts_out" | db.execute > Segmentation fault > dbmi: Protocol error > ERROR: Error while executing: 'SELECT rast_val FROM pts_out > ' > > DBF driver. Tested with latest 6.3 CVS. Has been the same in > 6.3 CVS of 17.09.2007 at least and 6.2.2 CVS of 13.09.2007. > > Shall I open a ticket in the tracker? If more info or test > dataset is needed pls let me know. > > Maciek > ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From mlennert at club.worldonline.be Mon Oct 8 22:18:22 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Oct 8 22:21:11 2007 Subject: [GRASS-dev] db.execute segfaults on simplest SQL query In-Reply-To: <470A8E5B.5090107@o2.pl> References: <470A8E5B.5090107@o2.pl> Message-ID: <1712.85.10.67.131.1191874702.squirrel@geog-pc40.ulb.ac.be> On Mon, October 8, 2007 22:08, Maciej Sieczka wrote: > This works: > > $ v.db.select pts_out col=rast_val > rast_val > 108.3656 > 102.906 > 41.60993 > > but, it's SQL counterpart segfaults: > > $ echo "SELECT rast_val FROM pts_out" | db.execute > Segmentation fault > dbmi: Protocol error > ERROR: Error while executing: 'SELECT rast_val FROM pts_out > ' All select queries need to be sent via db.select. All other queries via db.execute. I.e. try $ echo "SELECT rast_val FROM pts_out" | db.select Moritz From tutey at o2.pl Mon Oct 8 22:27:29 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 8 22:27:44 2007 Subject: [GRASS-dev] [grass-code R][506] v.what.rast should be able to use other methods like bilinear In-Reply-To: <20071008162612.C397C4031D@pyrosoma.intevation.org> References: <20071008162612.C397C4031D@pyrosoma.intevation.org> Message-ID: <470A92B1.8050506@o2.pl> grass-dev@grass.itc.it wrote: > v.what.rast does what I need, but only with nearest > neighbor sampling. I could use v.sample, but that > creates a new map/table, and the only way to get the > attribute back to the original map is to use an SQL join, William, For a workaround, you can also link the output vector's datatable to another layer in the input vector; sth like: $ v.sample -b input=pts_in col=value out=pts_out rast=xxx $ v.db.connect map=pts_in driver=dbf table=pts_out layer=2 BTW - anybody knows how to just copy a column from table to table? Or update an existing column in one column with the content of a column in another table? That's be the easiest workaround. > which is unsupported in dbf and sqlite databases. SQLite supports JOIN AFAICT. Does it fail in GRASS? Can you provide a test case? > Furthermore, IMHO, v.rast.what should, > through options, do whatever v.sample does and v.sample > should be be eliminated. I have added the suggestion to GRASS 7 ideas on WIKI. Maciek From tutey at o2.pl Mon Oct 8 22:32:00 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 8 22:32:12 2007 Subject: [GRASS-dev] db.execute segfaults on simplest SQL query In-Reply-To: <1712.85.10.67.131.1191874702.squirrel@geog-pc40.ulb.ac.be> References: <470A8E5B.5090107@o2.pl> <1712.85.10.67.131.1191874702.squirrel@geog-pc40.ulb.ac.be> Message-ID: <470A93C0.1080805@o2.pl> Moritz Lennert wrote: > On Mon, October 8, 2007 22:08, Maciej Sieczka wrote: >> This works: >> >> $ v.db.select pts_out col=rast_val >> rast_val >> 108.3656 >> 102.906 >> 41.60993 >> >> but, it's SQL counterpart segfaults: >> >> $ echo "SELECT rast_val FROM pts_out" | db.execute >> Segmentation fault >> dbmi: Protocol error >> ERROR: Error while executing: 'SELECT rast_val FROM pts_out >> ' > All select queries need to be sent via db.select. All other queries via > db.execute. I.e. try > > $ echo "SELECT rast_val FROM pts_out" | db.select Yes, perfect. Sorry for false alarm. Anyway, if db.execute could not segfault and say something instructive it would be great. Eg.: "db.execute does not support SELECT queries. Use db.select instead." Maciek From grass-bugs at intevation.de Mon Oct 8 22:44:16 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Oct 8 22:44:18 2007 Subject: [GRASS-dev] [bug #4141] (grass) more sql statements for db.execute Message-ID: <20071008204416.0EBE7602A2F@lists.intevation.de> guest wrote (Mon, Mar 6 2006 17:36:36): > maybe this sql statement support could be added to db.execute as well: > > this doesn't work: > echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE > plz = gkz" | db.execute > > this is fine: > echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE > plz = gkz" | psql -U dassau ifak By accident I have laerned today that db.execute is not supposed to support SELECT query. We have db.select for that. In that case, do we call the case closed? Maciek -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Mon Oct 8 22:46:38 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Oct 8 22:49:25 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <18185.18930.6475.865204@cerise.gclements.plus.com> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> <18185.18930.6475.865204@cerise.gclements.plus.com> Message-ID: <1790.85.10.67.131.1191876398.squirrel@geog-pc40.ulb.ac.be> On Sun, October 7, 2007 23:04, Glynn Clements wrote: > > Glynn Clements wrote: > >> My preferred approach would be to change lib/db/dbmi_base to simply >> not use XDR (that isn't anywhere near as much work as it might sound). > > I have attached a patch to do this. I haven't committed it yet in case > it breaks anything (and if it breaks anything, it may break a lot of > things). > > Could someone familiar with DBMI and vectors test it out? Rapid testing in Debian (v.out/in.ogr, v.univar, d.vect.thematic, g.copy) with dbf, sqlite, postgres does not show any problems. Will test in windows as soon as I solve the compile problems. Moritz From william.perkins at pnl.gov Mon Oct 8 23:59:02 2007 From: william.perkins at pnl.gov (William A. Perkins) Date: Mon Oct 8 23:59:06 2007 Subject: [GRASS-dev] [grass-code R][506] v.what.rast should be able to use other methods like bilinear In-Reply-To: <470A92B1.8050506@o2.pl> References: <20071008162612.C397C4031D@pyrosoma.intevation.org> <470A92B1.8050506@o2.pl> Message-ID: <18186.43046.423931.379801@bearflag.pnl.gov> Maciej, >>>>> "Maciej" == Maciej Sieczka writes: Maciej> grass-dev@grass.itc.it wrote: >> v.what.rast does what I need, but only with nearest >> neighbor sampling. I could use v.sample, but that >> creates a new map/table, and the only way to get the >> attribute back to the original map is to use an SQL join, Maciej> William, Maciej> For a workaround, you can also link the output vector's Maciej> datatable to another layer in the input vector; sth like: Maciej> $ v.sample -b input=pts_in col=value out=pts_out rast=xxx Maciej> $ v.db.connect map=pts_in driver=dbf table=pts_out layer=2 This is a very good idea. I will start doing this. Maciej> BTW - anybody knows how to just copy a column from table to Maciej> table? Or update an existing column in one column with the Maciej> content of a column in another table? That's be the easiest Maciej> workaround. What I usually end up doing is temporarily connecting to a Postgres database, for which this statement works (in your example): UPDATE pts_in SET value = pts_out.rast_val FROM pts_out WHERE pts_in.cat = pts_out.cat; However, I try to avoid keeping attributes in Postgres because I access by GRASS databases from a variety of computers, some of which do not have access to the Postgres server. >> which is unsupported in dbf and sqlite databases. Maciej> SQLite supports JOIN AFAICT. Does it fail in GRASS? Can you Maciej> provide a test case? The documentation says it's supported, and I have only been able to do joins with SELECT, but not UPDATE. The way I read the SQLite documentation, I should be able to do this: UPDATE pts_in SET value = pts_out.rast_val WHERE pts_in.cat = pts_out.cat; (sqlite does not allow a FROM clause in UPDATE). But I've never gotten that to work. I worked up a little example for which I've attached the output. I was working with today's CVS and on Mac OS X. >> Furthermore, IMHO, v.rast.what should, >> through options, do whatever v.sample does and v.sample >> should be be eliminated. Maciej> I have added the suggestion to GRASS 7 ideas on WIKI. Thanks. Maciej> Maciek Bill -- Bill Perkins Pacific Northwest National Laboratory Environmental Technologies Division, Hydrology Group P.O. Box 999 MSIN K9-36 Richland, Washington, USA 99352 voice: (509) 372-6131 fax: (509) 372-6089 email: william.perkins@pnl.gov -------------- next part -------------- GRASS 6.3.cvs > db.connect -p driver:sqlite database:$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db schema: group: GRASS 6.3.cvs > cat junk.sql drop table tmp1; drop table tmp2; create table tmp1 ( cat integer, num integer ); insert into tmp1 ( cat, num) values (1,1); insert into tmp1 ( cat, num) values (2,2); insert into tmp1 ( cat, num) values (3,3); insert into tmp1 ( cat, num) values (4,4); create table tmp2 ( cat integer, num integer ); insert into tmp2 ( cat, num) values (1,5); insert into tmp2 ( cat, num) values (2,6); insert into tmp2 ( cat, num) values (3,7); insert into tmp2 ( cat, num) values (4,8); GRASS 6.3.cvs > db.execute -i --v < ~/tmp/junk.sql GRASS 6.3.cvs > echo 'select tmp1.cat, tmp1.num, tmp2.num from tmp1, tmp2 where tmp1.cat = tmp2.cat' | db.select output=',' vs='' cat,num,num 1,1,5 2,2,6 3,3,7 4,4,8 GRASS 6.3.cvs > echo 'update tmp1 set num = tmp2.num where tmp1.cat = tmp2.cat' | db.execute DBMI-SQLite driver error: Error in sqlite3_prepare(): no such column: tmp2.num ERROR: Error while executing: 'update tmp1 set num = tmp2.num where tmp1.cat = tmp2.cat ' GRASS 6.3.cvs > db.connect driver=pg database=template1 GRASS 6.3.cvs > db.connect -p driver:pg database:template1 schema: group: GRASS 6.3.cvs > db.execute -i --v < ~/tmp/junk.sql DBMI-Postgres driver error: Cannot execute: drop table tmp1 ERROR: table "tmp1" does not exist WARNING: Error while executing: 'drop table tmp1' DBMI-Postgres driver error: Cannot execute: drop table tmp2 ERROR: table "tmp2" does not exist WARNING: Error while executing: 'drop table tmp2' GRASS 6.3.cvs > echo 'select tmp1.cat, tmp1.num, tmp2.num from tmp1, tmp2 where tmp1.cat = tmp2.cat' | db.select output=',' vs='' cat,num,num 1,1,5 2,2,6 3,3,7 4,4,8 GRASS 6.3.cvs > echo 'update tmp1 set num = tmp2.num from tmp2 where tmp1.cat = tmp2.cat' | db.execute GRASS 6.3.cvs > echo 'select tmp1.cat, tmp1.num, tmp2.num from tmp1, tmp2 where tmp1.cat = tmp2.cat' | db.select output=',' vs='' cat,num,num 1,5,5 2,6,6 3,7,7 4,8,8 From glynn at gclements.plus.com Tue Oct 9 00:46:32 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 9 00:46:44 2007 Subject: [GRASS-dev] trouble with man page generation In-Reply-To: <1408.85.10.67.131.1191869790.squirrel@geog-pc40.ulb.ac.be> References: <470A1E92.1090906@club.worldonline.be> <18186.20124.439032.715901@cerise.gclements.plus.com> <1408.85.10.67.131.1191869790.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18186.45896.656463.981866@cerise.gclements.plus.com> Moritz Lennert wrote: > >> I have the feeling the latest change in the man/Makefile [1] has > >> introduced a bug. When I run make in that directory nothing happens. > >> When I use the previous version of the Makefile, man pages get created. > > > > Which version of make are you using? > > GNU Make 3.81 Same here. > > Also, do the manual pages already exist? They won't be re-created if > > they're newer than the HTML files (the previous version would always > > re-create them). > > Running make distclean, then configure & make, I get no errors during > compilation, but there is no man directory in dist.i486-pc-linux-gnu/. > When I revert to the previous version of the Makefile, I get > dist.i486-pc-linux-gnu/man/man1 populated with the man pages. Duh; it's because I moved the "include" line (unnecessarily). The MANDIR and HTMLDIR variables depend upon GISBASE, but it isn't set until Dir.make gets included. I have GISBASE set in my normal shell environment, and make was picking it up from there. Fixed in CVS as: --- man/Makefile 30 Sep 2007 12:10:30 -0000 1.6 +++ man/Makefile 8 Oct 2007 22:43:05 -0000 @@ -1,5 +1,7 @@ MODULE_TOPDIR = .. +include $(MODULE_TOPDIR)/include/Make/Dir.make + # some definitions SECT = 1 MANDIR = $(GISBASE)/man/man$(SECT) @@ -7,8 +9,6 @@ HTML2MAN = GRASS_PERL=${PERL} VERSION_NUMBER=${GRASS_VERSION_NUMBER} sh $(GRASS_HOME)/tools/g.html2man/g.html2man MANPAGES := $(patsubst $(HTMLDIR)/%.html,$(MANDIR)/%.$(SECT),$(wildcard $(HTMLDIR)/*.html)) - -include $(MODULE_TOPDIR)/include/Make/Dir.make default: $(MANPAGES) I'm wondering if this has caused me to miss other build problems. -- Glynn Clements From glynn at gclements.plus.com Tue Oct 9 00:50:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Oct 9 00:50:17 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <1546.85.10.67.131.1191871654.squirrel@geog-pc40.ulb.ac.be> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> <18185.18930.6475.865204@cerise.gclements.plus.com> <1546.85.10.67.131.1191871654.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18186.46109.997950.634069@cerise.gclements.plus.com> Moritz Lennert wrote: > > +static ssize_t readn(int fd, void *buf, size_t count) > > { > > - xdrstdio_create (xdrs, _send, XDR_ENCODE); > > + ssize_t total = 0; > > + > > + while (total < count) > > + { > > + ssize_t n = read(fd, (char *) buf + total, count - total) > > the MINGW compiler complains about a missing ';' at the end here. gcc > under linux doesn't...don't know why. Because it isn't compiled on Linux: #ifdef __MINGW32__ #define USE_STDIO 0 #define USE_READN 1 #else #define USE_STDIO 1 #define USE_READN 0 #endif Linux uses stdio, Windows uses readn/writen. I thought that I tested those functions; obviously not. -- Glynn Clements From neteler at itc.it Tue Oct 9 01:00:35 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Oct 9 01:00:39 2007 Subject: [GRASS-dev] [grass-code R][506] v.what.rast should be able to use other methods like bilinear In-Reply-To: <18186.43046.423931.379801@bearflag.pnl.gov> References: <20071008162612.C397C4031D@pyrosoma.intevation.org> <470A92B1.8050506@o2.pl> <18186.43046.423931.379801@bearflag.pnl.gov> Message-ID: <13106492.post@talk.nabble.com> William A. Perkins wrote: > > Maciej> BTW - anybody knows how to just copy a column from table to > Maciej> table? Or update an existing column in one column with the > Maciej> content of a column in another table? That's be the easiest > Maciej> workaround. > > What I usually end up doing is temporarily connecting to a Postgres > database, for which this statement works (in your example): > ... > Not sure but v.db.join comes to mind... it includes even a trick to make joins in SQLite (which isn't really supported by it). Markus -- View this message in context: http://www.nabble.com/-grass-code-R--506--v.what.rast-should-be-able-to-use-other-methods-like-bilinear-tf4589359.html#a13106492 Sent from the Grass - Dev mailing list archive at Nabble.com. From rez at touchofmadness.com Tue Oct 9 01:33:35 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Oct 9 01:33:40 2007 Subject: [GRASS-dev] [bug #4141] (grass) more sql statements for db.execute In-Reply-To: <20071008204416.0EBE7602A2F@lists.intevation.de> References: <20071008204416.0EBE7602A2F@lists.intevation.de> Message-ID: <1191886415.17343.11.camel@dev64.localdomain> On Mon, 2007-10-08 at 22:44 +0200, Maciek Sieczka via RT wrote: > guest wrote (Mon, Mar 6 2006 17:36:36): > > > maybe this sql statement support could be added to db.execute as well: > > > > this doesn't work: > > echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE > > plz = gkz" | db.execute > > > > this is fine: > > echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE > > plz = gkz" | psql -U dassau ifak > > By accident I have laerned today that db.execute is not supposed to support > SELECT query. We have db.select for that. In that case, do we call the case > closed? > > Maciek (I didn't follow the entire thread, so my comments may be useless. YMMV. :-) Personally, I'd like db.select merged into db.execute. I don't use the db.* commands daily and I've fallen into the above case before. However, I quickly remember the more appropriate usage. OTOH, db.execute isn't supposed to return and resulting set, which is why db.select exists (to my knowledge). I've committed a change in CVS to db.execute.html noting this and suggests using db.select. I would consider this closed. -- 73, de Brad KB8UYR/6 From rez at touchofmadness.com Tue Oct 9 03:21:41 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Oct 9 03:22:17 2007 Subject: [GRASS-dev] db.execute segfaults on simplest SQL query In-Reply-To: <470A93C0.1080805@o2.pl> References: <470A8E5B.5090107@o2.pl> <1712.85.10.67.131.1191874702.squirrel@geog-pc40.ulb.ac.be> <470A93C0.1080805@o2.pl> Message-ID: <1191892901.17343.18.camel@dev64.localdomain> On Mon, 2007-10-08 at 22:32 +0200, Maciej Sieczka wrote: > Moritz Lennert wrote: > > On Mon, October 8, 2007 22:08, Maciej Sieczka wrote: > >> This works: > >> > >> $ v.db.select pts_out col=rast_val > >> rast_val > >> 108.3656 > >> 102.906 > >> 41.60993 > >> > >> but, it's SQL counterpart segfaults: > >> > >> $ echo "SELECT rast_val FROM pts_out" | db.execute > >> Segmentation fault > >> dbmi: Protocol error > >> ERROR: Error while executing: 'SELECT rast_val FROM pts_out > >> ' > > > All select queries need to be sent via db.select. All other queries via > > db.execute. I.e. try > > > > $ echo "SELECT rast_val FROM pts_out" | db.select > > Yes, perfect. Sorry for false alarm. > > Anyway, if db.execute could not segfault and say something > instructive it would be great. Eg.: > > "db.execute does not support SELECT queries. Use db.select > instead." Committed to CVS. -- 73, de Brad KB8UYR/6 From hamish_nospam at yahoo.com Tue Oct 9 03:33:49 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Oct 9 03:34:03 2007 Subject: [GRASS-dev] [bug #4141] (grass) more sql statements for db.execute In-Reply-To: <1191886415.17343.11.camel@dev64.localdomain> References: <20071008204416.0EBE7602A2F@lists.intevation.de> <1191886415.17343.11.camel@dev64.localdomain> Message-ID: <20071009143349.072a506b.hamish_nospam@yahoo.com> > Maciek wrote: > > By accident I have laerned today that db.execute is not supposed to > > support SELECT query. We have db.select for that. In that case, do we > > call the case closed? Brad Douglas wrote: > Personally, I'd like db.select merged into db.execute. I don't use the > db.* commands daily and I've fallen into the above case before. > However, I quickly remember the more appropriate usage. > > OTOH, db.execute isn't supposed to return and resulting set, which is > why db.select exists (to my knowledge). I've committed a change in CVS > to db.execute.html noting this and suggests using db.select. IIRC in an old post Radim explained why that must be, but can't find it now. > I would consider this closed. still outstanding: db.execute needs to throw an error- not segfault -when passed SELECT. Hamish From hamish_nospam at yahoo.com Tue Oct 9 03:37:54 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Oct 9 03:37:58 2007 Subject: [GRASS-dev] [grass-code R][506] v.what.rast should be able to use other methods like bilinear In-Reply-To: <20071008162612.C397C4031D@pyrosoma.intevation.org> References: <20071008162612.C397C4031D@pyrosoma.intevation.org> Message-ID: <20071009143754.120ca779.hamish_nospam@yahoo.com> > I would like to be able to sample a raster map using bilinear > interpolation at points in a vector map. I want the resulting raster > value to end up in an attribute column of the vector map. With existing > 6.3 tools, this becomes a several step process. > > v.what.rast does what I need, but only with nearest neighbor sampling. > I could use v.sample, but that creates a new map/table, and the only > way to get the attribute back to the original map is to use an SQL > join, which is unsupported in dbf and sqlite databases. v.drape could > also be used, but it also creates a new vector map, which has to > replace the original, and sometimes the raster information does not > make sense as a Z-coordinate. > > I've made some changes to v.sample so that it will update a column (and > not create a new map). However, I think the cleanest approach would be > to have a new option for v.what.rast. Furthermore, IMHO, v.rast.what > should, through options, do whatever v.sample does and v.sample should > be be eliminated. v.buffer + v.rast.stats? Then if you like attach v.buffer centroid attributes to original points with v.distance or just extract the centroids and convert them to points (v.extract + v.type). Hamish From twiens at interbaun.com Tue Oct 9 05:16:52 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Tue Oct 9 05:16:08 2007 Subject: [GRASS-dev] Python swig Message-ID: <20071008211652.79bb3a56.twiens@interbaun.com> I was having troubles getting the python swig interfact to install from my cvs build. I found the following. Making successfully in the swig/python dir and then run make install from the cvs root dir didn't copy the necessary files to the proper destinations. I had to copy these myself by hand. Second, it wouldn't work on my ubuntu fiesty system because like 6.10 stack protection is set is set to on. So I had to add the following flag to the Make file: -fno-stack-protector to get it to compile into a form that was useable on my system. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From twiens at interbaun.com Tue Oct 9 06:23:10 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Tue Oct 9 06:22:18 2007 Subject: [GRASS-dev] v.info -c Message-ID: <20071008222310.1f32e816.twiens@interbaun.com> cvs version reports: Displaying column types/names for database connection of layer 0: Database connection not defined However GUI inspection tool manages to find the data attribute data, so there seems to be something odd in the current build of v.info. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From twiens at interbaun.com Tue Oct 9 06:51:14 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Tue Oct 9 06:50:19 2007 Subject: [GRASS-dev] v.to.rast in cvs Message-ID: <20071008225114.18868170.twiens@interbaun.com> running using a column attribute without the layer option gives: ERROR: Unable to get layer info for vector map Running witht the layer option gives: Sorry, is not a valid parameter T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From twiens at interbaun.com Tue Oct 9 07:04:21 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Tue Oct 9 07:03:27 2007 Subject: [GRASS-dev] v.to.rast in cvs: RESOLVED In-Reply-To: <20071008225114.18868170.twiens@interbaun.com> References: <20071008225114.18868170.twiens@interbaun.com> Message-ID: <20071008230421.23fc3d6e.twiens@interbaun.com> On Mon, 8 Oct 2007 22:51:14 -0600 Trevor Wiens wrote: > running using a column attribute without the layer option gives: > > ERROR: Unable to get layer info for vector map > > Running witht the layer option gives: > > Sorry, is not a valid parameter > After going into the directory and remaking, it appears to have resolved itself. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From twiens at interbaun.com Tue Oct 9 07:20:35 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Tue Oct 9 07:19:40 2007 Subject: [GRASS-dev] v.info -c RESOLVED In-Reply-To: <20071008222310.1f32e816.twiens@interbaun.com> References: <20071008222310.1f32e816.twiens@interbaun.com> Message-ID: <20071008232035.0f0b631a.twiens@interbaun.com> On Mon, 8 Oct 2007 22:23:10 -0600 Trevor Wiens wrote: > cvs version reports: > > Displaying column types/names for database connection of layer 0: > Database connection not defined > > However GUI inspection tool manages to find the data attribute data, so there seems to be something odd in the current build of v.info. as with v.to.rast, a rebuild fixed the problem. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From hamish_nospam at yahoo.com Tue Oct 9 12:33:31 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Oct 9 12:33:33 2007 Subject: [GRASS-dev] Python swig In-Reply-To: <20071008211652.79bb3a56.twiens@interbaun.com> Message-ID: <710239.98186.qm@web52703.mail.re2.yahoo.com> Trevor Wiens wrote: > I was having troubles getting the python swig interfact to install from my > cvs build. > > I found the following. Making successfully in the swig/python dir and then > run make install from the cvs root dir didn't copy the necessary files to the > proper destinations. I had to copy these myself by hand. > > Second, it wouldn't work on my ubuntu fiesty system because like 6.10 stack > protection is set is set to on. So I had to add the following flag to the > Make file: -fno-stack-protector to get it to compile into a form that was > useable on my system. you might have a look at the following thread, AFAIK several of the 'make' issues raised in it have still not been fixed. http://thread.gmane.org/gmane.comp.gis.grass.devel/20751 Hamish ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From hamish_nospam at yahoo.com Tue Oct 9 14:42:13 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Oct 9 14:42:21 2007 Subject: [GRASS-dev] v.what.rast support for centroids, v.rast.stats speed, r.category update Message-ID: <20071010014213.a1bb9ca4.hamish_nospam@yahoo.com> Hi, any comments re. the following patch? it lets you use v.what.rast for centroids as well as points. I have made a (100m) buffer around a number of points, and in addition to the raster stats for the buffer provided by v.rast.stats I want to know the exact value at the center point (field sampling station). In this case my centroid is exactly in the middle of the area so it's ok. I'm not so sure that this patch is useful when the centroid is randomly placed within the area, hence this email. Then again the result is actually uploaded to the centroid, not the area, so maybe all-correct just sometimes requires a grain of salt in the interpretation. ??? Another issue touched by a recent thread* re. bounding boxes of features within a vector map: v.rast.stats is VERY slow. This is because it creates a r.mapcalc MASK at the full raster region resolution for each cat it processes. When picking out small vector buffers from a large raster this is highly inefficient. It would be much better to find the bounding box of each selected vector cat, zoom in on it with the GRASS_REGION or WIND_OVERRIDE enviro variables for the duration of the r.mapcalc and r.univar calls for each cat. [*] http://thread.gmane.org/gmane.comp.gis.grass.user/20327 I would be cool to have a C module which could do 'v.info -g' bounds for cats=1,3,5-9,13 &/or where='SQL query'. ?? Hamish ps- r.category label setting updates are mostly done, it just needs some cleaning. I expect it will need more testing and debugging than most changes as the labeling lib fns are very dusty. -------------- next part -------------- A non-text attachment was scrubbed... Name: vwr_centroids.diff Type: text/x-diff Size: 1039 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071010/7b2aa50f/vwr_centroids.bin From grass-dev at grass.itc.it Tue Oct 9 17:11:45 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Tue Oct 9 17:11:49 2007 Subject: [GRASS-dev] [grass-code I][507] r.in.xyz: a segfault with particular dataset Message-ID: <20071009151145.D58FD40377@pyrosoma.intevation.org> code I item #507, was opened at 2007-10-09 17:11 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Hamish Bowman (hamish) Summary: r.in.xyz: a segfault with particular dataset Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: raster Operating system: Linux Operating system version: Ubuntu Dapper 64bit GRASS CVS checkout date, if applies (YYMMDD): 071009 Initial Comment: r.in.xyz has been segfaulting with a particular dataset. It's quite big (23 MB bzipped) and I don't know how to provide it but let me know if ther's a need+way to. Details: $r.in.xyz -g input=tin_nieciag.xyz output=tin_nie ciag.xyz method=min type=DCELL fs="|" x=1 y=2 z=3 percent=100 n=5725102.149034 s=5705608.286234 e=587119.577053 w=568715.830892 b=69.431216 t= 224.696106 $ g.region n=5725102.149034 s=5705608.286234 e=587 119.577053 w=568715.830892 res=1 -a $ gdb r.in.xyz $ run input=tin_nieciag.xyz output=tin_nie ciag.xyz method=min type=DCELL fs="|" x=1 y=2 z=3 percent=100 Starting program: /usr/local/grass-6.3.cvs/bin/r.in.xyz input=tin_nieciag.xyz output=tin_nieciag.xyz method=min type=DCELL fs="|" x=1 y=2 z=3 percent=100 Scanning data ... 67% Program received signal SIGSEGV, Segmentation fault. 0x00002aaaaabf3c09 in G_is_d_null_value (dcellVal=0x2aaa2cd4e960) at null_val.c:502 502 if(((unsigned char *) dcellVal)[i] != (gdb) bt #0 0x00002aaaaabf3c09 in G_is_d_null_value (dcellVal=0x2aaa2cd4e960) at null_val.c:502 #1 0x00002aaaaabf3acb in G_is_null_value (rast=0x2aaa2cd4e960, data_type=2) at null_val.c:365 #2 0x000000000040439c in update_min (array=0x2aaaab3b4010, cols=18405, row=14767, col=4767, map_type=2, value=155.11966910999999) at support.c:74 #3 0x00000000004032c6 in main (argc=10, argv=0x7ffffffd43c8) at main.c:485 ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=507&group_id=21 From michael.barton at asu.edu Tue Oct 9 17:55:45 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Oct 9 17:58:09 2007 Subject: [GRASS-dev] v.what.rast support for centroids, v.rast.stats speed, r.category update In-Reply-To: <20071010014213.a1bb9ca4.hamish_nospam@yahoo.com> Message-ID: On 10/9/07 5:42 AM, "Hamish" wrote: > Hi, > > any comments re. the following patch? > > it lets you use v.what.rast for centroids as well as points. > > I have made a (100m) buffer around a number of points, and in addition to > the raster stats for the buffer provided by v.rast.stats I want to know > the exact value at the center point (field sampling station). In this > case my centroid is exactly in the middle of the area so it's ok. I'm not > so sure that this patch is useful when the centroid is randomly placed > within the area, hence this email. Then again the result is actually > uploaded to the centroid, not the area, so maybe all-correct just > sometimes requires a grain of salt in the interpretation. > This brings up an issue that we might want to think about for GRASS 7. Currently, centroids must always be created manually to transform a closed polyline into an area. While we might want to keep this as an option (but maybe not), I think it would be better to have some kind of 'area-creation' utility that would transform a close polyline into an area by automatically adding a centroid at a predefined center location (geometric center or other measure) and adding a cat value. Then analytical utilities like you are discussing here could be more reliable. > > > Another issue touched by a recent thread* re. bounding boxes of features > within a vector map: v.rast.stats is VERY slow. This is because it creates > a r.mapcalc MASK at the full raster region resolution for each cat it > processes. When picking out small vector buffers from a large raster this > is highly inefficient. It would be much better to find the bounding box > of each selected vector cat, zoom in on it with the GRASS_REGION or > WIND_OVERRIDE enviro variables for the duration of the r.mapcalc and > r.univar calls for each cat. > > [*] http://thread.gmane.org/gmane.comp.gis.grass.user/20327 > > I would be cool to have a C module which could do 'v.info -g' bounds for > cats=1,3,5-9,13 &/or where='SQL query'. ?? > > > Hamish > > ps- r.category label setting updates are mostly done, it just needs some > cleaning. I expect it will need more testing and debugging than most > changes as the labeling lib fns are very dusty. Just want to say thanks for these new extensions to r.cat -> r.category. Michael __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From grass-bugs at intevation.de Tue Oct 9 18:48:03 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Tue Oct 9 18:48:04 2007 Subject: [GRASS-dev] [bug #1470] (grass) full floats support for r.colors, please Message-ID: <20071009164803.04B67602A2F@lists.intevation.de> glynn@gclements.plus.com wrote (Sun, Oct 7 2007 16:43:41): > IOW a random colour table only makes sense if the data consists of > discrete categories rather than a scalar value. Integer maps can be > either categories or scalars, but FP maps are always scalars. In that case I'd call the case closed. If anybody minds please re-open the ticket. Maciek -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Tue Oct 9 18:57:07 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Oct 9 18:57:18 2007 Subject: [GRASS-dev] db.execute: ".execute" suffix missing in man page Message-ID: <470BB2E3.7070403@o2.pl> Hi, In Firefox and Lynx browsers the ".execute" part of "db.execute" is missing above the module description. It also not there in "man db.execute" output. Applies to current 6.3 CVS and checkouts few weeks old. In 6.2 it's OK though. See a copy/paste: --- NAME db - Executes any SQL statement. KEYWORDS database, SQL SYNOPSIS db db help db [-i] [input=name] [driver=name] [database=name] [--verbose] [--quiet] --- Does anybody confirm? Maciek From tutey at o2.pl Tue Oct 9 19:23:50 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Oct 9 19:24:05 2007 Subject: [GRASS-dev] Re: [grass-code I][497] r.spread not working In-Reply-To: <20071002192511.25D5040363@pyrosoma.intevation.org> References: <20071002192511.25D5040363@pyrosoma.intevation.org> Message-ID: <470BB926.5090306@o2.pl> Hi Everyone In regard to this bug report - has anybody recently tried r.spread, firedemo.sh with GRASS 6.3 or 6.2 and could verify the problems Ljiljana describes? Please read her latest notes below: > Comment By: Ljiljana Bodrozic (ljiljana) Date: 2007-10-02 > 21:25 > > Actualy, I tried on windows/cygwin platform, > linux (suse, gen-too and debian) and recently mac os. On > every platform problem is the same. Although I am working > on my own dataset, once I downloaded a firedemo location > dataset, where r.ros and r.spread were presented, I can't > remember where from, and the problem was the same. The > issue is following: The firedemo.sh script runs r.ros, > produces my_ros set of maps, and after it starts > r.spread, it freezes. The same problem occurs several > versions of grass ( I am not sure, but I think that 6.0.1 > was working, but 6.0.2 not). Curently I am using 5.7 > where the module works great. > > I wrote about the same problem a year or two ago on > grasslist. Cheers Maciek From tutey at o2.pl Tue Oct 9 19:38:19 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Oct 9 19:38:26 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> Message-ID: <470BBC8B.70902@o2.pl> Frank Warmerdam wrote: > On 10/1/07, Hamish wrote: >> What support software to use seems to be a totally separate issue from >> where to host things, as Intevation seems to be happy to provide what we >> ask for as best they can, and I guess (but don't know) that the OSGeo >> admins would be supportive too. > By default OSGeo SAC provides Trac+Subversion. Does anybody know if OSGEO's Trac setup allows for replying to tracker by email? Would that work? : 1. a GRASS bug is reported to Trac 2. notification is forwarded to GRASS dev list 3. a developer replies via email including Trac's email address and GRASS dev ML email address 4. the email is stored in the given Trac ticket I'm asking this because the lack of such funtionality seems the biggest problem with GRASS GForge trackers. Maciek From warmerdam at pobox.com Tue Oct 9 20:08:02 2007 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Oct 9 20:02:54 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <470BBC8B.70902@o2.pl> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> <470BBC8B.70902@o2.pl> Message-ID: <470BC382.2050707@pobox.com> Maciej Sieczka wrote: > Does anybody know if OSGEO's Trac setup allows for replying > to tracker by email? > > Would that work? : > > 1. a GRASS bug is reported to Trac > 2. notification is forwarded to GRASS dev list > 3. a developer replies via email including Trac's email > address and GRASS dev ML email address > 4. the email is stored in the given Trac ticket > > I'm asking this because the lack of such funtionality seems > the biggest problem with GRASS GForge trackers. Maciek, The OSGeo Trac does not currently support appending to a ticket by replying to Trac emails. If this is a normal Trac feature (I'm not sure) then I'd be interested in trying to get it working for OSGeo as it is a quite desirable feature. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | President OSGeo, http://osgeo.org From tutey at o2.pl Tue Oct 9 21:30:08 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Oct 9 21:30:18 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <470BC382.2050707@pobox.com> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> <470BBC8B.70902@o2.pl> <470BC382.2050707@pobox.com> Message-ID: <470BD6C0.5050302@o2.pl> Frank Warmerdam wrote: > Maciej Sieczka wrote: >> Does anybody know if OSGEO's Trac setup allows for replying >> to tracker by email? >> >> Would that work? : >> >> 1. a GRASS bug is reported to Trac >> 2. notification is forwarded to GRASS dev list >> 3. a developer replies via email including Trac's email >> address and GRASS dev ML email address >> 4. the email is stored in the given Trac ticket >> >> I'm asking this because the lack of such funtionality seems >> the biggest problem with GRASS GForge trackers. > The OSGeo Trac does not currently support appending to a ticket by > replying to Trac emails. If this is a normal Trac feature (I'm not sure) > then I'd be interested in trying to get it working for OSGeo as it is a > quite desirable feature. I have searched around before asking this and haven't found any clues that this is possible. Could an experienced Trac user please verify? Maciek From neteler.osgeo at gmail.com Tue Oct 9 22:47:24 2007 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Tue Oct 9 22:47:30 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <470BD6C0.5050302@o2.pl> References: <20070914114723.GD14995@bartok.itc.it> <200709282133.18544.jan-oliver.wagner@intevation.de> <12953139.post@talk.nabble.com> <200710012209.36561.jan-oliver.wagner@intevation.de> <20071002195728.31b45442.hamish_nospam@yahoo.com> <931f8ea90710020758p36880a39n522e949f69b58f87@mail.gmail.com> <470BBC8B.70902@o2.pl> <470BC382.2050707@pobox.com> <470BD6C0.5050302@o2.pl> Message-ID: <86782b610710091347u1de3ca79ma81a11ae88ec79e4@mail.gmail.com> On 10/9/07, Maciej Sieczka wrote: > Frank Warmerdam wrote: > > Maciej Sieczka wrote: > > >> Does anybody know if OSGEO's Trac setup allows for replying > >> to tracker by email? > >> > >> Would that work? : > >> > >> 1. a GRASS bug is reported to Trac > >> 2. notification is forwarded to GRASS dev list > >> 3. a developer replies via email including Trac's email > >> address and GRASS dev ML email address > >> 4. the email is stored in the given Trac ticket > >> > >> I'm asking this because the lack of such funtionality seems > >> the biggest problem with GRASS GForge trackers. > > > The OSGeo Trac does not currently support appending to a ticket by > > replying to Trac emails. If this is a normal Trac feature (I'm not sure) > > then I'd be interested in trying to get it working for OSGeo as it is a > > quite desirable feature. > > I have searched around before asking this and haven't found > any clues that this is possible. Could an experienced Trac > user please verify? I guess that a ticket in trac is a DB entry. If so, the trick is essentially to re-style an incoming email (after some sanity check for content which could also be done on the GRASS site) into a SQL statement and add this to the trac DB. Since everything is organized around the trac ticket ID, it's "just": - the extraction of the ticket ID from the email subject (throw email away if not found) - the extraction of the mail body as text - insert into the DB. It might be sufficient to pick one of the scripts from http://trac.edgewall.org/wiki/TracImport and modify appropriately to accept email instead of, say, bugzilla input. Markus From glynn at gclements.plus.com Wed Oct 10 01:40:09 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Oct 10 01:40:14 2007 Subject: [GRASS-dev] [grass-code I][507] r.in.xyz: a segfault with particular dataset In-Reply-To: <20071009151145.D58FD40377@pyrosoma.intevation.org> References: <20071009151145.D58FD40377@pyrosoma.intevation.org> Message-ID: <18188.4441.901884.93662@cerise.gclements.plus.com> grass-dev@grass.itc.it wrote: > code I item #507, was opened at 2007-10-09 17:11 > Status: Open > Priority: 3 > Submitted By: Maciej Sieczka (msieczka) > Assigned to: Hamish Bowman (hamish) > Summary: r.in.xyz: a segfault with particular dataset > Issue type: module bug > Issue status: None > GRASS version: CVS HEAD > GRASS component: raster > Operating system: Linux > Operating system version: Ubuntu Dapper 64bit > GRASS CVS checkout date, if applies (YYMMDD): 071009 > > > Initial Comment: > r.in.xyz has been segfaulting with a particular dataset. It's quite > big (23 MB bzipped) and I don't know how to provide it but let me > know if ther's a need+way to. > > Details: > > $r.in.xyz -g input=tin_nieciag.xyz output=tin_nie ciag.xyz method=min type=DCELL fs="|" x=1 y=2 z=3 percent=100 > > n=5725102.149034 s=5705608.286234 e=587119.577053 w=568715.830892 b=69.431216 t= 224.696106 > > $ g.region n=5725102.149034 s=5705608.286234 e=587 119.577053 w=568715.830892 res=1 -a If res == 1, then: cols = 587119.577053 - 568715.830892 = 18403.74616099999 = 18404 rows = 5725102.149034 - 5705608.286234 = 19493.86280000024 = 19494 At 8 bytes per cell, the total size of the map is: 18404 * 19494 * 8 = 2870140608 bytes This is larger than 2GiB, causing the arithmetic (which uses "int") to overflow. > $ gdb r.in.xyz > $ run input=tin_nieciag.xyz output=tin_nie ciag.xyz method=min type=DCELL fs="|" x=1 y=2 z=3 percent=100 > > Starting program: /usr/local/grass-6.3.cvs/bin/r.in.xyz input=tin_nieciag.xyz output=tin_nieciag.xyz method=min type=DCELL fs="|" x=1 y=2 z=3 percent=100 > Scanning data ... > 67% > Program received signal SIGSEGV, Segmentation fault. > 0x00002aaaaabf3c09 in G_is_d_null_value (dcellVal=0x2aaa2cd4e960) at null_val.c:502 > 502 if(((unsigned char *) dcellVal)[i] != > (gdb) bt > #2 0x000000000040439c in update_min (array=0x2aaaab3b4010, cols=18405, row=14767, col=4767, map_type=2, value=155.11966910999999) at support.c:74 int update_min(void *array, int cols, int row, int col, RASTER_MAP_TYPE map_type, double value) { void *ptr; DCELL old_val; ptr = array; ptr = G_incr_void_ptr(ptr, ((row*cols)+col)*G_raster_size(map_type)); if( G_is_null_value(ptr, map_type) ) There are two problems here: 1. row, col, and cols are all "int"s (typically 32-bit signed integers), so (row*cols)+col is performed at that width, which will overflow at 2GiB. 2. G_incr_void_ptr() takes the increment as an "int", which is limited to 2GiB. For this to work, we need to use a 64-bit type on 64-bit systems. We also need to use an unsigned type, as a 32-bit system can allocate memory up to 4GiB, not 2GiB (unlike off_t, size_t is unsigned). Which types are 64-bit on 64-bit Linux systems? ptrdiff_t has to be; size_t probably will be. [I was going to point out that malloc() is limited to a size_t, so the array couldn't be larger than that, but the array is allocated with calloc(), which could theoretically produce a >4GiB array with only a 32-bit size_t.] I suggest: 1. Changing G_incr_void_ptr() to use size_t. 2. Changing G_raster_size() to return size_t (that's what sizeof returns, which is the reason for size_t's existence). 3. Casting "cols" to a size_t, so that the index calculation is performed at size_t width. If size_t isn't enough to index the array (i.e. you have a 32-bit size_t on a platform which can calloc() more than 4GiB), you lose regardless. -- Glynn Clements From glynn at gclements.plus.com Wed Oct 10 01:47:53 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Oct 10 01:48:01 2007 Subject: [GRASS-dev] db.execute: ".execute" suffix missing in man page In-Reply-To: <470BB2E3.7070403@o2.pl> References: <470BB2E3.7070403@o2.pl> Message-ID: <18188.4905.381868.888521@cerise.gclements.plus.com> Maciej Sieczka wrote: > In Firefox and Lynx browsers the ".execute" part of > "db.execute" is missing above the module description. It > also not there in "man db.execute" output. G_basename > Does anybody confirm? Confirm: $ db.execute --help ... Usage: db [-i] [input=name] [driver=name] [database=name] [--verbose] [--quiet] G_parser() does: G_basename(tmp_name, "exe"); G_basename() is described thus: * \fn char * G_basename (char *filename, const char *desired_ext) * * \brief Truncates filename to the base part (before the last '.') * if it matches the extension, otherwise leaves it unchanged. But it actually only checks if the specified extension is a prefix of the actual extension rather than a complete match. Suggested fix (untested): char * G_basename(char *filename, const char *desired_ext) { /* Find the last . in the filename */ char *dot = strrchr(filename, '.'); if (dot && G_strcasecmp(dot + 1, desired_ext) == 0) *dot = '\0'; return filename; } -- Glynn Clements From grass-dev at grass.itc.it Wed Oct 10 08:37:16 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Wed Oct 10 08:37:40 2007 Subject: [GRASS-dev] [grass-code I][508] r.colors: last 100% rule is forgotten Message-ID: <20071010063716.E4E6B40380@pyrosoma.intevation.org> code I item #508, was opened at 2007-10-10 19:37 Status: Open Priority: 3 Submitted By: Hamish Bowman (hamish) Assigned to: Nobody (None) Summary: r.colors: last 100% rule is forgotten Issue type: module bug Issue status: None GRASS version: 6.2 GRASS component: raster Operating system: Linux Operating system version: debian/etch GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: as reported on the mailing list: http://article.gmane.org/gmane.comp.gis.grass.devel/22645 There seems to be a bug in r.colors in 6.2 and 6.3. e.g. for a CELL map containing values of [0-255], if the rules file looks like this: 0% 0:0:0 37.5% 255:0:0 37.5% 255:0:0 75% 255:255:0 75% 255:255:0 100% 255:255:255 the colr/ file looks like this: % 0 191.25 0:0 95.625:255:0:0 95.625:255:0:0 191.25:255:255:0 ie the last 100% rule is forgotten. Same if I give it real values: G63> r.colors gebco_bathy col=rules << EOF > 0 0:0:0 95.625 255:0:0 > 95.625 255:0:0 191.25 255:255:0 > 191.25 255:255:0 255 255:255:255 > EOF WARNING: Your color rules do not cover the whole range of data! (rules 0.000000 to 191.250000 but data 0.000000 to 255.000000) ??? the usual way to give percentage is typically 1 rule per line, which is why we haven't noticed this before: 0% 0:0:0 37.5% 255:0:0 75% 255:255:0 100% 255:255:255 ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=508&group_id=21 From hamish_nospam at yahoo.com Wed Oct 10 08:59:23 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Oct 10 08:59:55 2007 Subject: [GRASS-dev] [grass-code I][507] r.in.xyz: a segfault with particular dataset In-Reply-To: <18188.4441.901884.93662@cerise.gclements.plus.com> References: <20071009151145.D58FD40377@pyrosoma.intevation.org> <18188.4441.901884.93662@cerise.gclements.plus.com> Message-ID: <20071010195923.892e91da.hamish_nospam@yahoo.com> > > code I item #507, was opened at 2007-10-09 17:11 > > Submitted By: Maciej Sieczka (msieczka) > > Summary: r.in.xyz: a segfault with particular dataset > > Issue type: module bug .. > > Initial Comment: > > > r.in.xyz has been segfaulting with a particular dataset. It's quite > > big (23 MB bzipped) and I don't know how to provide it but let me > > know if ther's a need+way to. > > > > Details: > > > > $r.in.xyz -g input=tin_nieciag.xyz output=tin_nie ciag.xyz method=min > > type=DCELL fs="|" x=1 y=2 z=3 percent=100 > > > > n=5725102.149034 s=5705608.286234 e=587119.577053 w=568715.830892 > > b=69.431216 t= 224.696106 > > > > $ g.region n=5725102.149034 s=5705608.286234 e=587 119.577053 > > w=568715.830892 res=1 -a Glynn responded: > If res == 1, then: > > cols = 587119.577053 - 568715.830892 = 18403.74616099999 = 18404 > rows = 5725102.149034 - 5705608.286234 = 19493.86280000024 = 19494 > > At 8 bytes per cell, the total size of the map is: > > 18404 * 19494 * 8 = 2870140608 bytes > > This is larger than 2GiB, causing the arithmetic (which uses "int") to > overflow. > > > $ gdb r.in.xyz > > $ run input=tin_nieciag.xyz output=tin_nie ciag.xyz method=min > > type=DCELL fs="|" x=1 y=2 z=3 percent=100 > > > > Starting program: /usr/local/grass-6.3.cvs/bin/r.in.xyz > > input=tin_nieciag.xyz output=tin_nieciag.xyz method=min type=DCELL > > fs="|" x=1 y=2 z=3 percent=100 Scanning data ... 67% > > Program received signal SIGSEGV, Segmentation fault. > > 0x00002aaaaabf3c09 in G_is_d_null_value (dcellVal=0x2aaa2cd4e960) at > > null_val.c:502 502 if(((unsigned char *) dcellVal)[i] != > > (gdb) bt > > > #2 0x000000000040439c in update_min (array=0x2aaaab3b4010, > > #cols=18405, row=14767, col=4767, map_type=2, > > #value=155.11966910999999) at support.c:74 > > int update_min(void *array, int cols, int row, int col, RASTER_MAP_TYPE > map_type, double value) { > void *ptr; > DCELL old_val; > > ptr = array; > ptr = G_incr_void_ptr(ptr, ((row*cols)+col)*G_raster_size > (map_type)); > > if( G_is_null_value(ptr, map_type) ) > > There are two problems here: > > 1. row, col, and cols are all "int"s (typically 32-bit signed > integers), so (row*cols)+col is performed at that width, which will > overflow at 2GiB. > > 2. G_incr_void_ptr() takes the increment as an "int", which is limited > to 2GiB. > > For this to work, we need to use a 64-bit type on 64-bit systems. We > also need to use an unsigned type, as a 32-bit system can allocate > memory up to 4GiB, not 2GiB (unlike off_t, size_t is unsigned). > > Which types are 64-bit on 64-bit Linux systems? ptrdiff_t has to be; > size_t probably will be. > > [I was going to point out that malloc() is limited to a size_t, so the > array couldn't be larger than that, but the array is allocated with > calloc(), which could theoretically produce a >4GiB array with only a > 32-bit size_t.] > > I suggest: > > 1. Changing G_incr_void_ptr() to use size_t. > 2. Changing G_raster_size() to return size_t (that's what sizeof > returns, which is the reason for size_t's existence). > 3. Casting "cols" to a size_t, so that the index calculation is > performed at size_t width. > > If size_t isn't enough to index the array (i.e. you have a 32-bit > size_t on a platform which can calloc() more than 4GiB), you lose > regardless. - This is a problem with the size of the region settings, not the size of the input file. Thus the workaround is to use the percent=25 option to allocate less memory and do the import with multiple scans of the data, or readjust the resolution with 'g.region res=2 -a' or so. - If it had been a problem with the file, redirecting from stdin instead of explicitly giving the file name might have helped. (but then percent is locked at 100% :-/). Others have reported success with input files >4GB. - the program does try and test to see if there is enough memory to proceed before it does any processing. (main.c line 277) But that won't help SegFaults due to trying to write to a broken memory address. - I don't know enough about 64bit and LFS issues to fix this myself without introducing all sorts of errors so must leave it to someone else. Hamish From hamish_nospam at yahoo.com Wed Oct 10 09:11:55 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Oct 10 09:12:06 2007 Subject: [GRASS-dev] v.what.rast support for centroids, v.rast.stats speed, r.category update In-Reply-To: References: <20071010014213.a1bb9ca4.hamish_nospam@yahoo.com> Message-ID: <20071010201155.aaf17e45.hamish_nospam@yahoo.com> Michael Barton wrote: > > This brings up an issue that we might want to think about for GRASS 7. > Currently, centroids must always be created manually to transform a > closed polyline into an area. While we might want to keep this as an > option (but maybe not), I think it would be better to have some kind of > 'area-creation' utility that would transform a close polyline into an > area by automatically adding a centroid at a predefined center location > (geometric center or other measure) and adding a cat value. Then > analytical utilities like you are discussing here could be more > reliable. (v.type + v.centroids) I don't think you can convert automatically all closed boundaries as some of the closed boundaries may be islands/holes within an area, and you risk turning them into positives. Hamish From tutey at o2.pl Wed Oct 10 09:54:23 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Oct 10 09:54:31 2007 Subject: [GRASS-dev] [grass-code I][507] r.in.xyz: a segfault with particular dataset In-Reply-To: <20071010195923.892e91da.hamish_nospam@yahoo.com> References: <20071009151145.D58FD40377@pyrosoma.intevation.org> <18188.4441.901884.93662@cerise.gclements.plus.com> <20071010195923.892e91da.hamish_nospam@yahoo.com> Message-ID: <470C852F.7090003@o2.pl> Hamish, Glynn, Thanks for explaining this. Maciek From hamish_nospam at yahoo.com Wed Oct 10 10:23:04 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Oct 10 10:23:18 2007 Subject: [GRASS-dev] r.cats -> r.category + enhancements Message-ID: <20071010212304.fa38568c.hamish_nospam@yahoo.com> r.cats updates committed to cvs. test away. I am not sure that all which is mentioned in the lib/gis/cats.c comments really work. (copied into description.html) I know these don't work: - category ranges; cat1:cat2:Label appears as just cat2:Label in d.legend - val1:val2:Labels for FP maps don't appear in d.legend(?) - ps.map doesn't respect dynamic label names (see RT bug report) - etc. There are probably more bugs about but I wanted to get it checked in for others to help test. The library code is somewhat "dusty". Reading from stdin is brand new & totally untested. r.cats is preserved as a symlink. Anyone have ideas for module keywords? "support"? enjoy, Hamish ------------------ G63> r.category --help Description: Manages category values and labels associated with user-specified raster map layers. Keywords: raster Usage: r.category map=name [cats=range[,range,...]] [vals=value[,value,...]] [fs=character|space|tab] [raster=name] [rules=name] [format=string] [coefficients=mult1,offset1,mult2,offset2] [--verbose] [--quiet] Flags: --v Verbose module output --q Quiet module output Parameters: map Name of input raster map cats Category values Example: 1,3,7-9,13 vals Comma separated value list Example: 1.4,3.8,13 fs Output field separator default: tab raster Raster map from which to copy category table rules File containing category label rules (or "-" to read from stdin) format Default label or format string for dynamic labeling Used when no explicit label exists for the category coefficients Dynamic label coefficients Two pairs of category multiplier and offsets, for $1 and $2 From hamish_nospam at yahoo.com Wed Oct 10 10:26:11 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Oct 10 10:26:24 2007 Subject: [GRASS-dev] r.cats -> r.category + enhancements In-Reply-To: <200710081043.01358.dylan.beaudette@gmail.com> References: <923178.14954.qm@web52709.mail.re2.yahoo.com> <200710081043.01358.dylan.beaudette@gmail.com> Message-ID: <20071010212611.5cf41705.hamish_nospam@yahoo.com> Dylan Beaudette wrote: > > This sounds like a great addition. Assigning labels to FP ranges, or > even a simple approach to assigning labels to integer maps would be > useful. note the functionality has been there for years and years and used by various raster modules, just no easy way to access it for self-created maps so it is not widely known. Hamish From wolf+grass at bergenheim.net Wed Oct 10 10:35:08 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Wed Oct 10 10:35:44 2007 Subject: [GRASS-dev] v.what.rast support for centroids, v.rast.stats speed, r.category update In-Reply-To: <20071010201155.aaf17e45.hamish_nospam@yahoo.com> References: <20071010014213.a1bb9ca4.hamish_nospam@yahoo.com> <20071010201155.aaf17e45.hamish_nospam@yahoo.com> Message-ID: <470C8EBC.7020307@bergenheim.net> On 10.10.2007 10:11, Hamish wrote: > Michael Barton wrote: >> This brings up an issue that we might want to think about for GRASS 7. >> Currently, centroids must always be created manually to transform a >> closed polyline into an area. While we might want to keep this as an >> option (but maybe not), I think it would be better to have some kind of >> 'area-creation' utility that would transform a close polyline into an >> area by automatically adding a centroid at a predefined center location >> (geometric center or other measure) and adding a cat value. Then >> analytical utilities like you are discussing here could be more >> reliable. > > (v.type + v.centroids) > > I don't think you can convert automatically all closed boundaries as > some of the closed boundaries may be islands/holes within an area, and > you risk turning them into positives. > I agree with Hamish, however, I think it might be worth considering that we could have 2 new area creation buttons: "create area" and "create island/hole" That could make it easier for the new user to start with digitizing in GRASS. An advanced user would maybe choose to use the "draw boundary" and "draw centroid" buttons, which would sit there next to the new area drawing buttons. The purpose of the GUI is after all to make it easier/friendlier to operate GRASS. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From glynn at gclements.plus.com Wed Oct 10 12:18:09 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Oct 10 12:18:12 2007 Subject: [GRASS-dev] [grass-code I][508] r.colors: last 100% rule is forgotten In-Reply-To: <20071010063716.E4E6B40380@pyrosoma.intevation.org> References: <20071010063716.E4E6B40380@pyrosoma.intevation.org> Message-ID: <18188.42721.730049.602313@cerise.gclements.plus.com> grass-dev@grass.itc.it wrote: > code I item #508, was opened at 2007-10-10 19:37 > Status: Open > Priority: 3 > Submitted By: Hamish Bowman (hamish) > Assigned to: Nobody (None) > Summary: r.colors: last 100% rule is forgotten > Issue type: module bug > Issue status: None > GRASS version: 6.2 > GRASS component: raster > Operating system: Linux > Operating system version: debian/etch > GRASS CVS checkout date, if applies (YYMMDD): > > > Initial Comment: > as reported on the mailing list: > http://article.gmane.org/gmane.comp.gis.grass.devel/22645 > > There seems to be a bug in r.colors in 6.2 and 6.3. > > e.g. for a CELL map containing values of [0-255], if the rules file looks > like this: > > 0% 0:0:0 37.5% 255:0:0 > 37.5% 255:0:0 75% 255:255:0 > 75% 255:255:0 100% 255:255:255 Why do you think that format should be accepted? AFAICT, nothing in the r.colors documentation indicates that it should be, nor, AFAICT, has it ever been this way. FWIW, everything after the colour is discarded, so the above is treated exactly the same as: 0% 0:0:0 37.5% 255:0:0 75% 255:255:0 > the usual way to give percentage is typically 1 rule per line, No, the *correct* way to give rules (percentage or absolute) to r.colors is 1 rule per line. It's not a matter of what's "typical" or "usual". I daresay that I can tweak G_parse_color_rule() to return an error if a line has trailing garbage, rather than simply discarding it. -- Glynn Clements From michael.barton at asu.edu Wed Oct 10 16:17:13 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Oct 10 16:18:11 2007 Subject: [GRASS-dev] v.what.rast support for centroids, v.rast.stats speed, r.category update In-Reply-To: <20071010201155.aaf17e45.hamish_nospam@yahoo.com> Message-ID: I was thinking more along the lines of something where you specified a set of vector features (cat=... or where=...), clicked run and after a check to make sure they are closed polylines it would add a central centroid and make them areas. Michael On 10/10/07 12:11 AM, "Hamish" wrote: > Michael Barton wrote: >> >> This brings up an issue that we might want to think about for GRASS 7. >> Currently, centroids must always be created manually to transform a >> closed polyline into an area. While we might want to keep this as an >> option (but maybe not), I think it would be better to have some kind of >> 'area-creation' utility that would transform a close polyline into an >> area by automatically adding a centroid at a predefined center location >> (geometric center or other measure) and adding a cat value. Then >> analytical utilities like you are discussing here could be more >> reliable. > > (v.type + v.centroids) > > I don't think you can convert automatically all closed boundaries as > some of the closed boundaries may be islands/holes within an area, and > you risk turning them into positives. > > > Hamish __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From epatton at nrcan.gc.ca Wed Oct 10 19:11:02 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Wed Oct 10 19:11:08 2007 Subject: [GRASS-dev] Pipeline efficiency in bash shell scripts Message-ID: I'll keep this short and provide more details if people need it. In a for loop within bash scripts, where several commands are performing text manipulation, is it more efficient to pipe the commands together in one long pipeline (case 1), or instead dump the output from one program into a text file and use a redirection to input the results into a second command (case 2)? Case 1 ====== for FILES in *.extension ; do mbnavlist -Iinputfile -OJXY -N0 | awk '{lots of awk text manipulation goes here}' | v.in.ascii done Case 2 ====== for FILES in *.extension ; do mbnavlist -Iinputfile -OJXY -N0 > TMP.txt awk '{slicing and dicing commands go here}' < TMP.txt > v.in.ascii OR awk '{slicing and dicing commands go here}' < TMP.txt > TMP2.txt follwed by v.in.ascii < TMP2.txt In both cases, the for loop is calling the mbnavlist program (from free and open source bathymetry processing software MBTools) and awk together thousands or times. I wasn't sure if there are any general benefits to piping vs. writing out to a file, then redirecting input. Any suggestions? ~ Eric. From glynn at gclements.plus.com Wed Oct 10 20:26:32 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Oct 10 20:26:36 2007 Subject: [GRASS-dev] Pipeline efficiency in bash shell scripts In-Reply-To: References: Message-ID: <18189.6488.943211.860081@cerise.gclements.plus.com> Patton, Eric wrote: > I'll keep this short and provide more details if people need it. In a > for loop within bash scripts, where several commands are performing > text manipulation, is it more efficient to pipe the commands together > in one long pipeline (case 1), or instead dump the output from one > program into a text file and use a redirection to input the results > into a second command (case 2)? > > Case 1 > ====== > > for FILES in *.extension ; do > mbnavlist -Iinputfile -OJXY -N0 | awk '{lots of awk text manipulation goes here}' | v.in.ascii > > done > > > Case 2 > ====== > > for FILES in *.extension ; do > > mbnavlist -Iinputfile -OJXY -N0 > TMP.txt > awk '{slicing and dicing commands go here}' < TMP.txt > v.in.ascii > OR > awk '{slicing and dicing commands go here}' < TMP.txt > TMP2.txt > follwed by > v.in.ascii < TMP2.txt > > In both cases, the for loop is calling the mbnavlist program (from > free and open source bathymetry processing software MBTools) and awk > together thousands or times. I wasn't sure if there are any general > benefits to piping vs. writing out to a file, then redirecting input. > > Any suggestions? Any difference is likely to be so small that there's no reason to prefer one to the other based upon efficiency concerns. Exactly which will be more efficient depends upon more factors than can reasonably be discussed here. -- Glynn Clements From neteler at itc.it Wed Oct 10 21:35:33 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Oct 10 21:35:35 2007 Subject: [GRASS-dev] r.cats -> r.category + enhancements In-Reply-To: <923178.14954.qm@web52709.mail.re2.yahoo.com> References: <0AAE9F9B-A9A5-4C04-9D0C-CB9CB5651B73@kyngchaos.com> <18178.1570.808559.665340@cerise.gclements.plus.com> <407D8E33-ECB5-4E84-8D61-C0A4246F74ED@kyngchaos.com> <18178.32819.389941.767440@cerise.gclements.plus.com> <18178.44820.362012.427184@cerise.gclements.plus.com> <18179.23691.715738.76415@cerise.gclements.plus.com> <3C2F03CF-6EDC-4EF1-B074-35B217127D10@kyngchaos.com> <18179.56105.931632.839661@cerise.gclements.plus.com> <93BB1547-A2A6-4C7A-A5D0-29DE1509AB15@kyngchaos.com> <18180.54358.477131.681551@cerise.gclements.plus.com> <4CF13205-3E3A-4BA3-BA27-5CDC05E1046A@kyngchaos.com> <98F2157D-DFB3-447A-888E-1A5DE4CA3966@mac.com> <923178.14954.qm@web52709.mail.re2.yahoo.com> Message-ID: <13142960.post@talk.nabble.com> HamishB wrote: > > Hi, > > if there are no objections I will rename r.cats to be r.category (to match > v.category), leaving a r.cats symlink for backwards compatibility for the > duration of GRASS 6.x. > > In addition I mean to move/copy the copy cats from raster= option from > r.support to r.category and add a rules= option to import category labels > from > a file. > (r.support raster= is not in 6.2.x so no crime to move it, although if > someone > cares we can copy it with a note that it will be removed for GRASS 7; or > maybe > r.suppport is a better place for these things, not r.cats? but r.support > is > already crowded) > Please don't move but copy it since (almost) published new documentation such as the new GRASS book make use of r.support for this. For GRASS 7, it can then be really removed. thanks Markus -- View this message in context: http://www.nabble.com/another-make-problem-%28OSX%2C-but-could-be-a-general-problem%29-tf4551133.html#a13142960 Sent from the Grass - Dev mailing list archive at Nabble.com. From hamish_nospam at yahoo.com Thu Oct 11 00:49:41 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Oct 11 00:49:51 2007 Subject: [GRASS-dev] [grass-code I][508] r.colors: last 100% rule is forgotten In-Reply-To: <18188.42721.730049.602313@cerise.gclements.plus.com> References: <20071010063716.E4E6B40380@pyrosoma.intevation.org> <18188.42721.730049.602313@cerise.gclements.plus.com> Message-ID: <20071011114941.bdcca126.hamish_nospam@yahoo.com> Glynn Clements wrote: > > code I item #508, was opened at 2007-10-10 19:37 > > Summary: r.colors: last 100% rule is forgotten .. > > Initial Comment: > > as reported on the mailing list: > > http://article.gmane.org/gmane.comp.gis.grass.devel/22645 > > > > There seems to be a bug in r.colors in 6.2 and 6.3. > > > > e.g. for a CELL map containing values of [0-255], if the rules file > > looks like this: > > > > 0% 0:0:0 37.5% 255:0:0 > > 37.5% 255:0:0 75% 255:255:0 > > 75% 255:255:0 100% 255:255:255 > > Why do you think that format should be accepted? AFAICT, nothing in > the r.colors documentation indicates that it should be, nor, AFAICT, > has it ever been this way. > > FWIW, everything after the colour is discarded, so the above is > treated exactly the same as: > > 0% 0:0:0 > 37.5% 255:0:0 > 75% 255:255:0 oops I was mixing up the final colr/ file format with the rules= input format. My GMT color rules importing r.cpt2grass script is now updated and working fine. thanks, Hamish From rez at touchofmadness.com Thu Oct 11 06:36:35 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Oct 11 06:36:39 2007 Subject: [GRASS-dev] [grass-code I][507] r.in.xyz: a segfault with particular dataset In-Reply-To: <18188.4441.901884.93662@cerise.gclements.plus.com> References: <20071009151145.D58FD40377@pyrosoma.intevation.org> <18188.4441.901884.93662@cerise.gclements.plus.com> Message-ID: <1192077395.17343.173.camel@dev64.localdomain> On Wed, 2007-10-10 at 00:40 +0100, Glynn Clements wrote: > grass-dev@grass.itc.it wrote: > > > code I item #507, was opened at 2007-10-09 17:11 > > Status: Open > > Priority: 3 > > Submitted By: Maciej Sieczka (msieczka) > > Assigned to: Hamish Bowman (hamish) > > Summary: r.in.xyz: a segfault with particular dataset > > Issue type: module bug > > Issue status: None > > GRASS version: CVS HEAD > > GRASS component: raster > > Operating system: Linux > > Operating system version: Ubuntu Dapper 64bit > > GRASS CVS checkout date, if applies (YYMMDD): 071009 > > > > > > Initial Comment: > > > r.in.xyz has been segfaulting with a particular dataset. It's quite > > big (23 MB bzipped) and I don't know how to provide it but let me > > know if ther's a need+way to. > > [snip] > I suggest: > > 1. Changing G_incr_void_ptr() to use size_t. > 2. Changing G_raster_size() to return size_t (that's what sizeof Committed to CVS. > returns, which is the reason for size_t's existence). > 3. Casting "cols" to a size_t, so that the index calculation is > performed at size_t width. > > If size_t isn't enough to index the array (i.e. you have a 32-bit > size_t on a platform which can calloc() more than 4GiB), you lose > regardless. -- 73, de Brad KB8UYR/6 From michael.barton at asu.edu Thu Oct 11 09:33:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Oct 11 09:33:56 2007 Subject: [GRASS-dev] bug in v.surf.bspline? Message-ID: I'm not sure if this is a bug or if I just don't know how to use v.surf.bspline. If I make a 3D vector point map, v.surf.bspline will interpolate using the z-coordinate fine. However, if I try to specify a vector column as the basis for interpolation, it will go through fine, but the result is a flat map. That is, it seems not to correctly recognize a column specified for interpolation. I set layer=1, but don't see what else I should do. Any suggestions? Michael __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071011/47dc0d60/attachment.html From grass-dev at grass.itc.it Thu Oct 11 10:29:36 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Thu Oct 11 10:29:39 2007 Subject: [GRASS-dev] [grass-code I][509] v.mkgrid: segfault when "grid" parameters missing Message-ID: <20071011082936.C361040324@pyrosoma.intevation.org> code I item #509, was opened at 2007-10-11 10:29 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: v.mkgrid: segfault when "grid" parameters missing Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: Linux Operating system version: Ubuntu Dapper 64bit GRASS CVS checkout date, if applies (YYMMDD): 071011 Initial Comment: If the user fails to provide "grid" parameters, it segfaults. Applies to bot 6.2 CVS and 6.3 CVS. Example: $ v.mkgrid map=debug_grid position=region grid= Segmentation fault (core dumped) backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912562415552 (LWP 26775)] 0x00002aaaabe92cf1 in __strtoull_internal () from /lib/libc.so.6 (gdb) bt #0 0x00002aaaabe92cf1 in __strtoull_internal () from /lib/libc.so.6 #1 0x00002aaaaba65022 in atoi () from /usr/local/lib/libgdal.so.1 #2 0x0000000000401a25 in main (argc=4, argv=0x7fffff972dd8) at main.c:142 ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=509&group_id=21 From roberto at geomatica.como.polimi.it Thu Oct 11 10:56:19 2007 From: roberto at geomatica.como.polimi.it (Roberto Antolin) Date: Thu Oct 11 10:56:38 2007 Subject: [GRASS-dev] bug in v.surf.bspline? In-Reply-To: References: Message-ID: <470DE533.5070001@geomatica.como.polimi.it> Hi Michael and all, Michael Barton escribi?: > However, if I try to specify a vector column as the basis for interpolation, > it will go through fine, but the result is a flat map. That is, it seems not > to correctly recognize a column specified for interpolation. I set layer=1, > but don't see what else I should do. Any suggestions? Is it completely flat? I mean, did you try to take a look to the raster values? Time ago, border errors (due to the interpolation) made visualization a bit odd because, in borders, v.surf.bspline try to interpolate to zero. So depending on the values you want to interpolate it will seem that the whole raster has the same value but really it hasn't. I thought this error was fixed already, though. Which version are you using? I don't know whether is this or not, so let me know and I'll proceed with the bugfixing -in case there exits any bug ;)-. In the meanwhile I'll try to find the dataset I used in my tests and I'll check too. Regards, Roberto. -- Roberto Antol?n S?nchez Politecnico di Milano - Polo Regionale di Como (Laboratorio di Geomatica V2.8) Via Valleggio, 11 - 22100 Como, Italy tel: +39 031 332 7533 || fax: +39 031 332 7519 roberto@geomatica.como.polimi.it From hamish_nospam at yahoo.com Thu Oct 11 12:53:05 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Oct 11 12:53:08 2007 Subject: [GRASS-dev] [grass-code I][509] v.mkgrid: segfault when "grid" parameters missing In-Reply-To: <20071011082936.C361040324@pyrosoma.intevation.org> Message-ID: <419328.31553.qm@web52706.mail.re2.yahoo.com> > code I item #509, was opened at 2007-10-11 10:29 > Summary: v.mkgrid: segfault when "grid" parameters missing .. > If the user fails to provide "grid" parameters, it segfaults. Applies to bot > 6.2 CVS and 6.3 CVS. Example: > > $ v.mkgrid map=debug_grid position=region grid= > Segmentation fault (core dumped) > > backtrace: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 46912562415552 (LWP 26775)] > 0x00002aaaabe92cf1 in __strtoull_internal () from /lib/libc.so.6 > (gdb) bt > #0 0x00002aaaabe92cf1 in __strtoull_internal () from /lib/libc.so.6 > #1 0x00002aaaaba65022 in atoi () from /usr/local/lib/libgdal.so.1 > #2 0x0000000000401a25 in main (argc=4, argv=0x7fffff972dd8) at main.c:142 It is in the main.c atoi("") [line 137], but I'm not sure why it thinks that's found in libgdal. the root of the problem is that even though the option is declared TYPE_INTEGER, that is never checked. v.mkgrid/main.c has grid = G_define_option (); grid->key = "grid"; grid->key_desc = "rows,columns"; grid->type = TYPE_INTEGER; grid->required = YES; grid->multiple = NO; grid->description = _("Number of rows and columns in grid"); in lib/gis/parser.c ~ line 2136 the check_opts() fn skips sending it to check_an_opt() as (opt->options && opt->answer) are (null) and "" respectively. [ie not allocated, and allocated but set to "\0" (?)] it would be easy to add to v.mkgrid a test for the answer being empty and throw it to {G_usage(); exit(EXIT_FAILURE);}, but that doesn't solve the general problem- the parser should check for an integer answer. (same for TYPE_DOUBLE, ...) Note in this case the checker has to check key_desc to know to expect two int answers. G_parser() does catch the "grid=1," error with a please supply two values message. so maybe the problem is in check_multiple_opts()? Interesting, I hadn't noticed the parser's custom opt->checker option-option before. Hamish ____________________________________________________________________________________ Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html From landa.martin at gmail.com Thu Oct 11 13:06:26 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Oct 11 13:06:29 2007 Subject: [GRASS-dev] [grass-code I][509] v.mkgrid: segfault when "grid" parameters missing In-Reply-To: <419328.31553.qm@web52706.mail.re2.yahoo.com> References: <20071011082936.C361040324@pyrosoma.intevation.org> <419328.31553.qm@web52706.mail.re2.yahoo.com> Message-ID: Hi Hamish, see my comments on GForge [1]. I see problem in check_multiple_opts() fn... The attached patch is too simple, should be fixed in more robust way... Martin [1] http://wald.intevation.org/tracker/?func=detail&atid=204&aid=509&group_id=21 2007/10/11, Hamish : > > code I item #509, was opened at 2007-10-11 10:29 > > Summary: v.mkgrid: segfault when "grid" parameters missing > .. > > If the user fails to provide "grid" parameters, it segfaults. Applies to bot > > 6.2 CVS and 6.3 CVS. Example: > > > > $ v.mkgrid map=debug_grid position=region grid= > > Segmentation fault (core dumped) > > > > backtrace: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 46912562415552 (LWP 26775)] > > 0x00002aaaabe92cf1 in __strtoull_internal () from /lib/libc.so.6 > > (gdb) bt > > #0 0x00002aaaabe92cf1 in __strtoull_internal () from /lib/libc.so.6 > > #1 0x00002aaaaba65022 in atoi () from /usr/local/lib/libgdal.so.1 > > #2 0x0000000000401a25 in main (argc=4, argv=0x7fffff972dd8) at main.c:142 > > It is in the main.c atoi("") [line 137], but I'm not sure why it thinks that's > found in libgdal. > > the root of the problem is that even though the option is declared > TYPE_INTEGER, that is never checked. > v.mkgrid/main.c has > grid = G_define_option (); > grid->key = "grid"; > grid->key_desc = "rows,columns"; > grid->type = TYPE_INTEGER; > grid->required = YES; > grid->multiple = NO; > grid->description = _("Number of rows and columns in grid"); > > > in lib/gis/parser.c ~ line 2136 the check_opts() fn skips sending it to > check_an_opt() as (opt->options && opt->answer) are (null) and "" respectively. > [ie not allocated, and allocated but set to "\0" (?)] > > it would be easy to add to v.mkgrid a test for the answer being empty and throw > it to {G_usage(); exit(EXIT_FAILURE);}, but that doesn't solve the general > problem- the parser should check for an integer answer. (same for TYPE_DOUBLE, > ...) Note in this case the checker has to check key_desc to know to expect two > int answers. > > G_parser() does catch the "grid=1," error with a please supply two values > message. so maybe the problem is in check_multiple_opts()? > > > > Interesting, I hadn't noticed the parser's custom opt->checker option-option > before. > > > Hamish > > > > ____________________________________________________________________________________ > Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. > http://autos.yahoo.com/index.html > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From francesco.pirotti at unipd.it Thu Oct 11 13:25:34 2007 From: francesco.pirotti at unipd.it (francesco) Date: Thu Oct 11 13:25:35 2007 Subject: [GRASS-dev] new agg library Message-ID: <20071011112531.55F5E40002@kletz.unipd.it> Hello, Does anyone know how to obtain the agg.lib needed by the new mapserver5.0 for compiling? I downloaded the AGG library but the MINGW compiles libagg.a file and not agg.lib. I am not a superexpert on libraries and programming, so I am in trouble as I cannot compile AGG support in the new mapserver5.0. Another question is: with the new maxnumlayers and maxnumclasses in the mapserver.h the number of layers classes and styles can grow without limit right? there is no limit to numero of classes and styles? Cheers, and thank you for your time. Francesco Pirotti CIRGEO - Interdepartmental Research Center on Cartography, Photogrammetry, Remote Sensing and GIS Viale dell'Universit? 16 35020 Legnaro (PD) ITALY Ph. 049-8272710/2688 fax 049-8272686 www http://www.cirgeo.unipd.it From epatton at nrcan.gc.ca Thu Oct 11 14:41:24 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Oct 11 14:43:13 2007 Subject: [GRASS-dev] Pipeline efficiency in bash shell scripts References: <18189.6488.943211.860081@cerise.gclements.plus.com> Message-ID: >> In both cases, the for loop is calling the mbnavlist program (from >> free and open source bathymetry processing software MBTools) and awk >> together thousands or times. I wasn't sure if there are any general >> benefits to piping vs. writing out to a file, then redirecting input. >> >> Any suggestions? >Any difference is likely to be so small that there's no reason to >prefer one to the other based upon efficiency concerns. >Exactly which will be more efficient depends upon more factors than >can reasonably be discussed here. >-- >Glynn Clements Thanks for the feedback. I didn't really suspect a difference, but good to know. ~ Eric. From michael.barton at asu.edu Thu Oct 11 17:45:27 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Oct 11 17:46:13 2007 Subject: [GRASS-dev] bug in v.surf.bspline? In-Reply-To: <470DE533.5070001@geomatica.como.polimi.it> Message-ID: It's completely flat. I just did another test. If I use a vector attribute column in layer 1, the entire interpolated map has a value of 0 for all cells. If I create a 3D vector with the same data and set layer=0 so that it uses z values, it works fine. So I guess it sounds like a bug. Michael On 10/11/07 1:56 AM, "Roberto Antolin" wrote: > Hi Michael and all, > > Michael Barton escribi?: >> However, if I try to specify a vector column as the basis for interpolation, >> it will go through fine, but the result is a flat map. That is, it seems not >> to correctly recognize a column specified for interpolation. I set layer=1, >> but don't see what else I should do. Any suggestions? > > Is it completely flat? I mean, did you try to take a look to the raster > values? Time ago, border errors (due to the interpolation) made > visualization a bit odd because, in borders, v.surf.bspline try to > interpolate to zero. So depending on the values you want to interpolate > it will seem that the whole raster has the same value but really it > hasn't. I thought this error was fixed already, though. Which version > are you using? > > I don't know whether is this or not, so let me know and I'll proceed > with the bugfixing -in case there exits any bug ;)-. In the meanwhile > I'll try to find the dataset I used in my tests and I'll check too. > > Regards, > Roberto. __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Thu Oct 11 19:26:09 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Oct 11 19:26:18 2007 Subject: [GRASS-dev] Re: [GRASS-user] create a xy location with g.proj In-Reply-To: <20071010190942.02436b14.hamish_nospam@yahoo.com> References: <20071009141829.109780@gmx.net> <20071010190942.02436b14.hamish_nospam@yahoo.com> Message-ID: <470E5CB1.4070906@o2.pl> Hamish wrote: >> Peter L?we wrote: >>> does anybody have an example how to create a xy-location using g.proj >>> -c ? >>> >>> Calling up g.proj from within a xy-location using the -j/-w flags (to >>> create output in wkt/proj format) results in the info "xy location >>> (unprojected)". This doesn't really help. > > Michael Barton wrote: >> AFAIK, you cannot create an xy location using g.proj. g.proj is for >> creating projected locations. xy is not projected. When I wanted to >> create an xy location for the new wxPython location wizard, I had to >> code it myself. That said, it's not hard to create the WIND, etc files >> for an xy location. > If this doesn't exist, then we should look at adding the functionality. > > for example: > g.proj -c location="newloc" wkt=none > or > g.proj -c location="newloc" wkt=XY > or > g.proj -c location="newloc" wkt=unprojected It's a good idea IMO. But I'd suggest not to mix WKT with this - WKT has it's strict meaning (there's no WKT representation for GRASS XY location settings AFAIK; is there?). Moreover, wkt= parameter is supposed to be a file. How about this: if -c is used and no wkt, georef or proj4 parameters are given, assume XY? BTW, I noticed a following sentence in g.proj manual regarding georef option: "If the file is not georeferenced or cannot be read, XY (unprojected) will be used". But it does not work: (file xy does not exist): $ g.proj -c georef=xy Trying to open with OGR... Trying to open with GDAL... ERROR 4: `xy' does not exist in the file system, and is not recognised as a supported dataset name. ERROR: Could not read georeferenced file xy using either OGR nor GDAL (file xy is empty): $ touch xy $ g.proj -c georef=xy Trying to open with OGR... Trying to open with GDAL... ERROR 4: `xy' not recognised as a supported file format. ERROR: Could not read georeferenced file xy using either OGR nor GDAL Maciek From twiens at interbaun.com Thu Oct 11 23:19:02 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Thu Oct 11 23:18:07 2007 Subject: [GRASS-dev] gis.m symbol error in cvs Message-ID: <20071011151902.49f080a8.twiens@interbaun.com> On two systems I've tried, choosing point symbols results in a format of box@basic instead of basic / box As a result, the display of points fails T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From maris.gis at gmail.com Fri Oct 12 08:25:13 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Fri Oct 12 08:25:20 2007 Subject: [GRASS-dev] gis.m symbol error in cvs In-Reply-To: <20071011151902.49f080a8.twiens@interbaun.com> References: <20071011151902.49f080a8.twiens@interbaun.com> Message-ID: <2b3d8c1c0710112325m27b9c2a6r653e67eda244514@mail.gmail.com> Hi, You are right. It's broken. Guilty lines - 199/227 at http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gtcltk/select.tcl.diff?r1=1.18&r2=1.19 Seems, that we need to go back to old, (ugly) code, if nobody comes up with better solution. See attached patch. Somebody test && commit. Maris. 2007/10/12, Trevor Wiens : > On two systems I've tried, choosing point symbols results in a format of > > box@basic > > instead of > > basic / box > > As a result, the display of points fails > > T > -- > Trevor Wiens > twiens@interbaun.com > > The significant problems that we face cannot be solved at the same > level of thinking we were at when we created them. > (Albert Einstein) > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: select_symbol.patch Type: text/x-diff Size: 920 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071012/8b8fc8d6/select_symbol.bin From grass-dev at grass.itc.it Fri Oct 12 15:40:38 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Fri Oct 12 15:40:46 2007 Subject: [GRASS-dev] [grass-code R][510] v.to.db option=length: please report line's 3d length Message-ID: <20071012134038.E67B240390@pyrosoma.intevation.org> code R item #510, was opened at 2007-10-12 15:40 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: v.to.db option=length: please report line's 3d length Issue status: None GRASS component: vector Operating system: all Operating system version: Initial Comment: Currently v.to.db always assumes input vector is flat. Condider two vector lines: $ v.out.ascii line_3d form=standard L 2 571600 5722275.5 1 571610 5722275.5 4 $ v.out.ascii line_flat form=standard L 2 571600 5722275.5 571610 5722275.5 Although line_3d's length is 10.440307 and line_flat's is 10, v.to.db will report 10 for both: $ v.to.db -p opt=length map=line_3d col=dummy cat|length -1|10 v.to.db's options coor, start, end already support Z attribute. Please implement it for length too. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=188&aid=510&group_id=21 From landa.martin at gmail.com Fri Oct 12 16:47:04 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Oct 12 16:47:08 2007 Subject: [GRASS-dev] [grass-code R][510] v.to.db option=length: please report line's 3d length In-Reply-To: <20071012134038.E67B240390@pyrosoma.intevation.org> References: <20071012134038.E67B240390@pyrosoma.intevation.org> Message-ID: Hi, should be fixed in CVS. Martin 2007/10/12, grass-dev@grass.itc.it : > code R item #510, was opened at 2007-10-12 15:40 > Status: Open > Priority: 3 > Submitted By: Maciej Sieczka (msieczka) > Assigned to: Nobody (None) > Summary: v.to.db option=length: please report line's 3d length > Issue status: None > GRASS component: vector > Operating system: all > Operating system version: > > > Initial Comment: > Currently v.to.db always assumes input vector is flat. Condider two vector lines: > > $ v.out.ascii line_3d form=standard > L 2 > 571600 5722275.5 1 > 571610 5722275.5 4 > > $ v.out.ascii line_flat form=standard > L 2 > 571600 5722275.5 > 571610 5722275.5 > > > Although line_3d's length is 10.440307 and line_flat's is 10, v.to.db will report 10 for both: > > $ v.to.db -p opt=length map=line_3d col=dummy > cat|length > -1|10 > > v.to.db's options coor, start, end already support Z attribute. Please implement it for length too. > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=188&aid=510&group_id=21 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From grass-dev at grass.itc.it Fri Oct 12 17:04:41 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Fri Oct 12 17:04:45 2007 Subject: [GRASS-dev] [grass-code I][511] v.segment: fails to process segment if it's located exactly at the end of the input line Message-ID: <20071012150441.5AA3B40396@pyrosoma.intevation.org> code I item #511, was opened at 2007-10-12 17:04 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: v.segment: fails to process segment if it's located exactly at the end of the input line Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 071012 Initial Comment: The input offsets for v.segment are as following: $ cat offsets P 1 1 0 P 5 1 4.6981381500000001 P 10 1 10.440307 v.segment refuses to process the last offset, saying it's not on the input line, while it falls exactly at the of the line: $ cat offsets | v.segment llayer=1 input=line_cat output=line_cellcnt WARNING: Cannot get point on line: cat = 1 offset = 10.440307 (line length = 10.440307) P 10 1 10.440307 Building topology ... 2 primitives registered Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 2 Number of primitives: 2 Number of points : 2 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 3 points read from input 2 points written to output map (1 lost) 0 lines read from input 0 lines written to output map (0 lost) ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=511&group_id=21 From paul-grass at stjohnspoint.co.uk Fri Oct 12 17:20:46 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Oct 12 17:20:52 2007 Subject: [GRASS-dev] Re: [GRASS-user] create a xy location with g.proj In-Reply-To: <470E5CB1.4070906@o2.pl> References: <20071009141829.109780@gmx.net> <20071010190942.02436b14.hamish_nospam@yahoo.com> <470E5CB1.4070906@o2.pl> Message-ID: On Thu, 11 Oct 2007, Maciej Sieczka wrote: > Hamish wrote: >>> Peter L?we wrote: >>>> does anybody have an example how to create a xy-location using g.proj >>>> -c ? >>>> >>>> Calling up g.proj from within a xy-location using the -j/-w flags (to >>>> create output in wkt/proj format) results in the info "xy location >>>> (unprojected)". This doesn't really help. >> >> Michael Barton wrote: >>> AFAIK, you cannot create an xy location using g.proj. g.proj is for >>> creating projected locations. xy is not projected. When I wanted to >>> create an xy location for the new wxPython location wizard, I had to >>> code it myself. That said, it's not hard to create the WIND, etc files >>> for an xy location. > >> If this doesn't exist, then we should look at adding the functionality. >> >> for example: >> g.proj -c location="newloc" wkt=none >> or >> g.proj -c location="newloc" wkt=XY >> or >> g.proj -c location="newloc" wkt=unprojected > > It's a good idea IMO. But I'd suggest not to mix WKT with > this - WKT has it's strict meaning (there's no WKT > representation for GRASS XY location settings AFAIK; is > there?). Moreover, wkt= parameter is supposed to be a file. > How about this: if -c is used and no wkt, georef or proj4 > parameters are given, assume XY? > > BTW, I noticed a following sentence in g.proj manual > regarding georef option: "If the file is not georeferenced > or cannot be read, XY (unprojected) will be used". But it > does not work: That's true. It's a documentation bug. If you export a Shapefile and then delete the .prj file that was created, then try to use that Shapefile as the georeferenced source, you should be able to create an XY location. g.setproj can also do that though (not sure if anybody else mentioned that). Paul From mlennert at club.worldonline.be Fri Oct 12 19:16:39 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Oct 12 19:19:46 2007 Subject: [GRASS-dev] GRASS 6.2.2: gis.m crashes when there are more than one map with same name in path Message-ID: <470FABF7.2080503@club.worldonline.be> Hello, I don't know if this is a problem with just my installation (compiled Debian 6.2.2 package with source code from Debian site) but it seems that that an important bug which (AFAIK) is fixed in 6.3, is still present in 6.2.2: In spearfish: 1) g.copy vect=fields@PERMANENT,fields 2) Select 'fields' as vector file to display and in Map Display "Zoom to selected map". => gis.m crashes and in terminal you see: WARNING: 'vector/fields' was found in more mapsets (also found in user1). If another bugfix release of 6.2 is foreseen can this be backported ? Moritz From dylan.beaudette at gmail.com Sat Oct 13 00:14:03 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Sat Oct 13 00:11:18 2007 Subject: [GRASS-dev] d.graph output not saved with d.out.file Message-ID: <200710121514.03749.dylan.beaudette@gmail.com> Hi, just noticed that the results from d.graph are not saved to an output file when using d.out.file. GRASS 6.3-CVS Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 From twiens at interbaun.com Sat Oct 13 00:22:25 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Sat Oct 13 00:21:26 2007 Subject: [GRASS-dev] gis.m symbol error in cvs In-Reply-To: <2b3d8c1c0710112325m27b9c2a6r653e67eda244514@mail.gmail.com> References: <20071011151902.49f080a8.twiens@interbaun.com> <2b3d8c1c0710112325m27b9c2a6r653e67eda244514@mail.gmail.com> Message-ID: <20071012162225.45ce9dd3.twiens@interbaun.com> On Fri, 12 Oct 2007 09:25:13 +0300 "Maris Nartiss" wrote: > Hi, > You are right. It's broken. > > Guilty lines - 199/227 at > http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gtcltk/select.tcl.diff?r1=1.18&r2=1.19 > > Seems, that we need to go back to old, (ugly) code, if nobody comes up > with better solution. See attached patch. Somebody test && commit. > I tested it locally and it works on my one system ( I don't have access to the other today ). I don't have cvs access so I can't commit it. > Maris. > > 2007/10/12, Trevor Wiens : > > On two systems I've tried, choosing point symbols results in a format of > > > > box@basic > > > > instead of > > > > basic / box > > > > As a result, the display of points fails > > > > T > > -- > > Trevor Wiens > > twiens@interbaun.com > > > > The significant problems that we face cannot be solved at the same > > level of thinking we were at when we created them. > > (Albert Einstein) > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From mlennert at club.worldonline.be Sat Oct 13 00:44:39 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sat Oct 13 00:47:47 2007 Subject: [GRASS-dev] wingrass: problems with some Makefiles In-Reply-To: <1695.85.10.67.131.1191874261.squirrel@geog-pc40.ulb.ac.be> References: <1695.85.10.67.131.1191874261.squirrel@geog-pc40.ulb.ac.be> Message-ID: <2424.85.10.67.131.1192229079.squirrel@geog-pc40.ulb.ac.be> Been working a bit more on this: On Mon, October 8, 2007 22:11, Moritz Lennert wrote: > Hello, > > Trying to recompile in windows (mingw), I get the errors in the attached > log, which I never saw before and which seem to be linked to recent > changes in Makefiles. These errors go away if I revert to the previous version of the Makefile: /c/grasssrc/grass6/general/manage/lister make: *** No rule to make target `|', needed by `/c/grasssrc/grass6/dist.i686-pc-mingw32/etc/lister/cell'. Stop. /c/grasssrc/grass6/lib/form make: *** No rule to make target `|', needed by `/c/grasssrc/grass6/dist.i686-pc-mingw32/etc/form/html_library.tcl'. Stop. After reverting to previous version of Makefile, the error in d.frame compilation is different: -lgrass_display -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_raster -lgrass_pngdriver -lgrass_driver -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lfreetype -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lpng -lz -lgrass_psdriver -lgrass_driver -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lfreetype -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_driver -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lfreetype -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_raster -lgrass_pngdriver -lgrass_driver -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lfreetype -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lpng -lz -lgrass_psdriver -lgrass_driver -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lfreetype -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_driver -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lfreetype -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lxdr -liberty -lws2_32 -lz make /c/grasssrc/grass6/dist.i686-pc-mingw32/docs/html/d.frame.html HTMLSRC=/c/grasssrc/grass6/dist.i686-pc-mingw32/bin/d.frame.exe make[1]: Entering directory `/c/grasssrc/grass6/display/d.frame' make[1]: *** No rule to make target `/c/grasssrc/grass6/dist.i686-pc-mingw32/docs/html/d.frame.html'. Stop. make[1]: Leaving directory `/c/grasssrc/grass6/display/d.frame' make: *** [htmlcmd] Error 2 The same happens when I go another step back in cvs revisions. When I comment the htmlcmd line compilation completes as it should, except that there is no d.frame.html in docs/html. For v.voronoi I also continue to have an error: OBJ.i686-pc-mingw32/vo_main.o: In function `main':c:/grasssrc/grass6/vector/v.voronoi/vo_main.c:89: multiple definition of `main' OBJ.i686-pc-mingw32/dt_main.o:c:/grasssrc/grass6/vector/v.voronoi/dt_main.c:32: first defined here collect2: ld returned 1 exit status make[2]: *** [/c/grasssrc/grass6/dist.i686-pc-mingw32/bin/v.delaunay.exe.exe] Error 1 make[2]: Leaving directory `/c/grasssrc/grass6/vector/v.voronoi' make[1]: *** [htmlcmd] Error 2 make[1]: Leaving directory `/c/grasssrc/grass6/vector/v.voronoi' make: *** [htmlmulti] Error 2 It seems to have some difficulty separating v.voronoi and v.delaunoy builds... Moritz From mlennert at club.worldonline.be Sat Oct 13 00:47:29 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sat Oct 13 00:50:36 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <1790.85.10.67.131.1191876398.squirrel@geog-pc40.ulb.ac.be> References: <2054.85.10.65.83.1188905648.squirrel@geog-pc40.ulb.ac.be> <46DDAD56.8050308@ufg.uni-kiel.de> <46DE691B.1090309@club.worldonline.be> <2903.128.40.195.179.1188985093.squirrel@webmail.mail.uni-kiel.de> <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> <18185.18930.6475.865204@cerise.gclements.plus.com> <1790.85.10.67.131.1191876398.squirrel@geog-pc40.ulb.ac.be> Message-ID: <2431.85.10.67.131.1192229249.squirrel@geog-pc40.ulb.ac.be> On Mon, October 8, 2007 22:46, Moritz Lennert wrote: > On Sun, October 7, 2007 23:04, Glynn Clements wrote: >> Could someone familiar with DBMI and vectors test it out? > > Rapid testing in Debian (v.out/in.ogr, v.univar, d.vect.thematic, g.copy) > with dbf, sqlite, postgres does not show any problems. Will test in > windows as soon as I solve the compile problems. > Compile problems in windows are not solved, yet (see other mail), but they should not interfere with the dbmi issues. Rapid testing in windows also confirms that everything seems to work fine. I propose to commit to CVS to allow further testing. Moritz From hamish_nospam at yahoo.com Sat Oct 13 01:46:33 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Oct 13 01:46:36 2007 Subject: [GRASS-dev] d.graph output not saved with d.out.file In-Reply-To: <200710121514.03749.dylan.beaudette@gmail.com> Message-ID: <175043.46885.qm@web52711.mail.re2.yahoo.com> Dylan Beaudette wrote: > just noticed that the results from d.graph are not saved to an output file > when using d.out.file. GRASS 6.3-CVS from the man page: "The program can be run interactively or non-interactively. The user can run the program completely non-interactively by specifying the name of a graphics file containing the d.graph graphics commands. If run non-interactively the d.graph command is saved to the display's dedraw history." d.out.file requires the instructions to be listed in the display monitor's history (d.save). The same goes for surviving d.redraw. For it to act otherwise it would need to save the stdin info to a .tmp file, like d.text does. The .tmp file sticks around until you restart GRASS. So to get d.out.file to draw your d.graph stuff, use d.graph input=. Hamish ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From tutey at o2.pl Sat Oct 13 11:41:58 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Oct 13 11:42:06 2007 Subject: [GRASS-dev] [grass-code R][510] v.to.db option=length: please report line's 3d length In-Reply-To: References: <20071012134038.E67B240390@pyrosoma.intevation.org> Message-ID: <471092E6.1050009@o2.pl> Martin Landa wrote: > should be fixed in CVS. After brief testing looks OK. Thanks much Martin! Soon after I noticed v.to.db didn't report 3d length, I had the same problem with v.distance (looking for a workaround), which I noted down in the same ticket. Copying the note below: Same request applies to v.distance. It apparently assumes input points are flat too. Consider 2 3d points: $ v.out.ascii start_3d 571600|5722275.5|1|1 $ v.out.ascii end_3d 571610|5722275.5|4|1 The distance between them is about 10.440307. Yet, v.distance claims it's round 10: $ v.distance -p from=start_3d to=end_3d upload=cat,dist col=to_cat,dist from_cat|to_cat|dist 1|1|10.000000 Maciek From landa.martin at gmail.com Sat Oct 13 12:45:36 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sat Oct 13 12:45:40 2007 Subject: [GRASS-dev] [grass-code R][510] v.to.db option=length: please report line's 3d length In-Reply-To: <471092E6.1050009@o2.pl> References: <20071012134038.E67B240390@pyrosoma.intevation.org> <471092E6.1050009@o2.pl> Message-ID: Ahoj Maciek, v.distance should be fixed in CVS (not tested with 3d lines...) Martin 2007/10/13, Maciej Sieczka : > Martin Landa wrote: > > > should be fixed in CVS. > > After brief testing looks OK. Thanks much Martin! > > Soon after I noticed v.to.db didn't report 3d length, I had > the same problem with v.distance (looking for a workaround), > which I noted down in the same ticket. Copying the note below: > > Same request applies to v.distance. It apparently assumes > input points are flat too. Consider 2 3d points: > > $ v.out.ascii start_3d > 571600|5722275.5|1|1 > > $ v.out.ascii end_3d > 571610|5722275.5|4|1 > > The distance between them is about 10.440307. Yet, > v.distance claims it's round 10: > > $ v.distance -p from=start_3d to=end_3d upload=cat,dist > col=to_cat,dist > from_cat|to_cat|dist > 1|1|10.000000 > > Maciek > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From hamish_nospam at yahoo.com Sat Oct 13 13:02:51 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Oct 13 13:02:54 2007 Subject: [GRASS-dev] [grass-code R][510] v.to.db option=length: please report line's 3d length In-Reply-To: Message-ID: <152213.39500.qm@web52707.mail.re2.yahoo.com> > Maciej: > > Same request applies to v.distance. It apparently assumes > > input points are flat too. Consider 2 3d points: Martin wrote: > v.distance should be fixed in CVS (not tested with 3d lines...) d.what.vect will give you a 3D distance to compare against for an easy test. Hamish ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ From tutey at o2.pl Sat Oct 13 14:14:39 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Oct 13 14:14:46 2007 Subject: [GRASS-dev] [grass-code R][510] v.to.db option=length: please report line's 3d length In-Reply-To: <152213.39500.qm@web52707.mail.re2.yahoo.com> References: <152213.39500.qm@web52707.mail.re2.yahoo.com> Message-ID: <4710B6AF.3040205@o2.pl> Hamish wrote: >> Maciej: >>> Same request applies to v.distance. It apparently >>> assumes input points are flat too. Consider 2 3d >>> points: > Martin wrote: >> v.distance should be fixed in CVS Martin You are too quick for me to catch on with testing :). I confim now v.distance calculates the distance between 3D points OK. BTW - v.distance suffers the same issue you have just fixed in v.to.db, among the others, that a dummy column is required in -p(rint) mode. >> (not tested with 3d lines...) Works if both input point and line are 3d: $echo "571710|5722300|4|1" | v.in.ascii -zt z=3 out=pt3d --o $ echo "L 2 571600 5722275.5 0 571610 5722275.5 0" | v.in.ascii -zn form=standard out=l3d $ v.distance -pa from=pt3d to=l3d upload=cat,dist col=cat,dist from_cat|cat|dist 1|null|103.035188 $ echo "L 2 571600 5722275.5 1000 571610 5722275.5 1000" | v.in.ascii -zn form=standard out=l3d --o $ v.distance -pa from=pt3d to=l3d upload=cat,dist col=cat,dist from_cat|cat|dist 1|null|1001.307271 As can be seen the reported distances change as the input 3d line moves in Z. Same happens if the 3d point changes elevation. If *either* or both input is flat, the distance is calculated in 2d space. > d.what.vect will give you a 3D distance to compare > against for an easy test. Sorry I'm dense, but I don't get it how d.what.vect can measure 3D distance. Can you explain? Maciek From michael.barton at asu.edu Sat Oct 13 16:26:21 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Oct 13 16:26:29 2007 Subject: [GRASS-dev] srtm plus format and European bathymetry Message-ID: Ultimately, I'm trying to locate bathymetry off the coast of Europe to create a DEM of Pleistocene Europe during times of low sea level (i.e., -300m). Following the FreeGIS.org link off the GRASS download data page, I found a site with "STRM30 plus" that combine 1km SRTM with bathymetry . This seems just what I need. However, I can't figure out the format or how to import it into GRASS. The files show up like " w020n90.Bathmetry.srtm". I've tried r.in.gdal and r.in.strm to no avail. I thought maybe the files were compressed and tried to uncompress them without luck. Can anyone suggest what to do with these files? And barring that, any suggestions for an alternative site of bathymetry I can patch into my Europe map? Thanks Michael __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071013/d33ba403/attachment-0001.html From michael.barton at asu.edu Sat Oct 13 16:39:07 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Oct 13 16:39:16 2007 Subject: [GRASS-dev] gis.m symbol error in cvs In-Reply-To: <20071012162225.45ce9dd3.twiens@interbaun.com> Message-ID: I just ran into this too. I'm not sure whether it's only a product of my changes of some weeks back to make multiple selections functional (there was quite a bit of broken code that I fixed) or a combination of that and some other changes elsewhere in GRASS. I thought I'd tested all aspects of select.tcl, including symbol selection, but maybe I missed this part. There is a special procedure for symbols that was inserted into select.tcl awhile back (>1yr). Some of this may be what broke multi-selection code, but I can't be sure of that. Now that multi-selection functionality is working again, I'll look to see what is causing this problem with symbol selection. It looks relatively simple to fix--but looks can sometimes be deceiving. Michael On 10/12/07 3:22 PM, "Trevor Wiens" wrote: > On Fri, 12 Oct 2007 09:25:13 +0300 > "Maris Nartiss" wrote: > >> Hi, >> You are right. It's broken. >> >> Guilty lines - 199/227 at >> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gtcltk/select.tcl.diff?r1=1 >> .18&r2=1.19 >> >> Seems, that we need to go back to old, (ugly) code, if nobody comes up >> with better solution. See attached patch. Somebody test && commit. >> > > I tested it locally and it works on my one system ( I don't have access to the > other today ). I don't have cvs access so I can't commit it. > >> Maris. >> >> 2007/10/12, Trevor Wiens : >>> On two systems I've tried, choosing point symbols results in a format of >>> >>> box@basic >>> >>> instead of >>> >>> basic / box >>> >>> As a result, the display of points fails >>> >>> T >>> -- >>> Trevor Wiens >>> twiens@interbaun.com >>> >>> The significant problems that we face cannot be solved at the same >>> level of thinking we were at when we created them. >>> (Albert Einstein) >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev@grass.itc.it >>> http://grass.itc.it/mailman/listinfo/grass-dev >>> >> > __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Sat Oct 13 17:27:50 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Oct 13 17:28:04 2007 Subject: [GRASS-dev] Re: [GRASS-user] srtm plus format and European bathymetry In-Reply-To: References: Message-ID: <4710E3F6.1080102@o2.pl> Michael Barton wrote: > Ultimately, I'm trying to locate bathymetry off the coast of Europe to > create a DEM of Pleistocene Europe during times of low sea level (i.e., > -300m). > > Following the FreeGIS.org link off the GRASS download data page, I found a > site with "STRM30 plus" that combine 1km SRTM with bathymetry > . This seems just what I need. > However, I can't figure out the format or how to import it into GRASS. The > files show up like " w020n90.Bathmetry.srtm". I've tried r.in.gdal and > r.in.strm to no avail. I thought maybe the files were compressed and tried > to uncompress them without luck. > > Can anyone suggest what to do with these files? Michael, ftp://topex.ucsd.edu/pub/srtm30_plus/README.V2.0.txt: DATA FORMATS Data are provided as binary integers in exactly the same format as SRTM30. The files must be uncompressed with gzip and are 16-bit big endian byte order. Other than they don't seem gzipped actually, the information looks correct. These are 16 bit signed integer binary grids. You can use r.in.bin, or r.in.gdal if you create appropriate header files (see r.in.srtm script for inspiration; note it cannot work with 30" SRTM data as it is now - currently it supports only 3" and 1" SRTM tiles). In the presence of properly formatted *.hdr GDAL supports such binary grids with "ESRI .hdr Labelled" driver [1]. In ftp://topex.ucsd.edu/pub/srtm30_plus/ermapper_headers there are ERmapper header files, which I suppose can be used to prepare their GDAL-understandable version. [1] http://www.gdal.org/frmt_various.html#EHdr Maciek From michael.barton at asu.edu Sat Oct 13 18:04:38 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Oct 13 18:04:47 2007 Subject: [GRASS-dev] Re: [GRASS-user] srtm plus format and European bathymetry In-Reply-To: <4710E3F6.1080102@o2.pl> Message-ID: Thanks for the useful hints Maciej. I tried to unzip (as the docs say) and found that they are not zipped. Then I tried to follow the Russian-doll-like descriptions of 'these are formatted like the previous releases' in the brief docs back to USGS EROS where I could not find (yet) a decent description of the format. I'll try your suggestions. Michael On 10/13/07 8:27 AM, "Maciej Sieczka" wrote: > Michael Barton wrote: >> Ultimately, I'm trying to locate bathymetry off the coast of Europe to >> create a DEM of Pleistocene Europe during times of low sea level (i.e., >> -300m). >> >> Following the FreeGIS.org link off the GRASS download data page, I found a >> site with "STRM30 plus" that combine 1km SRTM with bathymetry >> . This seems just what I need. >> However, I can't figure out the format or how to import it into GRASS. The >> files show up like " w020n90.Bathmetry.srtm". I've tried r.in.gdal and >> r.in.strm to no avail. I thought maybe the files were compressed and tried >> to uncompress them without luck. >> >> Can anyone suggest what to do with these files? > > Michael, > > ftp://topex.ucsd.edu/pub/srtm30_plus/README.V2.0.txt: > > > DATA FORMATS > Data are provided as binary integers in exactly the same > format as SRTM30. The files must be uncompressed with gzip > and are 16-bit big endian byte order. > > > Other than they don't seem gzipped actually, the information > looks correct. These are 16 bit signed integer binary grids. > > You can use r.in.bin, or r.in.gdal if you create appropriate > header files (see r.in.srtm script for inspiration; note it > cannot work with 30" SRTM data as it is now - currently it > supports only 3" and 1" SRTM tiles). In the presence of > properly formatted *.hdr GDAL supports such binary grids > with "ESRI .hdr Labelled" driver [1]. In > ftp://topex.ucsd.edu/pub/srtm30_plus/ermapper_headers there > are ERmapper header files, which I suppose can be used to > prepare their GDAL-understandable version. > > [1] http://www.gdal.org/frmt_various.html#EHdr > > Maciek __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sat Oct 13 18:21:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Oct 13 18:21:12 2007 Subject: [GRASS-dev] wingrass: problems with some Makefiles In-Reply-To: <2424.85.10.67.131.1192229079.squirrel@geog-pc40.ulb.ac.be> References: <1695.85.10.67.131.1191874261.squirrel@geog-pc40.ulb.ac.be> <2424.85.10.67.131.1192229079.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18192.61552.776384.837017@cerise.gclements.plus.com> Moritz Lennert wrote: > > Trying to recompile in windows (mingw), I get the errors in the attached > > log, which I never saw before and which seem to be linked to recent > > changes in Makefiles. > > These errors go away if I revert to the previous version of the Makefile: > > /c/grasssrc/grass6/general/manage/lister > make: *** No rule to make target `|', needed by > `/c/grasssrc/grass6/dist.i686-pc-mingw32/etc/lister/cell'. Stop. What version of make do you have? The project page indicates that 3.81 is available: http://sourceforge.net/project/showfiles.php?group_id=2435 > After reverting to previous version of Makefile, the error in d.frame > compilation is different: > make /c/grasssrc/grass6/dist.i686-pc-mingw32/docs/html/d.frame.html > HTMLSRC=/c/grasssrc/grass6/dist.i686-pc-mingw32/bin/d.frame.exe > make[1]: Entering directory `/c/grasssrc/grass6/display/d.frame' > make[1]: *** No rule to make target > `/c/grasssrc/grass6/dist.i686-pc-mingw32/docs/html/d.frame.html'. Stop. Try "make -p -C display/d.frame". > make[1]: Leaving directory `/c/grasssrc/grass6/display/d.frame' > make: *** [htmlcmd] Error 2 > > The same happens when I go another step back in cvs revisions. When I > comment the htmlcmd line compilation completes as it should, except that > there is no d.frame.html in docs/html. > > For v.voronoi I also continue to have an error: > > OBJ.i686-pc-mingw32/vo_main.o: In function > `main':c:/grasssrc/grass6/vector/v.voronoi/vo_main.c:89: multiple > definition of `main' > OBJ.i686-pc-mingw32/dt_main.o:c:/grasssrc/grass6/vector/v.voronoi/dt_main.c:32: > first defined here > It seems to have some difficulty separating v.voronoi and v.delaunoy > builds... Try moving the lines: VORONOI = v.voronoi$(EXE) DELAUNAY = v.delaunay$(EXE) PROGRAMS = $(VORONOI) $(DELAUNAY) to after Module.make is included. I think that it's not getting the .exe extension, so it's try to use the default compilation rule (which uses all .o files) rather than those at the bottom of the Makefile. -- Glynn Clements From lars at ahlzen.com Sun Oct 14 01:20:08 2007 From: lars at ahlzen.com (Lars Ahlzen) Date: Sun Oct 14 01:20:16 2007 Subject: [GRASS-dev] Cairo monitor driver Message-ID: <471152A8.2030604@ahlzen.com> Hi! My apologies if this has been done and/or discussed before, but a search of grass-dev came up empty. Since the Cairo graphics library (http://www.cairographics.org, LGPL licensed) provides very high-quality graphics output in several vector and raster formats, I thought it would make sense to create a "pseudo" monitor driver for it (similar to the PNG and PS drivers). So I did. Cairo does all of the hard work, so it's really mostly simple "glue" code. It seems stable, and is fairly complete in terms of features. I've used for most of my own work recently. Benefits include: * High quality antialiased output. See http://lars.ahlzen.com/cairograss/ for a few simple examples and a comparison with the PNG driver. * Several output format options, both vector and bitmap. The driver currently supports PNG, PDF, PS and SVG. Output to X or Win32 windows might be possible in the future, since Cairo supports such formats as well. Of course, such niceness comes at a price. It takes longer to draw complex vector data, compared to the PNG driver. However, I imagine that in most cases drawing is not the main bottleneck anyway. Also, it obviously pulls in Cairo as an additional dependency. Cairo is probably found on most systems nowadays, though, since many other applications (including some mapping and GIS software) already use it. Additionally, the fact that GRASS monitors (unfortunately) receive integer data (screen coordinates, line widths, etc) somewhat limits the effectiveness of the high-precision output from the CAIRO driver. For example, in the "Massachusetts Counties and roads" example, the antialiasing breaks down for certain lines because they are divided into smaller segments whose coordinates are rounded before they are drawn. Similarly, zooming in on vector output will also reveal this drawback. My main question is: Does all of this seem useful to anyone else? I do realize that most of these things can be achieved in other ways, but I've personally found this driver to produce high quality output in a very convenient way. Feedback is appreciated! I can of course post code too, if anyone would be interested in actually trying it. / Lars -- Lars Ahlzen lars@ahlzen.com From dylan.beaudette at gmail.com Sun Oct 14 03:00:14 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Sun Oct 14 03:00:42 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <471152A8.2030604@ahlzen.com> References: <471152A8.2030604@ahlzen.com> Message-ID: <200710131800.15020.dylan.beaudette@gmail.com> On Saturday 13 October 2007 16:20, Lars Ahlzen wrote: > Hi! > > My apologies if this has been done and/or discussed before, but a search > of grass-dev came up empty. This has not... although other back-end drivers have been discussed... kind of like how R can use a wide variety "output devices". > > Since the Cairo graphics library (http://www.cairographics.org, LGPL > licensed) provides very high-quality graphics output in several vector > and raster formats, I thought it would make sense to create a "pseudo" > monitor driver for it (similar to the PNG and PS drivers). So I did. > Cairo does all of the hard work, so it's really mostly simple "glue" code. Indeed. I have been using it for all of my R work lately. I don't know why this hasn't come up before, but something like Cairo actually solves a lot of the problems we are facing: high quality on-screen display, output to PDF... This would also solve the translucency problem, as Cairo can deal with that quite nicely. > It seems stable, and is fairly complete in terms of features. I've used > for most of my own work recently. Yeah... seems to work quite well with R. > Benefits include: > > * High quality antialiased output. See > http://lars.ahlzen.com/cairograss/ for a few simple examples and a > comparison with the PNG driver. > > * Several output format options, both vector and bitmap. The driver > currently supports PNG, PDF, PS and SVG. Output to X or Win32 windows > might be possible in the future, since Cairo supports such formats as well. > > Of course, such niceness comes at a price. It takes longer to draw > complex vector data, compared to the PNG driver. However, I imagine that > in most cases drawing is not the main bottleneck anyway. For hard copy output like PDF this isn't a problem. > Also, it obviously pulls in Cairo as an additional dependency. Cairo is > probably found on most systems nowadays, though, since many other > applications (including some mapping and GIS software) already use it. If it is an additional feature, then an additional dep. isn't always a bad thing. > Additionally, the fact that GRASS monitors (unfortunately) receive > integer data (screen coordinates, line widths, etc) somewhat limits the > effectiveness of the high-precision output from the CAIRO driver. For > example, in the "Massachusetts Counties and roads" example, the > antialiasing breaks down for certain lines because they are divided into > smaller segments whose coordinates are rounded before they are drawn. > Similarly, zooming in on vector output will also reveal this drawback. Perhaps that rounding can be toggled based on the output device... > My main question is: Does all of this seem useful to anyone else? I do > realize that most of these things can be achieved in other ways, but > I've personally found this driver to produce high quality output in a > very convenient way. Feedback is appreciated! In the past I would approximate this type of output by rendering a PNG at 2x size and then shrink it down with imagemagick. This would give me nice looking lines, but not as nice as what Cairo does. It would also be nice to have an output device which can deal with alpha transparency and PDF versions >= 1.3, which would allow translucency in PDF files. > I can of course post code too, if anyone would be interested in actually > trying it. > > / Lars Posting the code would be great - which version of GRASS was this built against? I am not a developer, but since this is close to something that I would use on a regular basis I can certainly test it out. Cheers, and thanks for the innovative work! Dylan From hamish_nospam at yahoo.com Sun Oct 14 04:50:39 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Oct 14 04:50:42 2007 Subject: [GRASS-dev] [grass-code R][510] v.to.db option=length: please report line's 3d length In-Reply-To: <4710B6AF.3040205@o2.pl> Message-ID: <477846.85324.qm@web52712.mail.re2.yahoo.com> Hamish: > > d.what.vect will give you a 3D distance to compare > > against for an easy test. Maciek: > Sorry I'm dense, but I don't get it how d.what.vect can > measure 3D distance. Can you explain? Length is one it the outputs... just this: echo "L 2 571600 5722275.5 0 571610 5722275.5 20" | v.in.ascii -zn form=standard out=l3d echo "L 2 571600 5722276.5 571610 5722276.5" | v.in.ascii -n form=standard out=l2d g.region v=l3d d.vect l3d d.vect l2d color=blue d.what.vect -x --q 571604.16666667(E) 5722276.5(N) l3d in user1 Nothing Found. l2d in user1 Line length 10.000000 571603.95833333(E) 5722275.45833333(N) l3d in user1 Line length 22.360680 Line height min: 0.000000 max: 20.000000 l2d in user1 Nothing Found. Hamish ____________________________________________________________________________________ Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 From tutey at o2.pl Sun Oct 14 12:33:00 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Oct 14 12:33:09 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <200710131800.15020.dylan.beaudette@gmail.com> References: <471152A8.2030604@ahlzen.com> <200710131800.15020.dylan.beaudette@gmail.com> Message-ID: <4711F05C.9030505@o2.pl> Dylan Beaudette wrote: > On Saturday 13 October 2007 16:20, Lars Ahlzen wrote: >> I can of course post code too, if anyone would be interested in actually >> trying it. > Posting the code would be great - Hi Lars You can submit it to code patches tracker [1]. It will be stored there and a notification about the new ticket, including your message, will be automatically sent to GRASS dev ml. [1]http://wald.intevation.org/tracker/?atid=205&group_id=21&func=browse Maciek From neteler at itc.it Sun Oct 14 16:42:28 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Oct 14 16:42:33 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <2431.85.10.67.131.1192229249.squirrel@geog-pc40.ulb.ac.be> References: <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> <18160.10540.385.812973@cerise.gclements.plus.com> <46F0EE7B.8040801@club.worldonline.be> <18161.33895.287225.27506@cerise.gclements.plus.com> <1145.85.10.70.29.1190325790.squirrel@geog-pc40.ulb.ac.be> <18164.35727.756244.707883@cerise.gclements.plus.com> <1398.85.10.67.113.1190574248.squirrel@geog-pc40.ulb.ac.be> <18167.5602.661916.834459@cerise.gclements.plus.com> <470516FF.9030606@club.worldonline.be> <18181.23315.935184.421493@cerise.gclements.plus.com> <18185.18930.6475.865204@cerise.gclements.plus.com> <1790.85.10.67.131.1191876398.squirrel@geog-pc40.ulb.ac.be> <2431.85.10.67.131.1192229249.squirrel@geog-pc40.ulb.ac.be> Message-ID: <13199672.post@talk.nabble.com> Moritz Lennert-2 wrote: > > On Mon, October 8, 2007 22:46, Moritz Lennert wrote: >> On Sun, October 7, 2007 23:04, Glynn Clements wrote: >>> Could someone familiar with DBMI and vectors test it out? >> >> Rapid testing in Debian (v.out/in.ogr, v.univar, d.vect.thematic, g.copy) >> with dbf, sqlite, postgres does not show any problems. Will test in >> windows as soon as I solve the compile problems. >> > > Compile problems in windows are not solved, yet (see other mail), but they > should not interfere with the dbmi issues. Rapid testing in windows also > confirms that everything seems to work fine. > > I propose to commit to CVS to allow further testing. > This is excellent! And hopefully still comes in time for the upcoming QGIS release (which tells us that we should get out 6.3.0 to avoid a moving target for them!). Markus -- View this message in context: http://www.nabble.com/Re%3A-native-WinGRASS-and-attribute-data-deadlock%2C-next-try-tf4461552.html#a13199672 Sent from the Grass - Dev mailing list archive at Nabble.com. From hmitaso at unity.ncsu.edu Sun Oct 14 18:15:38 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sun Oct 14 18:15:44 2007 Subject: [GRASS-PSC] Re: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <9C0DCF94-D98A-4A10-85F6-1E4C90600FC1@unity.ncsu.edu> References: <20070914114723.GD14995@bartok.itc.it> <332C716A-CA67-41B4-8625-48517170AA5F@unity.ncsu.edu> <9C0DCF94-D98A-4A10-85F6-1E4C90600FC1@unity.ncsu.edu> Message-ID: <14F2D8F4-7ED3-447B-BE06-845CA79AAD28@unity.ncsu.edu> There do not seem to be any serious objections to the migration to OSGeo SVN/Trac, neither has anybody requested a vote, so I suggest that Markus starts the migration on Monday. It is becoming quite urgent due to the changes at ITC-irst (now FBK) so let us not delay further unless there is a very serious reason thanks, Helena Helena Mitasova Dept. of Marine, Earth and Atm. Sciences 1125 Jordan Hall, NCSU Box 8208, Raleigh NC 27695 http://skagit.meas.ncsu.edu/~helena/ On Oct 9, 2007, at 9:00 AM, Helena Mitasova wrote: > We just had a good discussion about the move of GRASS7 development > to SVN that quietly died out without any decision. I am guessing that > there are several of us who are waiting for the move to happen so that > we can get on with our work. So I would like to ask, please check > > http://grass.gdf-hannover.de/wiki/SVN_hosting > (especially explore the links to > GDAL SVN/Trac Server, OSGeo-SAC and Peer1) > > speak-up if you have concerns and if there are no objections Markus > can start the transition of GRASS CVS to OSGeo SVN/Trac, so that we > can use the same infrastructure as GDAL, OSSIM and other OSGeo > projects. We can keep the current Mediawiki as user Wiki and use > Trac as development wiki + PSC. > > Thanks a lot, > > Helena > > P.S. If anybody feels that this issue needs a PSC vote to make it > more formal, > please let Markus know and he can put it up for a vote. > > Helena Mitasova > Dept. of Marine, Earth and Atm. Sciences > 1125 Jordan Hall, NCSU Box 8208, > Raleigh NC 27695 > http://skagit.meas.ncsu.edu/~helena/ > > > > On Sep 15, 2007, at 11:33 PM, Helena Mitasova wrote: > >> I agree with what was already said and I think that there are >> obvious >> advantages to have all OSGeo projects using the same infrastructure. >> As others have mentioned - the reliability of Intevation has been >> outstanding - >> would the new site be equaly reliable? >> I have added the info from Frank to the wiki, along with the link >> (I hope I got it right) in case anybody wants to check it out: >> http://www.peer1.net/en/colocation.asp >> >> It looks as good as it could be, so the last question remains - who >> is paying for the service and is there a possibility that the cost >> may become >> too high for OSGeo (and GRASS) community to handle? >> >> Finally - do we need a vote on this for the record? >> >> Helena >> >> Helena Mitasova >> Dept. of Marine, Earth and Atm. Sciences >> 1125 Jordan Hall, NCSU Box 8208, >> Raleigh NC 27695 >> http://skagit.meas.ncsu.edu/~helena/ >> >> >> >> On Sep 14, 2007, at 7:47 AM, Markus Neteler wrote: >> >>> Dear PSC, >>> >>> we should decide (or give a recommendation to the >>> developers team) about the migration from CVS to SVN. >>> This is currently holding the start of GRASS 7 development. >>> >>> Essentially, all want to migrate to SVN for various >>> advantages already discussed. But we have to define >>> where the hosting will take place. Currently there >>> are two offers: >>> >>> - SVN with GForge at Intevation in Germany >>> - SVN with Trac and Wiki at OSGeo.org >>> >>> With help from Martin Landa I made a Wiki page to >>> confront both suggestions: >>> >>> http://grass.gdf-hannover.de/wiki/SVN_hosting >>> >>> I suggest to discuss this now, add further comments >>> on the Wiki page where appropriate, decide and >>> then really do it soon. There is no real reason >>> to wait any longer. >>> >>> Please visit the Wiki page and come up with >>> comments. I cc to the grass-dev list to reach >>> all interested people. >>> >>> Markus >>> >>> PS: I'll let through relevant cross-postings which >>> will be kept by Mailman in case people aren't subscribed >>> to 'grass-psc'. >>> >>> ------------------ >>> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler >>> ITC -> since 1 March 2007 Fondazione Bruno Kessler >>> ------------------ >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev@grass.itc.it >>> http://grass.itc.it/mailman/listinfo/grass-dev >> >> _______________________________________________ >> grass-psc mailing list >> grass-psc@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-psc > From michael.barton at asu.edu Sun Oct 14 19:50:42 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Oct 14 19:50:51 2007 Subject: [GRASS-dev] gis.m symbol error in cvs In-Reply-To: <4711329a.290.6604.10480@interbaun.com> Message-ID: I fixed this and committed it to the CVS. As I suspected, it was in the subroutine to add vector symbols to the GRASS selection control (line 187-204). The incorrect "[symbol]@[symbol directory]" was hard coded into line 199--possibly for an earlier version of selecting symbols. This did not show up before, because of bugs in the rest of the code. I replaced this with "[symbol directory]/[symbol]" as we currently use it. Michael On 10/13/07 2:03 PM, "twiens" wrote: > > > ----- Original Message Follows ----- > From: Michael Barton > To: Trevor Wiens , Maris Nartiss > > Cc: grass-dev@grass.itc.it > Subject: Re: [GRASS-dev] gis.m symbol error in cvs > Date: Sat, 13 Oct 2007 07:39:07 -0700 > >> I just ran into this too. I'm not sure whether it's only a >> product of my changes of some weeks back to make multiple >> selections functional (there was quite a bit of broken >> code that I fixed) or a combination of that and some other >> changes elsewhere in GRASS. I thought I'd tested all >> aspects of select.tcl, including symbol selection, but >> maybe I missed this part. >> >> There is a special procedure for symbols that was inserted >> into select.tcl awhile back (>1yr). Some of this may be >> what broke multi-selection code, but I can't be sure of >> that. Now that multi-selection functionality is working >> again, I'll look to see what is causing this problem with >> symbol selection. It looks relatively simple to fix--but >> looks can sometimes be deceiving. >> > > If you look at Maris's response she / he provided a patch > that repairs the problem. I had tried it at home and the > patch works. I don't have cvs access so I can't post it. > > T > > -- > Trevor Wiens > twiens@interbaun.com __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sun Oct 14 20:18:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Oct 14 20:19:07 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <200710131800.15020.dylan.beaudette@gmail.com> References: <471152A8.2030604@ahlzen.com> <200710131800.15020.dylan.beaudette@gmail.com> Message-ID: <18194.23953.482585.352251@cerise.gclements.plus.com> Dylan Beaudette wrote: > > Since the Cairo graphics library (http://www.cairographics.org, LGPL > > licensed) provides very high-quality graphics output in several vector > > and raster formats, I thought it would make sense to create a "pseudo" > > monitor driver for it (similar to the PNG and PS drivers). So I did. > > Cairo does all of the hard work, so it's really mostly simple "glue" code. > > Indeed. I have been using it for all of my R work lately. I don't know why > this hasn't come up before, but something like Cairo actually solves a lot of > the problems we are facing: high quality on-screen display, output to PDF... > > This would also solve the translucency problem, as Cairo can deal with that > quite nicely. The problem with translucency is that not all rendering systems support it. The core X11 protocol doesn't, so you either need the Render extension or to perform the rendering client-side. PostScript doesn't support it, as most printers only have one bit per component. -- Glynn Clements From glynn at gclements.plus.com Sun Oct 14 20:36:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Oct 14 20:37:08 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <471152A8.2030604@ahlzen.com> References: <471152A8.2030604@ahlzen.com> Message-ID: <18194.25025.606541.860222@cerise.gclements.plus.com> Lars Ahlzen wrote: > My apologies if this has been done and/or discussed before, but a search > of grass-dev came up empty. > > Since the Cairo graphics library (http://www.cairographics.org, LGPL > licensed) provides very high-quality graphics output in several vector > and raster formats, I thought it would make sense to create a "pseudo" > monitor driver for it (similar to the PNG and PS drivers). So I did. > Cairo does all of the hard work, so it's really mostly simple "glue" code. > > It seems stable, and is fairly complete in terms of features. I've used > for most of my own work recently. > > Benefits include: > > * High quality antialiased output. See > http://lars.ahlzen.com/cairograss/ for a few simple examples and a > comparison with the PNG driver. One thing to be careful of with anti-aliasing is tesselations. Issues with Ghostscript's anti-aliasing option are a regular topic on the GMT list. > * Several output format options, both vector and bitmap. The driver > currently supports PNG, PDF, PS and SVG. Output to X or Win32 windows > might be possible in the future, since Cairo supports such formats as well. > > Of course, such niceness comes at a price. It takes longer to draw > complex vector data, compared to the PNG driver. However, I imagine that > in most cases drawing is not the main bottleneck anyway. For d.vect, drawing usually is the bottleneck. > Also, it obviously pulls in Cairo as an additional dependency. Cairo is > probably found on most systems nowadays, though, since many other > applications (including some mapping and GIS software) already use it. > > Additionally, the fact that GRASS monitors (unfortunately) receive > integer data (screen coordinates, line widths, etc) somewhat limits the > effectiveness of the high-precision output from the CAIRO driver. For > example, in the "Massachusetts Counties and roads" example, the > antialiasing breaks down for certain lines because they are divided into > smaller segments whose coordinates are rounded before they are drawn. > Similarly, zooming in on vector output will also reveal this drawback. > > My main question is: Does all of this seem useful to anyone else? I do > realize that most of these things can be achieved in other ways, but > I've personally found this driver to produce high quality output in a > very convenient way. Feedback is appreciated! The main thing to bear in mind is that the graphics system is going to be completely re-written for 7.x. If Cairo is available for both Windows and MacOSX (natively, i.e. not requiring X11), and does an adequate job of PostScript generation (embedding a pre-rendered image in a PostScript file doesn't count), it could be a viable basis for the new graphics architecture. > I can of course post code too, if anyone would be interested in actually > trying it. The code would certainly be useful. -- Glynn Clements From michael.barton at asu.edu Sun Oct 14 20:48:13 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Oct 14 20:48:19 2007 Subject: [GRASS-dev] no custom breaks for d.vect.thematic Message-ID: A lot has been added by others to improve d.vect.thematic since I first wrote it. One is the addition of custom break points. But now it seems that custom breaks don't draw a thematic map. Has anyone else had this problem? So far, in attempting to debug, I've found that the script is actually reading the custom break points correctly and even making a legend. I can't see how it could NOT be actually making vector maps. I suppose it could something with awk somewhere, but this seems to be working OK AFAICT. Michael __________________________________________ 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-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071014/65222e5c/attachment.html From lars at ahlzen.com Sun Oct 14 20:52:35 2007 From: lars at ahlzen.com (Lars Ahlzen) Date: Sun Oct 14 20:52:45 2007 Subject: [GRASS-dev] Cairo monitor driver Message-ID: <47126573.3090602@ahlzen.com> Dylan Beaudette wrote: >> Since the Cairo graphics library (http://www.cairographics.org, LGPL >> licensed) provides very high-quality graphics output in several vector >> and raster formats, I thought it would make sense to create a "pseudo" >> monitor driver for it (similar to the PNG and PS drivers). So I did. >> Cairo does all of the hard work, so it's really mostly simple "glue" code. > > Indeed. I have been using it for all of my R work lately. I don't know why > this hasn't come up before, but something like Cairo actually solves a lot of > the problems we are facing: high quality on-screen display, output to PDF... Yep. > This would also solve the translucency problem, as Cairo can deal with that > quite nicely. Indeed. Cairo has good support for many things that (AFAIK) aren't directly supported by GRASS yet, but may one day be really nice to have. Examples include: Transparency (although gis.m "emulates" this using g.pnmcomp) and more advanced compositing, different line end/join styles (rounded, beveled, square, ...), high-quality text rendering, line patterns (dashed, dotted, ...), fill patterns, gradients, free-form antialiased masking, non-integer line widths etc. >> Of course, such niceness comes at a price. It takes longer to draw >> complex vector data, compared to the PNG driver. However, I imagine that >> in most cases drawing is not the main bottleneck anyway. > > For hard copy output like PDF this isn't a problem. True. And even for screen rendering, in practical cases we're probably talking about seconds at most. >> Additionally, the fact that GRASS monitors (unfortunately) receive >> integer data (screen coordinates, line widths, etc) somewhat limits the >> effectiveness of the high-precision output from the CAIRO driver. For >> example, in the "Massachusetts Counties and roads" example, the >> antialiasing breaks down for certain lines because they are divided into >> smaller segments whose coordinates are rounded before they are drawn. >> Similarly, zooming in on vector output will also reveal this drawback. > > Perhaps that rounding can be toggled based on the output device... I wish, and please prove me wrong here, but I believe that this would require a (minor) architectural change to GRASS. All monitors drivers get their drawing coordinates as integer data, e.g. "Draw a line from position 4, 23 to 5, 45", rather than floating point values, like "Draw a line from 3.84, 22.96 to 5.41, 45.11". That makes some sense as long as you only display data on a pixel based screen/file with no antialiasing or oversampling (like the X or PNG monitors), but not for higher quality or vector format output. The PS driver that is currently in the CVS tree seems to suffer from the same problem, btw, which limits its usefulness as well. Changing this would probably mean adjusting all monitor drivers (which I don't think would be overly complicated, but it would take a bit of work). Eventually it would be nice if GRASS supported floating point for things like line widths, point/symbol/text sizes and similar things too, but this would probably require more substantial changes. >> My main question is: Does all of this seem useful to anyone else? I do >> realize that most of these things can be achieved in other ways, but >> I've personally found this driver to produce high quality output in a >> very convenient way. Feedback is appreciated! > > In the past I would approximate this type of output by rendering a PNG at 2x > size and then shrink it down with imagemagick. This would give me nice > looking lines, but not as nice as what Cairo does. I've done the same thing, often even 4x or 6x. What I found inconvenient about this approach is that, after working at 1x, not only does the resolution need to be changed, but every line width, symbol size, text size in every drawing command needs to be scaled accordingly as well. You can get "creative" here with scripting, but in the end it still means more work for you... > It would also be nice to > have an output device which can deal with alpha transparency and PDF versions >> = 1.3, which would allow translucency in PDF files. I would, although I'm not sure how it would be handled by GRASS. > Posting the code would be great - which version of GRASS was this built > against? > > I am not a developer, but since this is close to something that I would use on > a regular basis I can certainly test it out. Great! I'll post the code to the patch tracker, as suggested by Maciek, as soon as I can. > Cheers, and thanks for the innovative work! Thanks for the feedback! It's appreciated. / Lars -- Lars Ahlzen lars@ahlzen.com From mlennert at club.worldonline.be Sun Oct 14 21:04:58 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sun Oct 14 20:58:39 2007 Subject: [GRASS-dev] no custom breaks for d.vect.thematic In-Reply-To: References: Message-ID: <4712685A.5050707@club.worldonline.be> Michael Barton wrote: > A lot has been added by others to improve d.vect.thematic since I first > wrote it. One is the addition of custom break points. But now it seems > that custom breaks don't draw a thematic map. Has anyone else had this > problem? > > So far, in attempting to debug, I've found that the script is actually > reading the custom break points correctly and even making a legend. I > can't see how it could NOT be actually making vector maps. I suppose it > could something with awk somewhere, but this seems to be working OK AFAICT. I cannot confirm this. I have been using custom breaks regularly without any problems. What do you mean by "that custom breaks don't draw a thematic map" ? What do they draw ? Moritz From lars at ahlzen.com Sun Oct 14 20:59:04 2007 From: lars at ahlzen.com (Lars Ahlzen) Date: Sun Oct 14 20:59:16 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <18194.23953.482585.352251@cerise.gclements.plus.com> References: <471152A8.2030604@ahlzen.com> <200710131800.15020.dylan.beaudette@gmail.com> <18194.23953.482585.352251@cerise.gclements.plus.com> Message-ID: <471266F8.2030402@ahlzen.com> Glynn Clements wrote: > Dylan Beaudette wrote: > >>> Since the Cairo graphics library (http://www.cairographics.org, LGPL >>> licensed) provides very high-quality graphics output in several vector >>> and raster formats, I thought it would make sense to create a "pseudo" >>> monitor driver for it (similar to the PNG and PS drivers). So I did. >>> Cairo does all of the hard work, so it's really mostly simple "glue" code. >> Indeed. I have been using it for all of my R work lately. I don't know why >> this hasn't come up before, but something like Cairo actually solves a lot of >> the problems we are facing: high quality on-screen display, output to PDF... >> >> This would also solve the translucency problem, as Cairo can deal with that >> quite nicely. > > The problem with translucency is that not all rendering systems > support it. The core X11 protocol doesn't, so you either need the > Render extension or to perform the rendering client-side. I believe that Cairo does this client-side for X surfaces, so one wouldn't really need to worry about it. > PostScript doesn't support it, as most printers only have one bit per component. True. Not much do do about this case (other than perhaps use PDF, and a printer driver that does the compositing in software before it's sent to the printer). / Lars -- Lars Ahlzen lars@ahlzen.com From rez at touchofmadness.com Sun Oct 14 21:01:14 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Oct 14 21:01:33 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <18194.25025.606541.860222@cerise.gclements.plus.com> References: <471152A8.2030604@ahlzen.com> <18194.25025.606541.860222@cerise.gclements.plus.com> Message-ID: <1192388474.17343.293.camel@dev64.localdomain> On Sun, 2007-10-14 at 19:36 +0100, Glynn Clements wrote: > The main thing to bear in mind is that the graphics system is going to > be completely re-written for 7.x. Could your provide details? I've seen bits here and there, but it would be nice to have a summary of planned changes in one place. > If Cairo is available for both Windows and MacOSX (natively, i.e. not > requiring X11), and does an adequate job of PostScript generation > (embedding a pre-rendered image in a PostScript file doesn't count), > it could be a viable basis for the new graphics architecture. Yes, Cairo is available without X11. It comes with recent versions of GTK, but is available as a completely separate standalone library. >From http://www.cairographics.org/download/ (Windows): "You want "cairo-1.4.8.zip", the binary distribution at "libpng 1.2.8", and "Zlib 1.2.3" (you can search on those strings to find them in the page). That should be it. Just pop libcairo-2.dll, libpng13.dll and zlib1.dll into your working directory or system PATH, and away you go!" > > I can of course post code too, if anyone would be interested in actually > > trying it. > > The code would certainly be useful. +1 -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From lars at ahlzen.com Sun Oct 14 21:29:06 2007 From: lars at ahlzen.com (Lars Ahlzen) Date: Sun Oct 14 21:29:11 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <18194.25025.606541.860222@cerise.gclements.plus.com> References: <471152A8.2030604@ahlzen.com> <18194.25025.606541.860222@cerise.gclements.plus.com> Message-ID: <47126E02.7010400@ahlzen.com> Glynn Clements wrote: >> * High quality antialiased output. See >> http://lars.ahlzen.com/cairograss/ for a few simple examples and a >> comparison with the PNG driver. > > One thing to be careful of with anti-aliasing is tesselations. Issues > with Ghostscript's anti-aliasing option are a regular topic on the GMT > list. Good point. I don't know how well this driver handles that. During my own use i haven't *noticed* any issues, but you or some one else might have good test cases to try once I post the code. >> My main question is: Does all of this seem useful to anyone else? I do >> realize that most of these things can be achieved in other ways, but >> I've personally found this driver to produce high quality output in a >> very convenient way. Feedback is appreciated! > > The main thing to bear in mind is that the graphics system is going to > be completely re-written for 7.x. If that's the case (I actually wasn't aware; I haven't followed grass-dev for that long), I guess it isn't worth spending an enormous amount of effort on something like this. It may still be useful in the meantime, though. > If Cairo is available for both Windows and MacOSX (natively, i.e. not > requiring X11), and does an adequate job of PostScript generation > (embedding a pre-rendered image in a PostScript file doesn't count), > it could be a viable basis for the new graphics architecture. It is native cross-platform. According to the docs, it even uses hardware acceleration where available. And yes, it produces real, actual vector output (PS, PDF and supposedly SVG although I had some issues with that), not just a bitmap with a PS/PDF header. There are some PDF examples rendered with the CAIRO GRASS driver at http://lars.ahlzen.com/cairograss/ There are also (currently experimental) support for OpenGL output, which may be useful if one wanted the new graphics architecture to support nviz and realtime graphics. For Mac there's Quartz in the works, too. Btw, IMO Cairo would be an excellent candidate to base a new graphics/rendering system on. >> I can of course post code too, if anyone would be interested in actually >> trying it. > > The code would certainly be useful. Will post. :) / Lars -- Lars Ahlzen lars@ahlzen.com From neteler at itc.it Mon Oct 15 00:12:19 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Oct 15 00:12:23 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <20070811081434.GB28767@bartok.itc.it> References: <20070811081434.GB28767@bartok.itc.it> Message-ID: <13204091.post@talk.nabble.com> Markus Neteler wrote: > > I think that it is time to get out a GRASS 6.3.0 release > (as sort of technology preview). It would be great to > have it ready for FOSS4G2007, say, September. > > IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? > I suggest to try again these days once Glynn/Moritz have updated for the winGRASS DBMI troubles (patch is prepared but AFAIK not yet submitted). With help of others I'll do backporting as needed (and 6.3.0 is the typical "technology preview"). Markus -- View this message in context: http://www.nabble.com/GRASS-6.3.0-release-preparation-tf4252794.html#a13204091 Sent from the Grass - Dev mailing list archive at Nabble.com. From woklist at kyngchaos.com Mon Oct 15 01:02:10 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Oct 15 01:03:09 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <13204091.post@talk.nabble.com> References: <20070811081434.GB28767@bartok.itc.it> <13204091.post@talk.nabble.com> Message-ID: <71C63B15-8686-4884-9062-8612A7C9F6F8@kyngchaos.com> Glynn, do you think the makefile changes for the extension building will make it into the 6.3 release? I haven't paid much attention to the 6.3 feature plan, but I see there is an item about using GEM for addons that this may affect (simplifying GEM). On Oct 14, 2007, at 5:12 PM, Markus Neteler wrote: > > > Markus Neteler wrote: >> >> I think that it is time to get out a GRASS 6.3.0 release >> (as sort of technology preview). It would be great to >> have it ready for FOSS4G2007, say, September. >> >> IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? >> > > I suggest to try again these days once Glynn/Moritz have updated > for the winGRASS DBMI troubles (patch is prepared but AFAIK not > yet submitted). With help of others I'll do backporting as needed > (and 6.3.0 is the typical "technology preview"). > > Markus ----- 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 From glynn at gclements.plus.com Mon Oct 15 03:54:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 15 03:54:33 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <47126573.3090602@ahlzen.com> References: <47126573.3090602@ahlzen.com> Message-ID: <18194.51271.145398.778299@cerise.gclements.plus.com> Lars Ahlzen wrote: > >> Additionally, the fact that GRASS monitors (unfortunately) receive > >> integer data (screen coordinates, line widths, etc) somewhat limits the > >> effectiveness of the high-precision output from the CAIRO driver. For > >> example, in the "Massachusetts Counties and roads" example, the > >> antialiasing breaks down for certain lines because they are divided into > >> smaller segments whose coordinates are rounded before they are drawn. > >> Similarly, zooming in on vector output will also reveal this drawback. > > > > Perhaps that rounding can be toggled based on the output device... > > I wish, and please prove me wrong here, but I believe that this would > require a (minor) architectural change to GRASS. All monitors drivers > get their drawing coordinates as integer data, e.g. "Draw a line from > position 4, 23 to 5, 45", rather than floating point values, like "Draw > a line from 3.84, 22.96 to 5.41, 45.11". One of the main changes in 7.x is that graphics coordinates will use floating-point. For geographic data, the expected approach will be to set an appropriate transform then use cartographic coordinates. > That makes some sense as long as you only display data on a pixel based > screen/file with no antialiasing or oversampling (like the X or PNG > monitors), but not for higher quality or vector format output. > > The PS driver that is currently in the CVS tree seems to suffer from the > same problem, btw, which limits its usefulness as well. > > Changing this would probably mean adjusting all monitor drivers (which I > don't think would be overly complicated, but it would take a bit of work). Changing the drivers is the easy part; it's changing all of the d.* commands which takes the effort. -- Glynn Clements From glynn at gclements.plus.com Mon Oct 15 04:10:38 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 15 04:10:51 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <471266F8.2030402@ahlzen.com> References: <471152A8.2030604@ahlzen.com> <200710131800.15020.dylan.beaudette@gmail.com> <18194.23953.482585.352251@cerise.gclements.plus.com> <471266F8.2030402@ahlzen.com> Message-ID: <18194.52254.913437.647110@cerise.gclements.plus.com> Lars Ahlzen wrote: > >>> Since the Cairo graphics library (http://www.cairographics.org, LGPL > >>> licensed) provides very high-quality graphics output in several vector > >>> and raster formats, I thought it would make sense to create a "pseudo" > >>> monitor driver for it (similar to the PNG and PS drivers). So I did. > >>> Cairo does all of the hard work, so it's really mostly simple "glue" code. > >> Indeed. I have been using it for all of my R work lately. I don't know why > >> this hasn't come up before, but something like Cairo actually solves a lot of > >> the problems we are facing: high quality on-screen display, output to PDF... > >> > >> This would also solve the translucency problem, as Cairo can deal with that > >> quite nicely. > > > > The problem with translucency is that not all rendering systems > > support it. The core X11 protocol doesn't, so you either need the > > Render extension or to perform the rendering client-side. > > I believe that Cairo does this client-side for X surfaces, so one > wouldn't really need to worry about it. Doing it client side can be a major performance hit. Apart from anything else, all of the rendering has to be done in software; your graphics hardware can't help. OTOH, we're already taking that hit with gis.m/wxGRASS and the PNG driver. It's less significant for simple visualisation, but it could be a major issue for interactive editing of vector data. > > PostScript doesn't support it, as most printers only have one bit per component. > > True. Not much do do about this case (other than perhaps use PDF, and a > printer driver that does the compositing in software before it's sent to > the printer). Pre-rasterising is less than ideal, for two main reasons: 1. For networked setups, the amount of data involved starts to become a major issue in terms of network bandwidth and disk usage, particularly with 1200x1200 DPI printers being relatively common nowadays. 2. The results are often less than ideal. Emulating intensity levels through halftones has a cost in terms of spatial resolution. You get better results if the halftoning is done on vector primitives (rather than pre-rendered images), and if it's tailored to the actual printing technology (for a laser printer, the transfer from the digital framebuffer to an actual page is quite noisy, which is why the default halftone resolution is usually substantially lower than the pixel resolution). You're a lot better off if you don't assume that you have a magic bullet which will make anti-aliasing and alpha-blending work for hardcopy as it does on video. IOW, explicitly allowing for hardcopy devices rather than designing for video then trying to bang the hardcopy peg into the video hole. -- Glynn Clements From glynn at gclements.plus.com Mon Oct 15 04:21:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 15 04:21:48 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <1192388474.17343.293.camel@dev64.localdomain> References: <471152A8.2030604@ahlzen.com> <18194.25025.606541.860222@cerise.gclements.plus.com> <1192388474.17343.293.camel@dev64.localdomain> Message-ID: <18194.52921.352249.75702@cerise.gclements.plus.com> Brad Douglas wrote: > > The main thing to bear in mind is that the graphics system is going to > > be completely re-written for 7.x. > > Could your provide details? I've seen bits here and there, but it would > be nice to have a summary of planned changes in one place. Main points include: 1. Eliminating seperate driver processes. Having to extend the protocol for each new operation has been a major drag on development. 2. Use of floating-point for all coordinates. 3. Common architecture for both video and hardcopy output. ps.map should be redundant. In retrospect, #1 means that we don't really need support for the Windows/MacOSX GUI, just the ability to generate image files. With X, we could take the shortcut of having d.* commands draw directly into an existing window, but I don't know whether that's possible on other platforms. OTOH, it might be useful to be able to use the same functions for self-contained GUI programs (e.g. vector digitising) as for d.* commands. -- Glynn Clements From glynn at gclements.plus.com Mon Oct 15 04:48:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 15 04:49:34 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <47126E02.7010400@ahlzen.com> References: <471152A8.2030604@ahlzen.com> <18194.25025.606541.860222@cerise.gclements.plus.com> <47126E02.7010400@ahlzen.com> Message-ID: <18194.54497.196252.42892@cerise.gclements.plus.com> Lars Ahlzen wrote: > >> * High quality antialiased output. See > >> http://lars.ahlzen.com/cairograss/ for a few simple examples and a > >> comparison with the PNG driver. > > > > One thing to be careful of with anti-aliasing is tesselations. Issues > > with Ghostscript's anti-aliasing option are a regular topic on the GMT > > list. > > Good point. > > I don't know how well this driver handles that. During my own use i > haven't *noticed* any issues, but you or some one else might have good > test cases to try once I post the code. Take a map with many adjoining polygons, e.g. "soils" from spearfish, then assign colours such that adjacent polygons have the same colour. Anti-aliasing will produce visible lines between polygons. It needs to be borne in mind that anti-aliasing edges is a "hack". Sometimes it works, sometimes it doesn't. When it doesn't, you need to to either use oversampling or to simply disable it. > > If Cairo is available for both Windows and MacOSX (natively, i.e. not > > requiring X11), and does an adequate job of PostScript generation > > (embedding a pre-rendered image in a PostScript file doesn't count), > > it could be a viable basis for the new graphics architecture. > > It is native cross-platform. According to the docs, it even uses > hardware acceleration where available. > > And yes, it produces real, actual vector output (PS, PDF and supposedly > SVG although I had some issues with that), not just a bitmap with a > PS/PDF header. There are some PDF examples rendered with the CAIRO GRASS > driver at http://lars.ahlzen.com/cairograss/ I've read up a bit about Cairo today. I note that it has a mechanism to fall back to rasterisation for operations which can't be implemented by vector targets (surfaces). In some situations, that may be useful; in others, it will be a nuisance. In particular, it doesn't mean that GRASS can just forget about vector targets and leave it to Cairo. One of the main areas where this is relevant is if we want translucent layers. It's possible to simulate translucency in PostScript using pattern fills, but you need to be careful when selecting the grid (frequency, phase, orientation) or else you can get artifacts. It gets complex if you want more than one translucent layer, as you have to plan all of the layers in advance (i.e. when drawing the intermediate layers, you have to allow for layers which will be drawn on top). -- Glynn Clements From neteler at itc.it Mon Oct 15 10:17:23 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Oct 15 10:17:27 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <18194.52921.352249.75702@cerise.gclements.plus.com> References: <471152A8.2030604@ahlzen.com> <18194.25025.606541.860222@cerise.gclements.plus.com> <1192388474.17343.293.camel@dev64.localdomain> <18194.52921.352249.75702@cerise.gclements.plus.com> Message-ID: <13208582.post@talk.nabble.com> Glynn Clements wrote: > > > Brad Douglas wrote: >> > The main thing to bear in mind is that the graphics system is going to >> > be completely re-written for 7.x. >> >> Could your provide details? I've seen bits here and there, but it would >> be nice to have a summary of planned changes in one place. > > Main points include: > ... > I have taken liberty to add them here: http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection#Display Markus -- View this message in context: http://www.nabble.com/Cairo-monitor-driver-tf4620004.html#a13208582 Sent from the Grass - Dev mailing list archive at Nabble.com. From tutey at o2.pl Mon Oct 15 11:22:53 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 15 11:23:01 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <13204091.post@talk.nabble.com> References: <20070811081434.GB28767@bartok.itc.it> <13204091.post@talk.nabble.com> Message-ID: <4713316D.6010004@o2.pl> Markus Neteler wrote: > Markus Neteler wrote: >> I think that it is time to get out a GRASS 6.3.0 release >> (as sort of technology preview). It would be great to >> have it ready for FOSS4G2007, say, September. >> >> IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? > I suggest to try again these days once Glynn/Moritz have updated > for the winGRASS DBMI troubles (patch is prepared but AFAIK not > yet submitted). With help of others I'll do backporting as needed > (and 6.3.0 is the typical "technology preview"). Is there anybody able to fix the "r.out.gdal sets NoData wrong" [1] bug before releasing 6.3? It's data corruption issue. [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=405&group_id=21&atid=204 Maciek From hamish_nospam at yahoo.com Mon Oct 15 11:26:14 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 15 11:26:16 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <18194.52254.913437.647110@cerise.gclements.plus.com> Message-ID: <301480.42124.qm@web52711.mail.re2.yahoo.com> > > The problem with translucency is that not all rendering systems > > support it. The core X11 protocol doesn't, so you either need the > > Render extension or to perform the rendering client-side. Not quite replying to right part of the thread, but I thought it should be mentioned that (AFAIR) translucency in PDF >=1.4 is limited to vector fills. > Doing it client side can be a major performance hit. Apart from > anything else, all of the rendering has to be done in software; your > graphics hardware can't help. Even if we use the much faster PNG(PPM) driver for fast GUI rendering, it sure would be nice to click a "quality mode" switch in the GUI to switch to the Cairo driver to create presentation quality output. For hardcopies (or softcopy raster output for presentation or web publication) quality is much more important than speed. (up the point it takes all night to render) For the GUI speed becomes the important factor, quality is reduced to a nice bonus. Hamish ____________________________________________________________________________________ Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html From hamish_nospam at yahoo.com Mon Oct 15 11:31:55 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 15 11:31:57 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <18194.54497.196252.42892@cerise.gclements.plus.com> Message-ID: <516222.44009.qm@web52711.mail.re2.yahoo.com> Glynn Clements wrote: > One of the main areas where this is relevant is if we want translucent > layers. It's possible to simulate translucency in PostScript using > pattern fills, but you need to be careful when selecting the grid > (frequency, phase, orientation) or else you can get artifacts. Older versions of Surfer (the commercial 3D surface rendering program) that I have used do that for area fills- shades of grey are many dots of varying density. The PS output is a massive file which takes a silly amount of time to render in gv and is generally an all-around PITA to work with. (meant as an anecdote, not as a condemnation of the approach) Hamish ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ From hamish_nospam at yahoo.com Mon Oct 15 11:46:18 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Oct 15 11:46:21 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <516222.44009.qm@web52711.mail.re2.yahoo.com> Message-ID: <488030.19833.qm@web52712.mail.re2.yahoo.com> Hamish wrote: > Older versions of Surfer (the commercial 3D surface rendering program) that I > have used do that for area fills- shades of grey are many dots of varying > density. The PS output is a massive file which takes a silly amount of time > to render in gv and is generally an all-around PITA to work with. (meant as > an anecdote, not as a condemnation of the approach) oh, and the aliasing problems are horrible when you resize. Hamish ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ From tutey at o2.pl Mon Oct 15 12:18:00 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 15 12:18:07 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <4713316D.6010004@o2.pl> References: <20070811081434.GB28767@bartok.itc.it> <13204091.post@talk.nabble.com> <4713316D.6010004@o2.pl> Message-ID: <47133E58.7060609@o2.pl> Maciej Sieczka wrote: > Markus Neteler wrote: >> Markus Neteler wrote: >>> I think that it is time to get out a GRASS 6.3.0 release >>> (as sort of technology preview). It would be great to >>> have it ready for FOSS4G2007, say, September. >>> >>> IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? >> I suggest to try again these days once Glynn/Moritz have updated >> for the winGRASS DBMI troubles (patch is prepared but AFAIK not >> yet submitted). With help of others I'll do backporting as needed >> (and 6.3.0 is the typical "technology preview"). > Is there anybody able to fix the "r.out.gdal sets NoData > wrong" [1] bug before releasing 6.3? It's data corruption issue. > > [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=405&group_id=21&atid=204 Also, the bug g.region [2] is very serious. Any chances these 2 bugs could be fixed before relasing 6.3? It would be much better not to release with *known* bugs which might corrupt users data. [2]http://wald.intevation.org/tracker/?func=detail&atid=204&aid=489&group_id=21 Maciek From neteler at itc.it Mon Oct 15 12:22:41 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Oct 15 12:22:43 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <4713316D.6010004@o2.pl> References: <20070811081434.GB28767@bartok.itc.it> <13204091.post@talk.nabble.com> <4713316D.6010004@o2.pl> Message-ID: <13210067.post@talk.nabble.com> Maciej Sieczka wrote: > > Markus Neteler wrote: >> Markus Neteler wrote: > >>> I think that it is time to get out a GRASS 6.3.0 release >>> (as sort of technology preview). It would be great to >>> have it ready for FOSS4G2007, say, September. >>> >>> IMHO, GRASS 6.3-CVS is in a good shape. Thoughts? > >> I suggest to try again these days once Glynn/Moritz have updated >> for the winGRASS DBMI troubles (patch is prepared but AFAIK not >> yet submitted). With help of others I'll do backporting as needed >> (and 6.3.0 is the typical "technology preview"). > > Is there anybody able to fix the "r.out.gdal sets NoData > wrong" [1] bug before releasing 6.3? It's data corruption issue. > > [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=405&group_id=21&atid=204 > > Maciek > Please collect such wishes here: http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan#TODO_GRASS_6.3.0 Markus PS: note, in 'trac' you can do easy milestone assignments rather than priority listing from GForge -- View this message in context: http://www.nabble.com/GRASS-6.3.0-release-preparation-tf4252794.html#a13210067 Sent from the Grass - Dev mailing list archive at Nabble.com. From tutey at o2.pl Mon Oct 15 12:48:29 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 15 12:48:38 2007 Subject: [GRASS-dev] v.mkgrid - why 2 extra nodes in horizontal boundaries? Message-ID: <4713457D.9070007@o2.pl> Hi I'm not sure if this is a defect or a feature for a purpose, thus asking first. v.mkgrid always creates areas with horizontal boundaries having 2 extra nodes (see attached screendump from v.digit). I can't see a reason why extra nodes are necesssary. Vertical boundaries don't have them... Maciek From tutey at o2.pl Mon Oct 15 13:03:23 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 15 13:03:32 2007 Subject: [GRASS-dev] v.mkgrid - why 2 extra nodes in horizontal boundaries? In-Reply-To: <4713457D.9070007@o2.pl> References: <4713457D.9070007@o2.pl> Message-ID: <471348FB.70303@o2.pl> Maciej Sieczka wrote: > v.mkgrid always creates areas with horizontal boundaries > having 2 extra nodes (see attached screendump from v.digit). Forgot to attach. Here it is. Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: extra_nodes.png Type: image/png Size: 531 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071015/c9e3d4ac/extra_nodes.png From landa.martin at gmail.com Mon Oct 15 13:14:19 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Oct 15 13:14:27 2007 Subject: [GRASS-dev] GRASS 6.3.0 release preparation In-Reply-To: <47133E58.7060609@o2.pl> References: <20070811081434.GB28767@bartok.itc.it> <13204091.post@talk.nabble.com> <4713316D.6010004@o2.pl> <47133E58.7060609@o2.pl> Message-ID: [snip] > Also, the bug g.region [2] is very serious. Any chances > these 2 bugs could be fixed before relasing 6.3? It would be > much better not to release with *known* bugs which might > corrupt users data. > [2]http://wald.intevation.org/tracker/?func=detail&atid=204&aid=489&group_id=21 should be fixed in CVS... Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From tutey at o2.pl Mon Oct 15 14:14:54 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 15 14:15:05 2007 Subject: [GRASS-dev] g.region bugs [was: GRASS 6.3.0 release preparation] In-Reply-To: References: <20070811081434.GB28767@bartok.itc.it> <13204091.post@talk.nabble.com> <4713316D.6010004@o2.pl> <47133E58.7060609@o2.pl> Message-ID: <471359BE.9040106@o2.pl> Martin Landa wrote: > Maciej Sieczka wrote: >> Also, the bug g.region [2] is very serious. Any chances >> these 2 bugs could be fixed before relasing 6.3? It would be >> much better not to release with *known* bugs which might >> corrupt users data. >> >> [2]http://wald.intevation.org/tracker/?func=detail&atid=204&aid=489&group_id=21 > should be fixed in CVS... Martin Yes it is! Cool. Yet, there is some more evil lurking in g.region - when the initial resolution is different than resolution requested in a "g.region vect=line res=1 -a" call, the region is set wrong (present in both CVS GRASS 6.2 and 6.3). Eg.: 1. Set the region to something like: $ g.region n=5680980 s=5680960 w=602440 e=602480 res=20 -g n=5680980 s=5680960 w=602440 e=602480 nsres=20 ewres=20 rows=1 cols=2 2. Create a vector line within the region: $ echo "L 2 1 602473.66691719 5680962.45268225 602448.70284465 5680961.09147704 1 1" | v.in.ascii -n form=standard out=line 3. Set the region to match the extent of vector line and force resolution "1": $ g.region vect=line res=1 -ag n=5680980 s=5680960 w=602440 e=602480 nsres=1 ewres=1 rows=20 cols=40 The above g.region result is wrong. It should be: n=5680963 s=5680961 w=602448 e=602474 nsres=1 ewres=1 rows=2 cols=26 This happens when the initial region (set in point #1) is different than target resolution (requested in #3). Would you mind looking into this bug too? Best, Maciek From landa.martin at gmail.com Mon Oct 15 15:47:31 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Oct 15 15:47:35 2007 Subject: [GRASS-dev] Re: g.region bugs [was: GRASS 6.3.0 release preparation] In-Reply-To: <471359BE.9040106@o2.pl> References: <20070811081434.GB28767@bartok.itc.it> <13204091.post@talk.nabble.com> <4713316D.6010004@o2.pl> <47133E58.7060609@o2.pl> <471359BE.9040106@o2.pl> Message-ID: Hi, hm, I disabled G_aling_window(), seems to work... (in CVS) Martin 2007/10/15, Maciej Sieczka : > Martin Landa wrote: > > Maciej Sieczka wrote: > > >> Also, the bug g.region [2] is very serious. Any chances > >> these 2 bugs could be fixed before relasing 6.3? It would be > >> much better not to release with *known* bugs which might > >> corrupt users data. > >> > >> [2]http://wald.intevation.org/tracker/?func=detail&atid=204&aid=489&group_id=21 > > > should be fixed in CVS... > > Martin > > Yes it is! Cool. > > Yet, there is some more evil lurking in g.region - when the > initial resolution is different than resolution requested in > a "g.region vect=line res=1 -a" call, the region is set > wrong (present in both CVS GRASS 6.2 and 6.3). Eg.: > > 1. Set the region to something like: > > $ g.region n=5680980 s=5680960 w=602440 e=602480 res=20 -g > n=5680980 > s=5680960 > w=602440 > e=602480 > nsres=20 > ewres=20 > rows=1 > cols=2 > > 2. Create a vector line within the region: > > $ echo "L 2 1 > 602473.66691719 5680962.45268225 > 602448.70284465 5680961.09147704 > 1 1" | v.in.ascii -n form=standard out=line > > 3. Set the region to match the extent of vector line and > force resolution "1": > > $ g.region vect=line res=1 -ag > n=5680980 > s=5680960 > w=602440 > e=602480 > nsres=1 > ewres=1 > rows=20 > cols=40 > > The above g.region result is wrong. It should be: > > n=5680963 > s=5680961 > w=602448 > e=602474 > nsres=1 > ewres=1 > rows=2 > cols=26 > > This happens when the initial region (set in point #1) is > different than target resolution (requested in #3). > > Would you mind looking into this bug too? > > Best, > Maciek > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From tutey at o2.pl Mon Oct 15 16:48:12 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Oct 15 16:48:22 2007 Subject: [GRASS-dev] Re: g.region bugs [was: GRASS 6.3.0 release preparation] In-Reply-To: References: <20070811081434.GB28767@bartok.itc.it> <13204091.post@talk.nabble.com> <4713316D.6010004@o2.pl> <47133E58.7060609@o2.pl> <471359BE.9040106@o2.pl> Message-ID: <47137DAC.6090602@o2.pl> Martin Landa wrote: > hm, I disabled G_aling_window(), seems to work... (in CVS) The test case from in my last email works OK now. But, a different one still fails. A different vector line, same intial region settings as in last case: $ echo "L 2 571600 5722275 571610 5722275" | v.in.ascii -n out=line format=standard --o $ g.region n=5680980 s=5680960 w=602440 e=602480 res=20 -ag n=5680980 s=5680960 w=602440 e=602480 nsres=20 ewres=20 rows=1 cols=2 cells=2 $ g.region vect=line res=1 -ag n=5722285 s=5722265 w=571600 e=571610 nsres=1 ewres=1 rows=20 cols=10 cells=200 Wrong. Should be: n=5722276 s=5722274 w=571600 e=571610 nsres=1 ewres=1 rows=2 cols=10 cells=20 The above happens in GRASS 6.3. In 6.2 (CVS), the procedure also leads to wrong region settings, but different: $ g.region vect=line res=1 -ag n=5722300 s=5722260 w=571600 e=571620 nsres=1 ewres=1 rows=40 cols=20 It'd be great if you can solve it. Maciek From glynn at gclements.plus.com Mon Oct 15 17:28:33 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Oct 15 17:28:45 2007 Subject: [GRASS-dev] Cairo monitor driver In-Reply-To: <301480.42124.qm@web52711.mail.re2.yahoo.com> References: <18194.52254.913437.647110@cerise.gclements.plus.com> <301480.42124.qm@web52711.mail.re2.yahoo.com> Message-ID: <18195.34593.956530.577482@cerise.gclements.plus.com> Hamish wrote: > > Doing it client side can be a major performance hit. Apart from > > anything else, all of the rendering has to be done in software; your > > graphics hardware can't help. > > Even if we use the much faster PNG(PPM) driver for fast GUI rendering, it sure > would be nice to click a "quality mode" switch in the GUI to switch to the > Cairo driver to create presentation quality output. For hardcopies (or softcopy