From soerengebbert at gmx.de Sat Sep 1 00:05:39 2007 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Sat Sep 1 00:05:43 2007 Subject: [GRASS-dev] gmath BLAS/LAPACK wrapper In-Reply-To: <1188442894.12609.45.camel@dev64.localdomain> References: <20070825184528.116940@gmx.net> <1188442894.12609.45.camel@dev64.localdomain> Message-ID: <20070831220539.195550@gmx.net> Hi, -------- Original-Nachricht -------- > Datum: Thu, 30 Aug 2007 03:01:34 +0000 > Von: Brad Douglas > An: "S?ren "Gebbert\\"" > CC: grass-dev@grass.itc.it, Glynn Clements , Markus Neteler > Betreff: Re: [GRASS-dev] gmath BLAS/LAPACK wrapper > On Sat, 2007-08-25 at 20:45 +0200, "S?ren Gebbert" wrote: > > Hi Brad, Dear devs, > > i am currently working on a ATLAS - BLAS/LAPACK implementation > > within the gpde library. > > The idea is to provide full access to ATLAS BLAS level 1-3 > > functions and have multi-threaded BLAS 1-3 functions implemented in > GRASS > > as backup. I have almost finished the BLAS level 1 vector routines and > > working on > > level 2 the vector - matrix and level 3 matrix - matrix implementation. > > It took me a little bit to get back on this. I needed to ensure that > ATLAS supports all of the LAPACK functions we need (it only supports a > subset). > > We also missed each other (probably by minutes) several times on > IRC. :-) > Ill keep on trying. :) > > The grass BLAS level 1-3 implementation is of course not as fast as > > the ATLAS library. > > ATLAS is cache optimized and uses recursive functions. > > Additionally, ATLAS uses pthreads to provide multi threaded level 3 > functions. > > Sounds good to me. I'll have to look into replacing autotools > BLAS/LAPACK detection with ATLAS. It shouldn't be terribly difficult > unless we want to support all derivatives of CBLAS/CLAPACK. > > I could use a little direction there as to which way to go. Glynn? > Markus? > > > But for each specialised ATLAS function, a more general grass functions > > will exists. Eg: there are level 3 functions for quadratic, symmetric > and hermitian > > matrices in BLAS, grass will provide only one matrix-matrix function. > > If the user compiles grass without ATLAS support, all the modules > > which are using > > BLAS functions will still work ... but not that fast. ;) > > That works for me. This prevents the current caveat of "install > BLAS/LAPACK or these modules won't compile". > > Do all of the lower level functions in lib/gmath, then lib/gpde calls > the gmath function, which automatically determins which version to run > (actually, it'll be determined at compile time). Thats a good idea, i will place the lower level functions from the gpde library into the gmath library. This will include the ATLAS wrapper, the grass blas level 1-3 implementation and all the linear equation solver i have implemented. > > > I try to keep the interface as simple as i can. The vectors are 1d > > float or double arrays > > and matrices are 1d float or double arrays with additional row > > pointers (using the G_alloc_vector and > > G_alloc_matrix functions). I use the same low level implementation > > as the ATLAS interface. The user must take care of correct allocation > > and row, column counting. > > > > Additionally i will try to create a wrapper to the LAPACK solver > > provided in ATLAS. > > IMHO the gpde lu decomposition with row pivoting > > and the gpde bandwidth optimized cholesky solver are the backup routines > > for most of the LAPACK sover. > > > > The krylov space solver (cg and bicgstab) will use the ATLAS BLASS 1-2 > > functions. > > > > So the gpde interface is much more low level than the gmath LAPACK/BLAS > > wrapper. And i think we can use the gpde routines instead of the native > > lapack routines in the gmath warpper. But the matrix functions will work > > in row major order. > > If you have lower level functions, then those should be moved to > lib/gmath, IMO. Agreed. > > > The blas functions are named like the (IMHO horrible) > > netlib-blas naming convention, accept that i have put a N_ before the > name. > > Eg: > > N_cblas_ddot, N_cblas_sdot ... . > > I'd rather use G_math_ddot (), G_math_sdot ()... > > I think it'll be simpler to determine the function operation at compile > time rather than run time. Ok, i will name the blas 1 - 3 ATLAS function as you suggested. But how should i name the grass backup blas functions? Currently i dont use the blas naming convention because its to cryptic. Because the grass blas implementation is more general, i have named those functions like: N_blas1_d_xdoty() or N_blas2_d_Ax_by() and so on. So i will name it G_math_blas1_d_xdoty() .... What parts of the LAPACK functions do we need in grass currently and ion the future? Because ATLAS supports only a few of them, this is an important question i think. Best regards soeren > > > -- > 73, de Brad KB8UYR/6 -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From michael.barton at asu.edu Sat Sep 1 01:33:51 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 1 01:34:57 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: Message-ID: Paul, On 8/31/07 1:27 PM, "Paul Kelly" wrote: > Hello Michael > > On Sat, 25 Aug 2007, Michael Barton wrote: > >> Moritz, >> >> Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens. >> I just made a change, suggested by Glynn, that fixed similar symptoms for >> with with another command (v.what). v.what was kicking out extraneous >> information when it launched and creating an identical dialog. I've >> separated out stderr from the normal stdout information when commands are >> launched from the menu and it works fine now. > > As far as I can see there in that latest change you're redirecting stderr > to /dev/null. So now there will be no output for the catch command to > catch in case of an error - so printing out the error message is > pointless. In any case a popup dialog should be a better option than > printing to the terminal where the user might not notice it until later - > or in future there may not even be a terminal, e.g. in WinGRASS but maybe > we'll change that. My understanding from Glynn (perhaps wrong) is that a *real* error will actually show up and be caught by TclTk, but not non-error information sent to stderr. I agree about preferring a message box. I can't really say I was being lazy, but I wanted to get all statements caught right away, and it was a large number to go through. > > I'd suggest using the catch command something as follows (this is adapting > what's in epsg_option.tcl): > > catch {set code [exec -- $program --tcltk]} errMsg > > if {[lindex $::errorCode 0] eq "CHILDSTATUS"} { > DialogGen .wrnDlg [G_msg "Error running command!"] warning \ > [format [G_msg "%s returned the following message:\n%s"] $program > $errMsg] \ > 0 OK > } elseif {$errMsg != ""} { > DialogGen .wrnDlg [format [G_msg "Informational output from %s"] > $program] info \ > [format [G_msg "%s returned the following informational > message:\n%s"] $program $errMsg] \ > 0 OK > } > } > > DialogGen is a nice little routine in gis_set.tcl that pops up a dialog > box. There are some comments in gis_set.tcl on how to use it. I've seen it, but would probably use the native tk_messageBox. It takes about the same amount of code in the original program. I started to put this in, but the problem with the mixing of stdout and stderr for non-errors resulted in a message box that ran off the screen with extraneous output from a problematic GRASS command. So I decided that until that was fixed I'd just re-route all catch output to the terminal. And it was also faster to do all the needed catch statements that way. > > Please note that I'm not saying this is what you should do, nor that I > necessarily recommend doing it now - my original comments about catching > errors properly where really just suggestions about something that we > should look out for in the future, as I thought it would be too much work > do do it thoroughly and properly now so soon before 6.3.0 without > introducing new unexpected behaviour and so on. Understood. My time has become considerably shorter of course, and I been trying to fix some other issues. Hopefully as they get fewer, it may be possible to in a batch, go in and add some kind of dialog or messagebox for error code. It would be cleaner and more professional looking to do that. > > Possible problems with and notes about the above code: > - With the catch where it is - I'm not sure if it actually catches the > "exec" command or just the "set" command It catches the exec command in this case. The set receives any error message. > - Checking the return status of the command is better than checking the > return value of catch, because, as we've seen lots of times - Tcl will > assume an error has happened if *any* output is written to stderr - a > usage convention not shared by GRASS. I *think* this is solved by redirecting the original output to devnull > - Output issued to stderr but when the command has exited successfully > should be handled by the second block of the if statement, and popped up > for the user to read and then continue. Again, I *think* that we will now only get an error message with a real error. The user should not have to read a message and click OK if there is no error. > - To be neater and less confusing to the user, the possiblity of a command > exiting with a non-zero return code but not writing anything to stderr > should probably also be handled. I suppose that this could be dealt with by if {$error != ""} { ...create the messagebox...} Thanks again for the thoughtful comments. 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 tutey at o2.pl Sat Sep 1 12:06:49 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Sep 1 12:07:13 2007 Subject: [GRASS-dev] [grass-code I][470] i.atcorr: hardcoded input/output map names In-Reply-To: <1188466741.12609.52.camel@dev64.localdomain> References: <20070827204117.029BE40077@pyrosoma.intevation.org> <200708290016.09767.yann.chemin@gmail.com> <1188466741.12609.52.camel@dev64.localdomain> Message-ID: <46D939B9.9020003@o2.pl> Brad Douglas wrote: > I started working on this awhile ago after realizing values were > hardcoded, etc. IIRC, I didn't finish because it was becoming > complicated and I didn't have time to dedicate to it. > > I can commit what I have (and comment unfinished code) if someone > wants to have it done relatively quickly and is willing to finish it > themselves. > > Until then, I think it should probably be removed from the Makefile. I have committed the documenation clean up. Things still unclear > > > On Wed, 2007-08-29 at 00:16 +0700, Yann wrote: >> Yes, this is test data, was in testdata/ dir in the grassSVN >> Add-ons before joining CVS. >> >> Please anyone with write access may change this. Yann >> >> On Tuesday 28 August 2007 03:41:17 grass-dev@grass.itc.it wrote: >>> code I item #470, was opened at 2007-08-27 22:41 Status: Open >>> Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: >>> Nobody (None) Summary: i.atcorr: hardcoded input/output map >>> names Issue type: module bug Issue status: None GRASS version: >>> CVS HEAD GRASS component: imagery Operating system: None >>> Operating system version: GRASS CVS checkout date, if applies >>> (YYMMDD): 070827 >>> >>> >>> Initial Comment: i.atcorr has a follwoing set of map names >>> hardcoded: >>> >>> iimg=ETM4_400x400.raw ialt=dem_float ivis=visibility >>> icnd=ETM4_atmospheric_input_GRASS.txt oimg=6s_output_file >>> >>> Shouldn't have any. > > From tutey at o2.pl Sat Sep 1 12:32:01 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Sep 1 12:32:27 2007 Subject: [GRASS-dev] [grass-code I][470] i.atcorr: hardcoded input/output map names In-Reply-To: <46D939B9.9020003@o2.pl> References: <20070827204117.029BE40077@pyrosoma.intevation.org> <200708290016.09767.yann.chemin@gmail.com> <1188466741.12609.52.camel@dev64.localdomain> <46D939B9.9020003@o2.pl> Message-ID: <46D93FA1.3070000@o2.pl> Maciej Sieczka wrote: > Brad Douglas wrote: >> I started working on this awhile ago after realizing values were >> hardcoded, etc. IIRC, I didn't finish because it was becoming >> complicated and I didn't have time to dedicate to it. >> >> I can commit what I have (and comment unfinished code) if someone >> wants to have it done relatively quickly and is willing to finish it >> themselves. >> >> Until then, I think it should probably be removed from the Makefile. > I have committed the documenation clean up. Things still unclear Sorry - hit send too soon. Once again: I have committed my doc clean up. Things still unclear are in red. It would be great if someone i.attcor and 6s savvy could finish it. For now, I think that i.attcor in it's current shape should not be a part of the planned GRASS 6.3 release. However, IMHO it should enabled in the makefile for people fetching latest GRASS from CVS, so the the final cleanup could be more likely. Maciek From glynn at gclements.plus.com Sat Sep 1 19:37:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 1 19:37:15 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: References: Message-ID: <18137.41799.309478.405497@cerise.gclements.plus.com> Paul Kelly wrote: > > Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens. > > I just made a change, suggested by Glynn, that fixed similar symptoms for > > with with another command (v.what). v.what was kicking out extraneous > > information when it launched and creating an identical dialog. I've > > separated out stderr from the normal stdout information when commands are > > launched from the menu and it works fine now. > > As far as I can see there in that latest change you're redirecting stderr > to /dev/null. So now there will be no output for the catch command to > catch in case of an error - so printing out the error message is > pointless. Right. The reason for the redirect was to prevent extraneous stderr output from being treated as an error (v.what was calling R_open_driver() before the G_parser() call; with direct rendering, this caused the PNG driver startup text ("PNG: GRASS_TRUECOLOR status: ..." etc) to be written to stderr. I've fixed v.what not to do this. The map= option is now always required; it won't try to get a default from the current monitor. A few display (d.*) commands still do this, but those don't get run from the menus, so this shouldn't be an issue. This isn't an issue for wxGRASS, as Python has better subprocess management. > Possible problems with and notes about the above code: > - Output issued to stderr but when the command has exited successfully > should be handled by the second block of the if statement, and popped up > for the user to read and then continue. I'm not sure that you get that option. If the command writes to stderr, exec fails. I don't think that it's guaranteed that the command will be run to completion, so I wouldn't want to rely upon it. > - To be neater and less confusing to the user, the possiblity of a command > exiting with a non-zero return code but not writing anything to stderr > should probably also be handled. In this particular case, there are only really two possibilities: either the command's interface description was successfully retrieved, or it wasn't. It probably isn't worth trying to discern between different types of failure. -- Glynn Clements From kyngchaos at kyngchaos.com Sat Sep 1 21:09:25 2007 From: kyngchaos at kyngchaos.com (William Kyngesburye) Date: Sat Sep 1 21:09:43 2007 Subject: [GRASS-dev] OSX install path changed Message-ID: <5035938A-09F0-4AA2-8374-28AA16696E4E@kyngchaos.com> I changed the OSX app install path a bit. It was changed from 'Contents/Resources' (within the app package) to 'Contents/MacOS'. You should completely remove your installed GRASS-6.3.app before installing a new build, or the old Resources stuff will hang around, taking up space and possibly confusing GRASS. This will break external apps that link to GRASS libraries (ie Qgis). 'MacOS' is a more appropriate location for the binaries, and is what other UNIX ports do. For some reason 'Resources' made sense back when I set up the app build. A bonus is that the AppleScript startup is now completely separated from GRASS files. That is, 'MacOS/scripts' (lowercase 's') is for GRASS scripts, as it should be, and 'Resources/Scripts' (uppercase 'S') is where the AppleScript startup resides (this is hardwired in the AppleScript system). This removes the problem of running GRASS.app on a case-sensitive file system (not that anyone is likely to do that). ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From michael.barton at asu.edu Sat Sep 1 21:40:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 1 21:41:04 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <18137.41799.309478.405497@cerise.gclements.plus.com> Message-ID: On 9/1/07 10:37 AM, "Glynn Clements" wrote: > > Paul Kelly wrote: > >>> Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens. >>> I just made a change, suggested by Glynn, that fixed similar symptoms for >>> with with another command (v.what). v.what was kicking out extraneous >>> information when it launched and creating an identical dialog. I've >>> separated out stderr from the normal stdout information when commands are >>> launched from the menu and it works fine now. >> >> As far as I can see there in that latest change you're redirecting stderr >> to /dev/null. So now there will be no output for the catch command to >> catch in case of an error - so printing out the error message is >> pointless. > > Right. > Maybe this is not what you mean, but I intentionally generated an error to test this by adding a typo to the menu command to call v.what (made it "v.whats"). The error message came back as 'v.whats not found'. So it looks like this will return at least some error messages. Michael > The reason for the redirect was to prevent extraneous stderr output > from being treated as an error (v.what was calling R_open_driver() > before the G_parser() call; with direct rendering, this caused the PNG > driver startup text ("PNG: GRASS_TRUECOLOR status: ..." etc) to be > written to stderr. > > I've fixed v.what not to do this. The map= option is now always > required; it won't try to get a default from the current monitor. > > A few display (d.*) commands still do this, but those don't get run > from the menus, so this shouldn't be an issue. This isn't an issue for > wxGRASS, as Python has better subprocess management. __________________________________________ 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 Sat Sep 1 21:57:45 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 1 21:58:43 2007 Subject: [GRASS-dev] Updated error management Message-ID: I had to hang out while our carpets were being cleaned, so I went ahead and changed all error output from the terminal to TclTk message boxes. I added some explanatory text where appropriate in some cases too. All such error output is run through G_msg, so it should be possible to internationalize it. 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/20070901/4a42f047/attachment.html From glynn at gclements.plus.com Sun Sep 2 07:04:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Sep 2 07:04:34 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: References: <18137.41799.309478.405497@cerise.gclements.plus.com> Message-ID: <18138.17501.998671.635150@cerise.gclements.plus.com> Michael Barton wrote: > >>> Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens. > >>> I just made a change, suggested by Glynn, that fixed similar symptoms for > >>> with with another command (v.what). v.what was kicking out extraneous > >>> information when it launched and creating an identical dialog. I've > >>> separated out stderr from the normal stdout information when commands are > >>> launched from the menu and it works fine now. > >> > >> As far as I can see there in that latest change you're redirecting stderr > >> to /dev/null. So now there will be no output for the catch command to > >> catch in case of an error - so printing out the error message is > >> pointless. > > > > Right. > > > > Maybe this is not what you mean, but I intentionally generated an error to > test this by adding a typo to the menu command to call v.what (made it > "v.whats"). The error message came back as 'v.whats not found'. > > So it looks like this will return at least some error messages. That error is generated by Tcl itself. Errors generated by the command (or the loader, e.g. "unable to load shared library") will still be discarded. AFAICT, the only solution to that would be to redirect stderr to a file, then include its contents in the event of an error. -- Glynn Clements From maris.gis at gmail.com Sun Sep 2 10:14:36 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Sun Sep 2 10:14:41 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <18138.17501.998671.635150@cerise.gclements.plus.com> References: <18137.41799.309478.405497@cerise.gclements.plus.com> <18138.17501.998671.635150@cerise.gclements.plus.com> Message-ID: <2b3d8c1c0709020114w104ad471t3b980fda5782a8f3@mail.gmail.com> Sorry for jumping-in. I may be not following hard enough, but I just tested error catching in lib/init/file_option.tcl proc fileOpt::create_loc and it works in both cases: 1) Try to create new location from GDAL unsupported file -> outputs g.proj error; 2) Move all GDAL libs to some other place and then try to create new location -> outputs "shared library not found" error. IMHO both of them are most common errors and having reported to user in some user-friendly way is good thing. Any other common problem that should be tested? Alltough Glynns suggestion about redirecting GRASS error messages ALSO to some error.log file would be a good idea as this file could be a must for (crash) bug reporting. Only as a non-programmer I see some difficulties: 1) How multiple processes (modules) can append data to that file in sane way; 2) When enable such functionality? I.E. g.env set=ERRLOG=true 3) What else needs to be written to such file? I.E. command history, arch, GRASS version... Just my 0.02$, Maris. From paul-grass at stjohnspoint.co.uk Sun Sep 2 13:11:34 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Sep 2 13:11:40 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <2b3d8c1c0709020114w104ad471t3b980fda5782a8f3@mail.gmail.com> References: <18137.41799.309478.405497@cerise.gclements.plus.com> <18138.17501.998671.635150@cerise.gclements.plus.com> <2b3d8c1c0709020114w104ad471t3b980fda5782a8f3@mail.gmail.com> Message-ID: Hello Maris On Sun, 2 Sep 2007, Maris Nartiss wrote: > Sorry for jumping-in. > I may be not following hard enough, but I just tested error catching > in lib/init/file_option.tcl proc fileOpt::create_loc and it works in > both cases: > 1) Try to create new location from GDAL unsupported file -> outputs > g.proj error; > 2) Move all GDAL libs to some other place and then try to create new > location -> outputs "shared library not found" error. > IMHO both of them are most common errors and having reported to user > in some user-friendly way is good thing. Any other common problem that > should be tested? Yes I think it works quite well there. I copied some of what you did in file_option.tcl for my recent improvements to epsg_option.tcl. The way I see it is that because the catch function takes an optional argument - a variable to catch whatever is written to stderr - there is no need to redirect stderr to a file. In effect we use the catch command to "catch" the stderr output. DialogGen works well for popping up clear error messages with the same look and file as the rest of the GUI (in fact I changed it so the border on the OK button looks the same as the other buttons in gis_set.tcl and associated dialogs). tk_messageBox (on Windows anyway) resulted in a dialog box with a totally different look and feel and to me at least it seemed a bit inconsistent in regard to which windows it popped up in front of. I wouldn't recommend using it - I changed a couple of occurences of it in epsg_option.tcl to use DialogGen instead. Paul From paul-grass at stjohnspoint.co.uk Sun Sep 2 13:15:30 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Sep 2 13:15:35 2007 Subject: [GRASS-dev] Re: wx init.sh needs updating In-Reply-To: References: Message-ID: On Tue, 7 Aug 2007, Michael Barton wrote: > Sounds like this needs to be updated soon. I'm surprised that it doesn't > kick out an error for the native Windows version. init.sh isn't used on native Windows - that's what init.bat is for. Unless you start GRASS from an Msys shell, when you could use init.sh and indeed it used to work - I haven't tested it recently though and we've been concentrating on getting Msys-independent WinGRASS working as well as possible. Paul From paul-grass at stjohnspoint.co.uk Sun Sep 2 13:22:13 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Sep 2 13:22:24 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <1388.85.10.64.54.1188080603.squirrel@geog-pc40.ulb.ac.be> References: <98406.78280.qm@web60521.mail.yahoo.com> <18104.45127.468813.123101@cerise.gclements.plus.com> <18104.50679.830154.347160@cerise.gclements.plus.com> <1527.164.15.134.164.1187624226.squirrel@geog-pc40.ulb.ac.be> <1352.85.10.64.54.1188079494.squirrel@geog-pc40.ulb.ac.be> <1388.85.10.64.54.1188080603.squirrel@geog-pc40.ulb.ac.be> Message-ID: On Sun, 26 Aug 2007, Moritz Lennert wrote: > Maybe if someone could try my 20070825 binaries from > http://moritz.homelinux.org/grass/wingrass/ to see if the same problem > appears ? I tried them and didn't have any problems. Starting nviz from gis.m File menu, button in display window and command-line all worked fine. I unset my PATH first so it's using the libraries you have included in the distribution (I haven't compiled new ones recently anyway) and I'm still using the Activestate Tcl. I think for a proper Beta WinGRASS release we should compile our own Tcl/Tk and include that though to make it easy and reliably compatible. Paul From glynn at gclements.plus.com Sun Sep 2 13:57:50 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Sep 2 13:57:56 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <2b3d8c1c0709020114w104ad471t3b980fda5782a8f3@mail.gmail.com> References: <18137.41799.309478.405497@cerise.gclements.plus.com> <18138.17501.998671.635150@cerise.gclements.plus.com> <2b3d8c1c0709020114w104ad471t3b980fda5782a8f3@mail.gmail.com> Message-ID: <18138.42302.921253.184918@cerise.gclements.plus.com> Maris Nartiss wrote: > Alltough Glynns suggestion about redirecting GRASS error messages ALSO > to some error.log file would be a good idea as this file could be a > must for (crash) bug reporting. Only as a non-programmer I see some > difficulties: > 1) How multiple processes (modules) can append data to that file in sane way; > 2) When enable such functionality? I.E. g.env set=ERRLOG=true > 3) What else needs to be written to such file? I.E. command history, > arch, GRASS version... I wasn't talking about writing to a "log" file, but a temporary file which would be used for a single command. The problem is that Tcl's "exec" command considers it an error if a subprocess writes anything to stderr. However, a number of modules write warnings or even just informational messages to stderr as well as writing machine-readable output to stdout. There are several possibilities, all of which have drawbacks: 1. If stderr isn't redirected, any warnings or messages will cause the command to fail. 2. If stderr redirected to /dev/null (or nul: on Windows), actual error messages which could identify the cause of the problem will be lost. 3. Merging stderr with stdout isn't an option if stdout is to be passed to another program which is expecting data in a particular format. 4. If stderr is redirected to gis.m's stderr (typically the terminal), messages may be ignored if the user doesn't normally use the terminal. Also, this requires that gis.m actually has a stderr, which isn't necessarily the case if gis.m is launched via the desktop (e.g. the "Start Menu" etc). 5. Redirecting stderr to a file then reading it afterwards requires additional code. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Sun Sep 2 14:28:40 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Sep 2 14:28:43 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <18138.42302.921253.184918@cerise.gclements.plus.com> References: <18137.41799.309478.405497@cerise.gclements.plus.com> <18138.17501.998671.635150@cerise.gclements.plus.com> <2b3d8c1c0709020114w104ad471t3b980fda5782a8f3@mail.gmail.com> <18138.42302.921253.184918@cerise.gclements.plus.com> Message-ID: On Sun, 2 Sep 2007, Glynn Clements wrote: > > Maris Nartiss wrote: > >> Alltough Glynns suggestion about redirecting GRASS error messages ALSO >> to some error.log file would be a good idea as this file could be a >> must for (crash) bug reporting. Only as a non-programmer I see some >> difficulties: >> 1) How multiple processes (modules) can append data to that file in sane way; >> 2) When enable such functionality? I.E. g.env set=ERRLOG=true >> 3) What else needs to be written to such file? I.E. command history, >> arch, GRASS version... > > I wasn't talking about writing to a "log" file, but a temporary file > which would be used for a single command. > > The problem is that Tcl's "exec" command considers it an error if a > subprocess writes anything to stderr. However, a number of modules That's true - however the error-detecting code in file_option.tcl doesn't use the return value of catch to determine whether an error has occured or not - instead it checks the global variable errorcode to see if the command just run has exited with an error or not. e.g. something like this: catch {exec g.proj -c georef=$filepath location=$fileLocation} errMsg if {[lindex $::errorCode 0] eq "CHILDSTATUS"} { # Pop-up error dialog here. It seems to work well but perhaps mightn't cover all eventualities? Paul From michael.barton at asu.edu Sun Sep 2 17:24:41 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 2 17:25:47 2007 Subject: [GRASS-dev] Re: wx init.sh needs updating In-Reply-To: Message-ID: This has been a very important effort. I'm teaching my graduate spatial technologies class in the Spring and for the first time, I'll be able to use GRASS as the primary software for this on all platforms. Michael On 9/2/07 4:15 AM, "Paul Kelly" wrote: > On Tue, 7 Aug 2007, Michael Barton wrote: > >> Sounds like this needs to be updated soon. I'm surprised that it doesn't >> kick out an error for the native Windows version. > > init.sh isn't used on native Windows - that's what init.bat is for. Unless > you start GRASS from an Msys shell, when you could use init.sh and indeed > it used to work - I haven't tested it recently though and we've been > concentrating on getting Msys-independent WinGRASS working as well as > possible. > > Paul __________________________________________ 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 Sun Sep 2 20:43:44 2007 From: Michael.Barton at asu.edu (Michael Barton) Date: Sun Sep 2 20:47:36 2007 Subject: [GRASS-dev] another not quiet GRASS command Message-ID: I'm trying to use g.mapset in the georectifier module for wxgrass. I have to switch back and forth between locations and mapsets. For TclTk, I used g.gisenv, but thought it would be more convenient to use g.mapset here. BUT, I've hit the perennial problem of a GRASS command that won't be quiet. Regardless of the --q switch, g.mapset insists on dumping a warning to stderr. g.mapset mapset=PERMANENT location=Spearfish60_test --q WARNING: Your shell continues to use the history for the old mapset. This causes cmd.Command (wxgrass command processor using subprocess.Popen) to report an error when there isn't one. (Martin, this seems to be a general issue with cmd.Command. Is there a way to work around this for commands that insist on dumping extraneous stuff to stderr?) This might be a useful warning for command line users to get. But for scripting, I don?t want to see ANY warnings or other extraneous output. It does nothing except lock up scripts that don't make special arrangements to parse such stuff. This is a real problem for TclTk, leaving us with the necessity of sending all stderr to dev/null so that we only get back error messages sent by TclTk. Even for languages like wxPython that can separate stderr from stdout, it means that attempts to gracefully trap and display errors will incorrectly show an error when something like this happens. It would make life so much easier for scripting if we could optionally turn off ALL returned message except stdout for commands that are supposed to return a value and stderr for real errors. 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 mlennert at club.worldonline.be Sun Sep 2 21:54:25 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sun Sep 2 21:54:31 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: References: <98406.78280.qm@web60521.mail.yahoo.com> <18104.45127.468813.123101@cerise.gclements.plus.com> <18104.50679.830154.347160@cerise.gclements.plus.com> <1527.164.15.134.164.1187624226.squirrel@geog-pc40.ulb.ac.be> <1352.85.10.64.54.1188079494.squirrel@geog-pc40.ulb.ac.be> <1388.85.10.64.54.1188080603.squirrel@geog-pc40.ulb.ac.be> Message-ID: <1673.85.10.70.150.1188762865.squirrel@geog-pc40.ulb.ac.be> On Sun, September 2, 2007 13:22, Paul Kelly wrote: > On Sun, 26 Aug 2007, Moritz Lennert wrote: > >> Maybe if someone could try my 20070825 binaries from >> http://moritz.homelinux.org/grass/wingrass/ to see if the same problem >> appears ? > > I tried them and didn't have any problems. Starting nviz from gis.m File > menu, button in display window and command-line all worked fine. I just recompiled and everything works fine as well. No idea where the problem came from... > I think for a proper Beta WinGRASS release we > should compile our own Tcl/Tk and include that though to make it easy and > reliably compatible. Yes, sounds like a good idea in order to have one "installer" that includes everything. Moritz From michael.barton at asu.edu Mon Sep 3 06:26:12 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 06:26:27 2007 Subject: [GRASS-dev] script output for g.list Message-ID: Awhile ago, I think g.mlist output was changed so that it sent out a single list of maps or other GIS elements rather than a multicolumn list. Is there a way to add a flag to g.list so that it can produce output in the same way? As it is, the output of g.list cannot easily be parsed within a script because of it's multicolumn output. If the output could be a nice, clean single list, it *would* be parsable. Within a script, g.list is preferable over g.mlist for finding all relevant files in a mapset because it seems considerably faster. 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/20070902/f8975364/attachment-0001.html From grass-dev at grass.itc.it Mon Sep 3 07:50:58 2007 From: grass-dev at grass.itc.it (Juana Irving) Date: Mon Sep 3 07:58:09 2007 Subject: [GRASS-dev] Re: Message-ID: <01c7edef$64f39480$dbd5d751@grass-dev> New pharmacy shop: http://kcoam.solveparticular.com/?714277367215 From michael.barton at asu.edu Mon Sep 3 08:57:06 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 08:57:25 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: Message-ID: I just put in a large number of error message boxes instead of routing errors to the terminal. In general, it has generally seemed like a better idea to use a built in TclTk tool like tk_messageBox if one was available, than to use a custom function that we have to maintain to do the same thing. In the x11 version I use on my Mac, I kind of like the looks of tk_messageBox better than DialogGen, but that's just a matter of personal opinion. But I don't have a sense of what the difference between the two is on Windows and would always like to have a better looking interface. It might be nice to have error reporting have a consistent look across the entire program--either DialogGen or tk_messageBox. And if there is a general preference to the custom function (DialogGen) I don't feel that strongly about it either way--as long as someone else wants to change over the 130+ of tk_messageBox dialogs I just installed ;-). On a different error trap note...anyone have a feel for whether it's worthwhile to use this check for all error traps? if {[lindex $::errorCode 0] eq "CHILDSTATUS"} { if it returns better information, it might be worth the effort. Cheers Michael On 9/2/07 4:11 AM, "Paul Kelly" wrote: > Hello Maris > > On Sun, 2 Sep 2007, Maris Nartiss wrote: > >> Sorry for jumping-in. >> I may be not following hard enough, but I just tested error catching >> in lib/init/file_option.tcl proc fileOpt::create_loc and it works in >> both cases: >> 1) Try to create new location from GDAL unsupported file -> outputs >> g.proj error; >> 2) Move all GDAL libs to some other place and then try to create new >> location -> outputs "shared library not found" error. >> IMHO both of them are most common errors and having reported to user >> in some user-friendly way is good thing. Any other common problem that >> should be tested? > > Yes I think it works quite well there. I copied some of what you did in > file_option.tcl for my recent improvements to epsg_option.tcl. The way I > see it is that because the catch function takes an optional argument - a > variable to catch whatever is written to stderr - there is no need to > redirect stderr to a file. In effect we use the catch command to "catch" > the stderr output. > > DialogGen works well for popping up clear error messages with the same > look and file as the rest of the GUI (in fact I changed it so the border > on the OK button looks the same as the other buttons in gis_set.tcl and > associated dialogs). tk_messageBox (on Windows anyway) resulted in a > dialog box with a totally different look and feel and to me at least it > seemed a bit inconsistent in regard to which windows it popped up in front > of. I wouldn't recommend using it - I changed a couple of occurences of it > in epsg_option.tcl to use DialogGen instead. > > Paul > > __________________________________________ 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 maris.gis at gmail.com Mon Sep 3 11:38:31 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Mon Sep 3 11:38:34 2007 Subject: [GRASS-dev] GRASS6.3 on Windows In-Reply-To: References: Message-ID: <2b3d8c1c0709030238w3a39ef44ldefd30a30470d7a8@mail.gmail.com> Hi, when I wrote additional error trapping for GRASS startup screen I used DialogGen as it was already used there. Now maybe it's time to ask - why DialogGen instead of plain tk_messageBox? Is there some reason why startup screen uses DialoGen and not tk native widgets? Probably we should get rid of DialogGen popups in startup screen too. About errorCode You can read more in TCL/Tk docs: http://www.tcl.tk/man/tcl8.4/TclCmd/tclvars.htm#M18 Just my 0.02, Maris. 2007/9/3, Michael Barton : > I just put in a large number of error message boxes instead of routing > errors to the terminal. > > In general, it has generally seemed like a better idea to use a built in > TclTk tool like tk_messageBox if one was available, than to use a custom > function that we have to maintain to do the same thing. In the x11 version I > use on my Mac, I kind of like the looks of tk_messageBox better than > DialogGen, but that's just a matter of personal opinion. > > But I don't have a sense of what the difference between the two is on > Windows and would always like to have a better looking interface. It might > be nice to have error reporting have a consistent look across the entire > program--either DialogGen or tk_messageBox. And if there is a general > preference to the custom function (DialogGen) I don't feel that strongly > about it either way--as long as someone else wants to change over the 130+ > of tk_messageBox dialogs I just installed ;-). > > On a different error trap note...anyone have a feel for whether it's > worthwhile to use this check for all error traps? > > if {[lindex $::errorCode 0] eq "CHILDSTATUS"} { > > if it returns better information, it might be worth the effort. > > Cheers > Michael > From hamish_nospam at yahoo.com Mon Sep 3 12:58:41 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 3 12:58:55 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: References: Message-ID: <20070903225841.75bfa7f3.hamish_nospam@yahoo.com> Michael Barton wrote: > I'm trying to use g.mapset in the georectifier module for wxgrass. I > have to switch back and forth between locations and mapsets. For TclTk, > I used g.gisenv, but thought it would be more convenient to use > g.mapset here. > > BUT, I've hit the perennial problem of a GRASS command that won't be > quiet. Regardless of the --q switch, g.mapset insists on dumping a > warning to stderr. > > g.mapset mapset=PERMANENT location=Spearfish60_test --q > WARNING: Your shell continues to use the history for the old mapset. > > This causes cmd.Command (wxgrass command processor using > subprocess.Popen) to report an error when there isn't one. .. > This might be a useful warning for command line users to get. But for > scripting, I don?t want to see ANY warnings or other extraneous output. Warnings and fatal error messages are not affected by --quiet by design; they are not optional and need to be passed on to the user. With any module you can and will get warnings or fatal error messages, and any GUI wrapper will need to deal with them somehow. In the above case of georect.tcl, we may ask 1) if switching between mapsets in the script is really the best solution; 2) if that warning should be a warning. One might argue that in this case it should use G_important_message(), not G_warning(), but the warning message reads quite well IMO. G_important_message("WARNING: ..."); ? Seems kinda circuitous to me. > It does nothing except lock up scripts that don't make special > arrangements to parse such stuff. Because the calling wrapper is deficient, not the concept of warnings and error messages. All scripts must make special arrangements to parse such stuff. This can be aided by a wrapper fn, in the same way as the Tcl GUI menu has different 'spawn' module launchers. The cure is to fix the wrapper -- not hide the errors. It is fundamentally wrong to assume that anything written to stderr automatically means a problem is fatal, and the GUI code needs to be written with that in mind, even if it is a pain. > It would make life so much easier for scripting if we could optionally > turn off ALL returned message except stdout for commands that are > supposed to return a value and stderr for real errors. Warnings and fatal errors are "real errors". I guess one problem lies in the concept of the warning. Is it a warning that the user is sailing in dangerous waters? or is it a warning that the binary executable module did something unexpected, but non-fatal? (I'd argue both are needed). Is it a line item to be logged in GIS_ERROR_LOG or a console? or is it a standalone pop-up GUI message? (I'd argue that the GUI needs a console). Note in the C API there is G_suppress_warnings() (in lib/gis/error.c), /*! * \fn int G_suppress_warnings (int flag) * * \brief Suppress printing a warning message to stderr * * \param[in] flag a warning message will be suppressed if non-zero value is given * \return previous flag */ Use that at your own peril, it is likely that it will accidentally cause more trouble than it solves. ... so instead of lots of open and catch statements, I'd suggest that any call to a module be done using a standard wrapping function, and that standard wrapping function take care of robust open/close & error handling, once & correctly. I don't think there's another good way. Duplicating robust error handling for all external calls is wasted duplicated effort and as you point out, a pain. Hamish From hamish_nospam at yahoo.com Mon Sep 3 13:46:56 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 3 13:47:02 2007 Subject: [GRASS-dev] [grass-code I][470] i.atcorr: hardcoded input/output map names In-Reply-To: <46D93FA1.3070000@o2.pl> References: <20070827204117.029BE40077@pyrosoma.intevation.org> <200708290016.09767.yann.chemin@gmail.com> <1188466741.12609.52.camel@dev64.localdomain> <46D939B9.9020003@o2.pl> <46D93FA1.3070000@o2.pl> Message-ID: <20070903234656.bc91de7d.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > I think that i.attcor in it's current shape should not be a part > of the planned GRASS 6.3 release. Note the 6.3.0 release will be a development preview, not a stable release. Thus it shouldn't be a shock to folks if a few things don't work as expected, as we are clearly labeling that it is only beta-ware. While it reflects badly on the project when users find things that don't work, I don't think we should make huge efforts to make 6.3.0 perfect, better to spend that energy fixing problems directly in CVS. In CVS terms, 6.3.0 will be a tag not a branch. (AFAIU) As for i.attcor, it's easy enough to change the Makefile before tagging 6.3.0, then back afterwards if that is the general consensus. I express no opinion on the module as I've never used it. Hamish From landa.martin at gmail.com Mon Sep 3 15:40:31 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Sep 3 15:40:35 2007 Subject: [GRASS-dev] Re: another not quiet GRASS command In-Reply-To: References: Message-ID: Hi Michael, 2007/9/2, Michael Barton : > g.mapset mapset=PERMANENT location=Spearfish60_test --q > WARNING: Your shell continues to use the history for the old mapset. > > This causes cmd.Command (wxgrass command processor using subprocess.Popen) > to report an error when there isn't one. mapset = "PERMANENT" location = "spearfish60" mapsetCmd = cmd.Command(['g.mapset', 'mapset=%s' % mapset, 'location=%s' % location, '--q']) print "%d" % mapsetCmd.returncode # 0 success # 1 failure ? Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Mon Sep 3 16:11:06 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 3 16:11:14 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: References: Message-ID: <18140.5626.224323.508059@cerise.gclements.plus.com> Michael Barton wrote: > I just put in a large number of error message boxes instead of routing > errors to the terminal. > > In general, it has generally seemed like a better idea to use a built in > TclTk tool like tk_messageBox if one was available, than to use a custom > function that we have to maintain to do the same thing. In the x11 version I > use on my Mac, I kind of like the looks of tk_messageBox better than > DialogGen, but that's just a matter of personal opinion. > > But I don't have a sense of what the difference between the two is on > Windows and would always like to have a better looking interface. It might > be nice to have error reporting have a consistent look across the entire > program--either DialogGen or tk_messageBox. And if there is a general > preference to the custom function (DialogGen) I don't feel that strongly > about it either way--as long as someone else wants to change over the 130+ > of tk_messageBox dialogs I just installed ;-). If you find yourself typing 130+ instances of near-identical code, that should be a clue that you should add some more infrastrcture. For a start, if you add: proc errorBox {msg} { tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg } you would be able to replace e.g.: tk_messageBox -type ok -icon error -title [G_msg "Error"] \ -message [G_msg "Error creating tempfile: $error"] (of which I see at least 102 occurrences) with just: errorBox [G_msg "Error creating tempfile: $error"] [ BTW, this usage of G_msg is probably incorrect, as the entire message, including $error, will be used as the key. It should probably be: errorBox "[G_msg {Error creating tempfile}]: $error" or even: errorBox "[G_msg {Error creating tempfile}]: [G_msg $error]" so that "Error creating tempfile" and the error message will be translated independently. This means that you only need A+B translations instead of A*B. The second G_msg is only necessary if Tcl/Tk error messages aren't already localised by Tcl/Tk. Note that the situation is different with C, where "%s" is included literally in the message key. In Tcl, $error will be substituted before the message is translated. ] Beyond that, the common error-trapping idioms for exec can be incorporated into functions, e.g. (untested): proc execNoError {cmd args} { if {[catch {set result [eval exec [list $cmd] $args]} result]} { tk_messageBox -type ok -icon error -title [G_msg "Error"] -message [G_msg $result] # force the caller to return uplevel 1 return } return $result } This would allow simple cases to avoid explicit error handling altogether. -- Glynn Clements From glynn at gclements.plus.com Mon Sep 3 16:22:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 3 16:22:53 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <20070903225841.75bfa7f3.hamish_nospam@yahoo.com> References: <20070903225841.75bfa7f3.hamish_nospam@yahoo.com> Message-ID: <18140.6329.381498.777074@cerise.gclements.plus.com> Hamish wrote: > In the above case of georect.tcl, we may ask 1) if switching between > mapsets in the script is really the best solution; 2) if that warning > should be a warning. 3) If g.mapset is the right way to switch mapsets, or whether gis.m should generate a temporary GISRC and "set env(GISRC) $tmp_gisrc". If you're going to modify the existing $GISRC with g.mapset, the user had better not be running GRASS commands on the terminal in the meantime. -- Glynn Clements From mlennert at club.worldonline.be Mon Sep 3 17:38:23 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Sep 3 17:38:27 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try Message-ID: <46DC2A6F.2050102@club.worldonline.be> Benjamin wrote: >> So, how are we going to go ahead? > Glynn answered: > Figure out how to debug the processes. If you can't get gdb to work, I > can only suggest logging every significant event at the lowest level, > i.e. log every read/write operation: the arguments, the return code, > and the complete data (i.e. the buffer contents before read and after > write). This is all done in the RPC/XDR library, in xdr_stdio.c. It > will probably help to also log the beginning/end of each procedure > call (i.e. lib/db/dbmi_base/xdrprocedure.c). I would really like this to be solved, so I am willing to try to find some time to do the logging effort. Benjamin, have you advanced on this ? I will need some time understanding the xdr logic and code, but hope to be able to help with this. Moritz From tutey at o2.pl Mon Sep 3 18:40:38 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Sep 3 18:41:02 2007 Subject: [GRASS-dev] [grass-code I][470] i.atcorr: hardcoded input/output map names In-Reply-To: <20070903234656.bc91de7d.hamish_nospam@yahoo.com> References: <20070827204117.029BE40077@pyrosoma.intevation.org> <200708290016.09767.yann.chemin@gmail.com> <1188466741.12609.52.camel@dev64.localdomain> <46D939B9.9020003@o2.pl> <46D93FA1.3070000@o2.pl> <20070903234656.bc91de7d.hamish_nospam@yahoo.com> Message-ID: <46DC3906.2010902@o2.pl> Hamish wrote: > Maciej Sieczka wrote: >> I think that i.attcor in it's current shape should not be a part >> of the planned GRASS 6.3 release. > Note the 6.3.0 release will be a development preview, not a stable > release. > > Thus it shouldn't be a shock to folks if a few things don't work as > expected, as we are clearly labeling that it is only beta-ware. OK. You are right. Maciek From michael.barton at asu.edu Mon Sep 3 18:52:50 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 18:53:07 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <20070903225841.75bfa7f3.hamish_nospam@yahoo.com> Message-ID: The problem in this and other cases is that the warning is sent to stderr when the command operates and exits properly. Error messages are sent to stderr when the command does not operate properly and/or exits with an error. There is no easy way (maybe no way in many cases) for a script to tell the difference. The result is that an "error" is generated both when the command operates correctly AND incorrectly. The choice is to display an error message every time the command runs (ranging from annoying to incapacitating) OR to send them off to devnull limbo where a user will rarely if ever see a REAL error message. While admitedly useful for command line use, an informational message (i.e., not a value returned) that is sent by a module when it operates correctly is completely pointless in a scripting context. When the message is sent to the output channel that is also used to inform users about a real error, it is a problem too. Why can't quiet mean quiet since it is an option? Or can there be a 'super quiet' that really means quiet? For scripting purposes, the ideal behavior of a module would be to 1) return a value in an easily parsable form (e.g., key=val\nkey=val\n...) when asked to do so, 2) return a clear and easily understandable error message that could help a user/developer when an error occurs; and 3) completely silently go about its business in all other circumstances. Michael On 9/3/07 3:58 AM, "Hamish" wrote: > Michael Barton wrote: >> I'm trying to use g.mapset in the georectifier module for wxgrass. I >> have to switch back and forth between locations and mapsets. For TclTk, >> I used g.gisenv, but thought it would be more convenient to use >> g.mapset here. >> >> BUT, I've hit the perennial problem of a GRASS command that won't be >> quiet. Regardless of the --q switch, g.mapset insists on dumping a >> warning to stderr. >> >> g.mapset mapset=PERMANENT location=Spearfish60_test --q >> WARNING: Your shell continues to use the history for the old mapset. >> >> This causes cmd.Command (wxgrass command processor using >> subprocess.Popen) to report an error when there isn't one. > .. >> This might be a useful warning for command line users to get. But for >> scripting, I don?t want to see ANY warnings or other extraneous output. > > Warnings and fatal error messages are not affected by --quiet by design; > they are not optional and need to be passed on to the user. > > With any module you can and will get warnings or fatal error messages, > and any GUI wrapper will need to deal with them somehow. > > In the above case of georect.tcl, we may ask 1) if switching between > mapsets in the script is really the best solution; 2) if that warning > should be a warning. One might argue that in this case it should use > G_important_message(), not G_warning(), but the warning message reads > quite well IMO. G_important_message("WARNING: ..."); ? Seems kinda > circuitous to me. > >> It does nothing except lock up scripts that don't make special >> arrangements to parse such stuff. > > Because the calling wrapper is deficient, not the concept of warnings and > error messages. All scripts must make special arrangements to parse > such stuff. This can be aided by a wrapper fn, in the same way as the Tcl > GUI menu has different 'spawn' module launchers. The cure is to fix the > wrapper -- not hide the errors. It is fundamentally wrong to assume that > anything written to stderr automatically means a problem is fatal, and > the GUI code needs to be written with that in mind, even if it is a pain. > >> It would make life so much easier for scripting if we could optionally >> turn off ALL returned message except stdout for commands that are >> supposed to return a value and stderr for real errors. > > Warnings and fatal errors are "real errors". I guess one problem lies in > the concept of the warning. Is it a warning that the user is sailing in > dangerous waters? or is it a warning that the binary executable module > did something unexpected, but non-fatal? (I'd argue both are needed). Is > it a line item to be logged in GIS_ERROR_LOG or a console? or is it a > standalone pop-up GUI message? (I'd argue that the GUI needs a console). > > > > Note in the C API there is G_suppress_warnings() (in lib/gis/error.c), > /*! > * \fn int G_suppress_warnings (int flag) > * > * \brief Suppress printing a warning message to stderr > * > * \param[in] flag a warning message will be suppressed if non-zero value > is given > * \return previous flag > */ > > Use that at your own peril, it is likely that it will accidentally cause > more trouble than it solves. > > > ... so instead of lots of open and catch statements, I'd suggest that any > call to a module be done using a standard wrapping function, and that > standard wrapping function take care of robust open/close & error > handling, once & correctly. I don't think there's another good way. > Duplicating robust error handling for all external calls is wasted > duplicated effort and as you point out, a pain. > > > 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 michael.barton at asu.edu Mon Sep 3 19:01:45 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 19:02:25 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <18140.6329.381498.777074@cerise.gclements.plus.com> Message-ID: On 9/3/07 7:22 AM, "Glynn Clements" wrote: > > Hamish wrote: > >> In the above case of georect.tcl, we may ask 1) if switching between >> mapsets in the script is really the best solution; 2) if that warning >> should be a warning. > > 3) If g.mapset is the right way to switch mapsets, or whether gis.m > should generate a temporary GISRC and "set env(GISRC) $tmp_gisrc". > > If you're going to modify the existing $GISRC with g.mapset, the user > had better not be running GRASS commands on the terminal in the > meantime. Because of the way GRASS works, it is necessary to switch between mapsets. i.e., a display command will only work with the current environment and an accessible mapset. Any operation that changes something (e.g., i.group) will only work in the current mapset. However, with more experimentation, it looks like g.mapset won't work as a way to do this. I've had to revert to using g.gisenv set=LOCATION_NAME=[xy_location]. 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 michael.barton at asu.edu Mon Sep 3 19:19:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 19:20:14 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <20070903225841.75bfa7f3.hamish_nospam@yahoo.com> Message-ID: On 9/3/07 3:58 AM, "Hamish" wrote: >> It does nothing except lock up scripts that don't make special >> arrangements to parse such stuff. > > Because the calling wrapper is deficient, not the concept of warnings and > error messages. All scripts must make special arrangements to parse > such stuff. This can be aided by a wrapper fn, in the same way as the Tcl > GUI menu has different 'spawn' module launchers. The cure is to fix the > wrapper -- not hide the errors. It is fundamentally wrong to assume that > anything written to stderr automatically means a problem is fatal, and > the GUI code needs to be written with that in mind, even if it is a pain. > >> It would make life so much easier for scripting if we could optionally >> turn off ALL returned message except stdout for commands that are >> supposed to return a value and stderr for real errors. > > Warnings and fatal errors are "real errors". I guess one problem lies in > the concept of the warning. Is it a warning that the user is sailing in > dangerous waters? or is it a warning that the binary executable module > did something unexpected, but non-fatal? (I'd argue both are needed). Is > it a line item to be logged in GIS_ERROR_LOG or a console? or is it a > standalone pop-up GUI message? (I'd argue that the GUI needs a console). The GUI has a console. Errors were being routed to the console, but overall it is a better user experience to have real errors showing up in GUI-appropriate message boxes than expect a user to search for it in a terminal or other console. This also doesn't solve all problems of warnings being mistaken for real errors. > > > > Note in the C API there is G_suppress_warnings() (in lib/gis/error.c), > /*! > * \fn int G_suppress_warnings (int flag) > * > * \brief Suppress printing a warning message to stderr > * > * \param[in] flag a warning message will be suppressed if non-zero value > is given > * \return previous flag > */ > > Use that at your own peril, it is likely that it will accidentally cause > more trouble than it solves. I don't disagree with these concepts. However, the difference is between a message that is returned when a module operates as designed (regardless of whether a user might be venturing into dangerous territory or not) or does not operated as designed. When buried inside a complex script that chains together multiple commands, something that causes a module to NOT operate as designed (an error to me at least) can result in unexpected or undesired behavior or crash the whole script. This needs to be reported 'outside' the script so that the user can learn what is going wrong 'inside'. But when the module is working as designed, sending a message is pointless. If it is a message that triggers an error trap that requires the user to press an OK button the message itself can bring down the whole script. > > > ... so instead of lots of open and catch statements, I'd suggest that any > call to a module be done using a standard wrapping function, and that > standard wrapping function take care of robust open/close & error > handling, once & correctly. I don't think there's another good way. > Duplicating robust error handling for all external calls is wasted > duplicated effort and as you point out, a pain. I definitely agree. This is what has been done with wxgrass. Martin created a cmd.Command function that will execute a GRASS command using subprocess.Popen and do a lot of this housekeeping. It doesn't completely get rid of the need to individually trap potential errors with the try function, but it helps a lot. However, this STILL hits the same problem with warnings. Since they come in through stderr, they apparently produce a non-zero return value for Popen. This triggers the error management routines--as it should--raising a message box that says g.mapset failed when it in fact did not. 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 michael.barton at asu.edu Mon Sep 3 19:27:54 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 19:28:15 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: <18140.5626.224323.508059@cerise.gclements.plus.com> Message-ID: On 9/3/07 7:11 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I just put in a large number of error message boxes instead of routing >> errors to the terminal. >> >> In general, it has generally seemed like a better idea to use a built in >> TclTk tool like tk_messageBox if one was available, than to use a custom >> function that we have to maintain to do the same thing. In the x11 version I >> use on my Mac, I kind of like the looks of tk_messageBox better than >> DialogGen, but that's just a matter of personal opinion. >> >> But I don't have a sense of what the difference between the two is on >> Windows and would always like to have a better looking interface. It might >> be nice to have error reporting have a consistent look across the entire >> program--either DialogGen or tk_messageBox. And if there is a general >> preference to the custom function (DialogGen) I don't feel that strongly >> about it either way--as long as someone else wants to change over the 130+ >> of tk_messageBox dialogs I just installed ;-). > > If you find yourself typing 130+ instances of near-identical code, > that should be a clue that you should add some more infrastrcture. > > For a start, if you add: > > proc errorBox {msg} { > tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg > } > > you would be able to replace e.g.: > > tk_messageBox -type ok -icon error -title [G_msg "Error"] \ > -message [G_msg "Error creating tempfile: $error"] > > (of which I see at least 102 occurrences) with just: > > errorBox [G_msg "Error creating tempfile: $error"] Agreed that this reduces the number of characters in the code. But it isn't much different timewise for cutting and pasting. It would make it easier to globally format all error messages in the future. > > [ > BTW, this usage of G_msg is probably incorrect, as the entire message, > including $error, will be used as the key. It should probably be: > > errorBox "[G_msg {Error creating tempfile}]: $error" > > or even: > > errorBox "[G_msg {Error creating tempfile}]: [G_msg $error]" > > so that "Error creating tempfile" and the error message will be > translated independently. This means that you only need A+B > translations instead of A*B. The second G_msg is only necessary if > Tcl/Tk error messages aren't already localised by Tcl/Tk. > > Note that the situation is different with C, where "%s" is included > literally in the message key. In Tcl, $error will be substituted > before the message is translated. > ] This is important to know for internationalization. Probably worth going back and redoing. An error function probably wouldn't have made this any easier unfortunately. > > Beyond that, the common error-trapping idioms for exec can be > incorporated into functions, e.g. (untested): > > proc execNoError {cmd args} { > if {[catch {set result [eval exec [list $cmd] $args]} result]} { > tk_messageBox -type ok -icon error -title [G_msg "Error"] -message [G_msg > $result] > # force the caller to return > uplevel 1 return > } > return $result > } > > This would allow simple cases to avoid explicit error handling > altogether. In retrospect, it would have been better to have a single command processing function that used arguments or flags to merge the multiple ones now in the TclTk GUI (run, run_ui, execute, ...) and handle error trapping at the same time--as per Hamish' comments in a related thread and as we're doing with cmd.Command in wxgrass. It's quite a bit of work to go back and fix this in TclTk. If we were keeping the TclTk GUI into the future, it would definitely be worth the effort. I'm not sure it is now, given that we're switching to wxPython. 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 glynn at gclements.plus.com Mon Sep 3 21:21:09 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 3 21:21:22 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: References: <18140.6329.381498.777074@cerise.gclements.plus.com> Message-ID: <18140.24229.765470.221583@cerise.gclements.plus.com> Michael Barton wrote: > >> In the above case of georect.tcl, we may ask 1) if switching between > >> mapsets in the script is really the best solution; 2) if that warning > >> should be a warning. > > > > 3) If g.mapset is the right way to switch mapsets, or whether gis.m > > should generate a temporary GISRC and "set env(GISRC) $tmp_gisrc". > > > > If you're going to modify the existing $GISRC with g.mapset, the user > > had better not be running GRASS commands on the terminal in the > > meantime. > > Because of the way GRASS works, it is necessary to switch between mapsets. > i.e., a display command will only work with the current environment and an > accessible mapset. Any operation that changes something (e.g., i.group) will > only work in the current mapset. > > However, with more experimentation, it looks like g.mapset won't work as a > way to do this. I've had to revert to using g.gisenv > set=LOCATION_NAME=[xy_location]. I'm not questioning whether it's necessary to switch mapsets. I'm questioning whether modifying the existing $GISRC is the right approach, or whether gis.m should create a new $GISRC solely for use by the georectifier. Personally, I'd suggest the latter. In general, global state (e.g. $GISRC, WIND) is undesirable. For command-line use, it's a necessary compromise, as having to manually specify database/location/mapset (and others, e.g. monitor and database) for each command would be a major nuisance. A GUI doesn't have this problem; it can maintain its own state. Moreover, it can maintain as many different states as it wishes, and use the appropriate one for each individual command. See also: past discussions of $WIND_OVERRIDE and $GRASS_REGION vs the WIND file. -- Glynn Clements From michael.barton at asu.edu Mon Sep 3 21:23:47 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 21:24:02 2007 Subject: [GRASS-dev] GRASS6.3 on Windows In-Reply-To: <2b3d8c1c0709030238w3a39ef44ldefd30a30470d7a8@mail.gmail.com> Message-ID: I think that DialogGen was written a long time ago, before tk_messageBox existed. Michael On 9/3/07 2:38 AM, "Maris Nartiss" wrote: > Hi, > > when I wrote additional error trapping for GRASS startup screen I used > DialogGen as it was already used there. Now maybe it's time to ask - > why DialogGen instead of plain tk_messageBox? Is there some reason why > startup screen uses DialoGen and not tk native widgets? Probably we > should get rid of DialogGen popups in startup screen too. > > About errorCode You can read more in TCL/Tk docs: > http://www.tcl.tk/man/tcl8.4/TclCmd/tclvars.htm#M18 > > Just my 0.02, > Maris. > > 2007/9/3, Michael Barton : >> I just put in a large number of error message boxes instead of routing >> errors to the terminal. >> >> In general, it has generally seemed like a better idea to use a built in >> TclTk tool like tk_messageBox if one was available, than to use a custom >> function that we have to maintain to do the same thing. In the x11 version I >> use on my Mac, I kind of like the looks of tk_messageBox better than >> DialogGen, but that's just a matter of personal opinion. >> >> But I don't have a sense of what the difference between the two is on >> Windows and would always like to have a better looking interface. It might >> be nice to have error reporting have a consistent look across the entire >> program--either DialogGen or tk_messageBox. And if there is a general >> preference to the custom function (DialogGen) I don't feel that strongly >> about it either way--as long as someone else wants to change over the 130+ >> of tk_messageBox dialogs I just installed ;-). >> >> On a different error trap note...anyone have a feel for whether it's >> worthwhile to use this check for all error traps? >> >> if {[lindex $::errorCode 0] eq "CHILDSTATUS"} { >> >> if it returns better information, it might be worth the effort. >> >> Cheers >> 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 glynn at gclements.plus.com Mon Sep 3 21:36:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 3 21:36:34 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: References: Message-ID: <18140.25130.972820.275027@cerise.gclements.plus.com> Michael Barton wrote: > I'm trying to use g.mapset in the georectifier module for wxgrass. I have to > switch back and forth between locations and mapsets. For TclTk, I used > g.gisenv, but thought it would be more convenient to use g.mapset here. > > BUT, I've hit the perennial problem of a GRASS command that won't be quiet. > Regardless of the --q switch, g.mapset insists on dumping a warning to > stderr. > > g.mapset mapset=PERMANENT location=Spearfish60_test --q > WARNING: Your shell continues to use the history for the old mapset. > > This causes cmd.Command (wxgrass command processor using subprocess.Popen) > to report an error when there isn't one. > > (Martin, this seems to be a general issue with cmd.Command. Is there a way > to work around this for commands that insist on dumping extraneous stuff to > stderr?) If cmd.Command considers writing to stderr to constitute an error, that's a bug in cmd.Command. That behaviour of Tcl's "exec" is a significant design flaw; it should not be intentionally replicated by wxGRASS. > This might be a useful warning for command line users to get. But for > scripting, I don?t want to see ANY warnings or other extraneous output. Many of the warnings which commands generate are quite important, and shouldn't be hidden for the sake of convenience. The g.mapset warning is of debatable usefulness (in general; it's entirely meaningless for the GUI), but there are plenty of others which are useful. > It does nothing except lock up scripts that don't make special arrangements to > parse such stuff. Scripts should not be attempting to parse stderr. The only reasonable ways to handle stderr output are: 1. Show it to the user. 2. Log it to a file. 3. Discard it, or otherwise ignore it. > This is a real problem for TclTk, leaving us with the > necessity of sending all stderr to dev/null so that we only get back error > messages sent by TclTk. That's a deficiency of Tcl's process management primitives ("primitive" being the operative term). > Even for languages like wxPython that can separate > stderr from stdout, it means that attempts to gracefully trap and display > errors will incorrectly show an error when something like this happens. Only if the code mimic's Tcl's bogus concept of what constitutes an error (i.e. stderr output). Writing to stderr is *not* an error. Returning a non-zero exit code is an error. > It > would make life so much easier for scripting if we could optionally turn off > ALL returned message except stdout for commands that are supposed to return > a value and stderr for real errors. That isn't going to happen. Apart from the amount of work involved in modifying GRASS, many library functions can write warnings (and other messages) to stderr, and don't necessarily provide any mechanism to control whether this happens, or even to detect that it has happened. In general terms, stderr is a mechanism for programs to communicate arbitrary information to the *user*. Programs should not get involved with reading stderr unless they are doing so in order to act as a "common carrier" between the program and the user (i.e. to simply pass the information along). -- Glynn Clements From michael.barton at asu.edu Mon Sep 3 21:38:55 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 21:42:43 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <18140.24229.765470.221583@cerise.gclements.plus.com> Message-ID: On 9/3/07 12:21 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>> In the above case of georect.tcl, we may ask 1) if switching between >>>> mapsets in the script is really the best solution; 2) if that warning >>>> should be a warning. >>> >>> 3) If g.mapset is the right way to switch mapsets, or whether gis.m >>> should generate a temporary GISRC and "set env(GISRC) $tmp_gisrc". >>> >>> If you're going to modify the existing $GISRC with g.mapset, the user >>> had better not be running GRASS commands on the terminal in the >>> meantime. >> >> Because of the way GRASS works, it is necessary to switch between mapsets. >> i.e., a display command will only work with the current environment and an >> accessible mapset. Any operation that changes something (e.g., i.group) will >> only work in the current mapset. >> >> However, with more experimentation, it looks like g.mapset won't work as a >> way to do this. I've had to revert to using g.gisenv >> set=LOCATION_NAME=[xy_location]. > > I'm not questioning whether it's necessary to switch mapsets. I'm > questioning whether modifying the existing $GISRC is the right > approach, or whether gis.m should create a new $GISRC solely for use > by the georectifier. > > Personally, I'd suggest the latter. OK. I see what you're getting at now. I'm not sure how to accomplish it. The active GISRC is a tempfile ( /tmp/grass6-cmbarton-6824/gisrc on my machine). Will simply creating a new temporary file with different values for LOCATION_NAME and MAPSET have the effect of 'switching' to a different working location/mapset? If so, how to get the current GRASS session to recognize this? Does it even have to be a text file on disk somewhere or can it simply be set to a variable (e.g., Python data object) with the appropriate values? Can I just make a minimal GISRC with only location and mapset, or is it safer to copy whatever is in the currently active one and then modify location and mapset. My active one currently contains... DIGITIZER: none GISDBASE: /Users/Shared/grassdata GRASS_DB_ENCODING: utf-8 GRASS_ADDON_PATH: /Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/gm/script MONITOR: x0 LOCATION_NAME: xy MAPSET: test GRASS_RENDER_IMMEDIATE: TRUE GRASS_GUI: wx Michael > > In general, global state (e.g. $GISRC, WIND) is undesirable. For > command-line use, it's a necessary compromise, as having to manually > specify database/location/mapset (and others, e.g. monitor and > database) for each command would be a major nuisance. > > A GUI doesn't have this problem; it can maintain its own state. > Moreover, it can maintain as many different states as it wishes, and > use the appropriate one for each individual command. > > See also: past discussions of $WIND_OVERRIDE and $GRASS_REGION vs the > WIND file. __________________________________________ 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 Sep 3 21:52:21 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 3 21:53:03 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <18140.25130.972820.275027@cerise.gclements.plus.com> Message-ID: So what is *supposed* to happen in a scripting environment is... 1) non-zero exit code returned 2) show whatever is in stderr to the user OR 1) 0 exit code returned 2) do not report with whatever is in stderr (not because it is unimportant, but because it is not an error) Correct? If so, then there may be a bug somewhere in cmd.Comand since it is showing non-meaningful error messages sometimes when the command operates fine. An aside: g.mapset treats as an error (It says "ERROR", so I assume that it generates a non-zero exit code) a situation where the location and mapset are the current location and mapset. IMHO, this should not be an error. I guess it could be a "warning", but the module is operating correctly in that it is 'changing' to the location and mapset specified; these just happen to be the current one. Michael On 9/3/07 12:36 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I'm trying to use g.mapset in the georectifier module for wxgrass. I have to >> switch back and forth between locations and mapsets. For TclTk, I used >> g.gisenv, but thought it would be more convenient to use g.mapset here. >> >> BUT, I've hit the perennial problem of a GRASS command that won't be quiet. >> Regardless of the --q switch, g.mapset insists on dumping a warning to >> stderr. >> >> g.mapset mapset=PERMANENT location=Spearfish60_test --q >> WARNING: Your shell continues to use the history for the old mapset. >> >> This causes cmd.Command (wxgrass command processor using subprocess.Popen) >> to report an error when there isn't one. >> >> (Martin, this seems to be a general issue with cmd.Command. Is there a way >> to work around this for commands that insist on dumping extraneous stuff to >> stderr?) > > If cmd.Command considers writing to stderr to constitute an error, > that's a bug in cmd.Command. > > That behaviour of Tcl's "exec" is a significant design flaw; it should > not be intentionally replicated by wxGRASS. > >> This might be a useful warning for command line users to get. But for >> scripting, I don?t want to see ANY warnings or other extraneous output. > > Many of the warnings which commands generate are quite important, and > shouldn't be hidden for the sake of convenience. > > The g.mapset warning is of debatable usefulness (in general; it's > entirely meaningless for the GUI), but there are plenty of others > which are useful. > >> It does nothing except lock up scripts that don't make special arrangements >> to >> parse such stuff. > > Scripts should not be attempting to parse stderr. The only reasonable > ways to handle stderr output are: > > 1. Show it to the user. > 2. Log it to a file. > 3. Discard it, or otherwise ignore it. > >> This is a real problem for TclTk, leaving us with the >> necessity of sending all stderr to dev/null so that we only get back error >> messages sent by TclTk. > > That's a deficiency of Tcl's process management primitives > ("primitive" being the operative term). > >> Even for languages like wxPython that can separate >> stderr from stdout, it means that attempts to gracefully trap and display >> errors will incorrectly show an error when something like this happens. > > Only if the code mimic's Tcl's bogus concept of what constitutes an > error (i.e. stderr output). > > Writing to stderr is *not* an error. Returning a non-zero exit code is > an error. > >> It >> would make life so much easier for scripting if we could optionally turn off >> ALL returned message except stdout for commands that are supposed to return >> a value and stderr for real errors. > > That isn't going to happen. > > Apart from the amount of work involved in modifying GRASS, many > library functions can write warnings (and other messages) to stderr, > and don't necessarily provide any mechanism to control whether this > happens, or even to detect that it has happened. > > In general terms, stderr is a mechanism for programs to communicate > arbitrary information to the *user*. Programs should not get involved > with reading stderr unless they are doing so in order to act as a > "common carrier" between the program and the user (i.e. to simply pass > the information along). __________________________________________ 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 Mon Sep 3 22:24:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 3 22:25:15 2007 Subject: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows In-Reply-To: References: <18140.5626.224323.508059@cerise.gclements.plus.com> Message-ID: <18140.28052.752634.966709@cerise.gclements.plus.com> Michael Barton wrote: > > If you find yourself typing 130+ instances of near-identical code, > > that should be a clue that you should add some more infrastrcture. > > > > For a start, if you add: > > > > proc errorBox {msg} { > > tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg > > } > > > > you would be able to replace e.g.: > > > > tk_messageBox -type ok -icon error -title [G_msg "Error"] \ > > -message [G_msg "Error creating tempfile: $error"] > > > > (of which I see at least 102 occurrences) with just: > > > > errorBox [G_msg "Error creating tempfile: $error"] > > Agreed that this reduces the number of characters in the code. But it isn't > much different timewise for cutting and pasting. It would make it easier to > globally format all error messages in the future. It isn't about the time required to enter the code in the first place. It's about being able to subsequently change the behaviour for all instances by modifying a single function rather than 100+ copies. IOW: abstraction. Keep the details of error handling in one place (or a few places), and have the individual instances simply request that an error be handled. Beyond that, it's not uncommon for large projects to have substantial hierarchies of "stub" functions for common operations, simply to categorise the flows. E.g.: void handle_file_read_error(const char *msg) { handle_file_error(msg); } void handle_file_write_error(const char *msg) { handle_file_error(msg); } void handle_file_error(const char *msg) { handle_io_error(msg); } void handle_io_error(const char *msg) { handle_error(msg); } void handle_error(const char *msg) { /* the real work is done here */ } As it stands, this offers no advantage over either calling handle_error() directly or, at the other extreme, simply inlining the error handling. But in practice, code seldom gets written then left untouched for the rest of its days. When it comes to making changes, the above structure means that you can change the handling of a particular category of cases without being limited to a choice of either modifying handle_error() (and affecting every case), or having to manually modify individual occurrences. > > Beyond that, the common error-trapping idioms for exec can be > > incorporated into functions, e.g. (untested): > > > > proc execNoError {cmd args} { > > if {[catch {set result [eval exec [list $cmd] $args]} result]} { > > tk_messageBox -type ok -icon error -title [G_msg "Error"] -message [G_msg > > $result] > > # force the caller to return > > uplevel 1 return > > } > > return $result > > } > > > > This would allow simple cases to avoid explicit error handling > > altogether. > > In retrospect, it would have been better to have a single command processing > function that used arguments or flags to merge the multiple ones now in the > TclTk GUI (run, run_ui, execute, ...) and handle error trapping at the same > time--as per Hamish' comments in a related thread and as we're doing with > cmd.Command in wxgrass. This is an area where a hierarchy similar to the above would be applicable. A single level (one function called directly from throughout the code) won't suffice. Even without the "term" case (legacy programs requiring an xterm), you probably need one case for display commands, one for "normal" computational commands run from the menus, one for obtaining the interface description with --tcltk, etc. At the lowest level, you would have one command, either with a lot of options or which is little more than "exec" itself. For any additional steps which it might perform, there is probably some case where you would want to avoid that. To handle that, you either provide options to enable/disable the additional functionality, or have multiple higher-level functions which provide the additional functionality, or some combination of the two. Specific cases either use the appropriate set of options or call the appropriate higher-level version. E.g. for display commands, you probably wouldn't want errors to reported through dialogs. If the user sets an option which causes most display commands to fail, they won't want to have to individually acknowledge a dozen error dialogs before they can correct the problem. [Remember when web browsers would pop up an error dialog whenever an error occurred? The current behaviour of reporting the problem in the frame is a lot less annoying.] -- Glynn Clements From mlennert at club.worldonline.be Mon Sep 3 22:33:50 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Sep 3 22:33:55 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <46DC2A6F.2050102@club.worldonline.be> References: <46DC2A6F.2050102@club.worldonline.be> Message-ID: <1364.85.10.66.145.1188851630.squirrel@geog-pc40.ulb.ac.be> On Mon, September 3, 2007 17:38, Moritz Lennert wrote: > Benjamin wrote: > > >> So, how are we going to go ahead? > > > > Glynn answered: > > > Figure out how to debug the processes. If you can't get gdb to work, I > > can only suggest logging every significant event at the lowest level, > > i.e. log every read/write operation: the arguments, the return code, > > and the complete data (i.e. the buffer contents before read and after > > write). This is all done in the RPC/XDR library, in xdr_stdio.c. It > > will probably help to also log the beginning/end of each procedure > > call (i.e. lib/db/dbmi_base/xdrprocedure.c). > > I would really like this to be solved, so I am willing to try to find > some time to do the logging effort. Benjamin, have you advanced on this ? > > I will need some time understanding the xdr logic and code, but hope to > be able to help with this. > Ok, very first simple debugging effort seems to confirm timin issue. Here's what I did: diff -u dbmi_base dbmi_base_debug/ Common subdirectories: dbmi_base/CVS and dbmi_base_debug/CVS Only in dbmi_base_debug/: OBJ.i686-pc-mingw32 diff -u dbmi_base/xdrint.c dbmi_base_debug/xdrint.c --- dbmi_base/xdrint.c Thu Oct 5 06:13:28 2006 +++ dbmi_base_debug/xdrint.c Mon Sep 3 20:17:35 2007 @@ -10,10 +10,12 @@ stat = DB_OK; + G_debug(1, "xdrint.c: Begin send"); xdr_begin_send (&xdrs); if(!xdr_int (&xdrs, &n)) stat = DB_PROTOCOL_ERR; xdr_end_send (&xdrs); + G_debug(1, "xdrint.c: End send"); if (stat == DB_PROTOCOL_ERR) db_protocol_error(); diff -u dbmi_base/xdrprocedure.c dbmi_base_debug/xdrprocedure.c --- dbmi_base/xdrprocedure.c Thu Oct 5 06:13:28 2006 +++ dbmi_base_debug/xdrprocedure.c Mon Sep 3 20:17:35 2007 @@ -40,10 +40,12 @@ stat = DB_OK; + G_debug(1, "xdrprocedure.c: Begin receive"); xdr_begin_recv (&xdrs); if(!xdr_int (&xdrs, n)) stat = DB_EOF; xdr_end_recv (&xdrs); + G_debug(1, "xdrprocedure.c: End receive"); return stat; } and now, after setting 'g.gisenv set=DEBUG=1', I cannot reproduce the deadlock anymore, using Benjamin's test data, except when I do other things on the machine (open other windows, type an email, etc). When I just run the command and stare at the screen I get no deadlock. With DEBUG=0 I get the same irregular deadlock. I'll dig into xdrstdio.c now. Moritz From hamish_nospam at yahoo.com Tue Sep 4 04:00:53 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 4 04:00:59 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: References: <18140.25130.972820.275027@cerise.gclements.plus.com> Message-ID: <20070904140053.8f9dfe7a.hamish_nospam@yahoo.com> Michael Barton wrote: > An aside: g.mapset treats as an error (It says "ERROR", so I assume > that it generates a non-zero exit code) it does: general/g.mapset/main.c /* TODO: this should be checked better (repeated '/' etc.) */ if ( strcmp(mapset_old_path, mapset_new_path) == 0 ) G_fatal_error ( _("%s is already the current mapset"), mapset_new ); > a situation where the location and mapset are the current location and > mapset. IMHO, this should not be an error. I guess it could be a > "warning", but the module is operating correctly in that it is > 'changing' to the location and mapset specified; these just happen to > be the current one. when the rectifying target is the current mapset, can you test for that and just not run g.mapset at all? The fewer times g.mapset needs to be called the better.. Hamish From michael.barton at asu.edu Tue Sep 4 04:36:05 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 4 04:36:21 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <20070904140053.8f9dfe7a.hamish_nospam@yahoo.com> Message-ID: On 9/3/07 7:00 PM, "Hamish" wrote: > > when the rectifying target is the current mapset, can you test for that > and just not run g.mapset at all? The fewer times g.mapset needs to be > called the better.. > I can test for this, but it's easier and cleaner to just make the change to whatever the user wants. For the georectifier, this is moot now, since g.mapset won't work. But I guess you could consider it a general question/suggestion. It doesn't seem to be an error if g.mapset does what it is supposed to and simply stays in the current location/mapset because that is what the user instructed it to do. FWIW, here is what is going on with g.mapset (error/warning reporting aside). There is a custom selection tool that uses g.mapsets -p and g.mlist (I'd prefer g.list, but need to have it output a simple, single column list) to create a pull-down combo box with a hierarchical list of selectable maps within each accessible mapset. However, in spite of calling g.mapset before repopulating the combo box list of values, it only shows maps in the old location/mapset. I don't know whether this is a function of the object-oriented nature of Python (initial instantiation of the control is somehow locked into the GISRC values that it is called with) or something about the GRASS modules. I suspect the latter, however, because when I use g.gisenv to reset location and mapset it all works fine. Glynn is suggesting creating a temporary GISRC file for all this. I'm not yet sure how to go about this, but it should be pretty easy to plug in since the location/mapset switch routines are all within a method that is called as needed. Thanks for the comments and thoughts 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 landa.martin at gmail.com Tue Sep 4 11:37:54 2007 From: landa.martin at gmail.com (Martin Landa) Date: Tue Sep 4 11:37:58 2007 Subject: [GRASS-dev] script output for g.list In-Reply-To: References: Message-ID: Hi Michael, I tried to modify g.list. Instead of G_list_element(), the patch call G_list() and G_ls_format() . Patch attached (not committed to CVS). E.g. $ g.list rast ---------------------------------------------- raster files available in mapset : asp ---------------------------------------------- raster files available in mapset : aspect elevation.dem fields landuse roads soil.br.depth soils.ph strm.dist trn.sites bugsites elevation.dted geology owner rstrct.areas soils soils.range texture uparea density erode.index landcover.30m quads rushmore soils.Kfactor spot.image tractids vegcover elevation.10m erosion1 landcover.orig railroads slope soils.Tfactor streams transport.misc $ g.list rast --q asp aspect bugsites density elevation.10m elevation.dem elevation.dted erode.index erosion1 fields geology landcover.30m landcover.orig landuse owner quads railroads roads rstrct.areas rushmore slope soil.br.depth soils soils.Kfactor soils.Tfactor soils.ph soils.range spot.image streams strm.dist texture tractids transport.misc trn.sites uparea vegcover Martin 2007/9/3, Michael Barton : > > Awhile ago, I think g.mlist output was changed so that it sent out a single > list of maps or other GIS elements rather than a multicolumn list. Is there > a way to add a flag to g.list so that it can produce output in the same way? > > As it is, the output of g.list cannot easily be parsed within a script > because of it's multicolumn output. If the output could be a nice, clean > single list, it *would* be parsable. Within a script, g.list is preferable > over g.mlist for finding all relevant files in a mapset because it seems > considerably faster. > > 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 > > > _______________________________________________ > 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 * -------------- next part -------------- A non-text attachment was scrubbed... Name: g-list-vq.diff.gz Type: application/x-gzip Size: 1975 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070904/c0b116a3/g-list-vq.diff.gz From paul-grass at stjohnspoint.co.uk Mon Sep 3 19:06:26 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Sep 4 11:40:49 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: References: Message-ID: On Mon, 3 Sep 2007, Michael Barton wrote: > The problem in this and other cases is that the warning is sent to stderr > when the command operates and exits properly. Error messages are sent to > stderr when the command does not operate properly and/or exits with an > error. There is no easy way (maybe no way in many cases) for a script to > tell the difference. I think Tcl's deficiencies are confusing you. Tcl cannot tell the difference and this is IMHO a major bug in Tcl. But it is a single exception. Operating systems and probably almost all other scripting languages use the exit code of the program: a zero exit code indicates it exited successfully; a non-zero exit code indicates it exited with an error. In any case Maris seems to have found a workaround to Tcl's deficiency: check the global variable errorcode after running an external command. I'm waiting to see if anybody comes up with a problem with this approach. From neteler at itc.it Tue Sep 4 12:18:17 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Sep 4 12:18:20 2007 Subject: [GRASS-dev] script output for g.list In-Reply-To: References: Message-ID: <46DD30E9.9070005@itc.it> Martin Landa wrote on 09/04/2007 11:37 AM: > Hi Michael, > > I tried to modify g.list. Instead of G_list_element(), the patch call > G_list() and G_ls_format() . > > ... > $ g.list rast --q > asp > aspect > bugsites > density > ... Hi Martin, wouldn't it be more sensitive to use '-g' instead? Also in combination with -f for the titles? Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From glynn at gclements.plus.com Tue Sep 4 12:32:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 4 12:32:52 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: References: <18140.24229.765470.221583@cerise.gclements.plus.com> Message-ID: <18141.13391.884328.120773@cerise.gclements.plus.com> Michael Barton wrote: > > I'm not questioning whether it's necessary to switch mapsets. I'm > > questioning whether modifying the existing $GISRC is the right > > approach, or whether gis.m should create a new $GISRC solely for use > > by the georectifier. > > > > Personally, I'd suggest the latter. > > OK. I see what you're getting at now. I'm not sure how to accomplish it. > > The active GISRC is a tempfile ( /tmp/grass6-cmbarton-6824/gisrc on my > machine). > > Will simply creating a new temporary file with different values for > LOCATION_NAME and MAPSET have the effect of 'switching' to a different > working location/mapset? You also need to change $GISRC to refer to the new file. > If so, how to get the current GRASS session to > recognize this? You don't want the "current GRASS session" to recognise it. What you want is for the commands run from the georectifier (and nothing else) to recognise it. In gis.m, "set env(GISRC) $tmp_gisrc" before calling such commands, then set it back afterwards. In Python, change GISRC in the environment passed to Popen() for such commands, e.g.: env = os.environ.copy() env["GISRC"] = tmp_gisrc child = subprocess.Popen(cmd, env = env, ...) > Does it even have to be a text file on disk somewhere or can it simply be > set to a variable (e.g., Python data object) with the appropriate values? It needs to be a text file. > Can I just make a minimal GISRC with only location and mapset, or is it > safer to copy whatever is in the currently active one and then modify > location and mapset. I suggest the latter. If creating a new one, you need at least GISDBASE, LOCATION_NAME and MAPSET for all commands. The others should be optional. > My active one currently contains... > > DIGITIZER: none > GISDBASE: /Users/Shared/grassdata > GRASS_DB_ENCODING: utf-8 > GRASS_ADDON_PATH: /Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/gm/script > MONITOR: x0 > LOCATION_NAME: xy > MAPSET: test > GRASS_RENDER_IMMEDIATE: TRUE > GRASS_GUI: wx [I don't know how the GRASS_RENDER_IMMEDIATE setting got there; that's an environment variable.] I have: GISDBASE: /opt/grass-data LOCATION_NAME: spearfish57 MAPSET: glynn GRASS_DB_ENCODING: ascii GRASS_GUI: text GRASS_DB_ENCODING is only used by the form library. GRASS_GUI is used to remember the -text/-gui/etc setting between sessions and to determine whether --ui uses Tcl/Tk or wxPython. Neither of these are relevant for non-interactive commands. -- Glynn Clements From glynn at gclements.plus.com Tue Sep 4 12:48:22 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 4 12:48:28 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: References: <18140.25130.972820.275027@cerise.gclements.plus.com> Message-ID: <18141.14326.444532.256423@cerise.gclements.plus.com> Michael Barton wrote: > So what is *supposed* to happen in a scripting environment is... > > 1) non-zero exit code returned > 2) show whatever is in stderr to the user > > OR > > 1) 0 exit code returned > 2) do not report with whatever is in stderr (not because it is unimportant, > but because it is not an error) > > Correct? A GUI for GRASS should generally show everything written to both stderr and stdout (unless explicitly redirected) to the user, regardless of whether or not the command succeeds. IOW, you need a log window. If a command succeeds but generates warnings, the user should be aware of those warnings. It's not uncommon for a command to be able to produce results yet have doubts as to whether the result is what the user actually wanted. In the case of of a non-zero exit code, the output from stderr is likely to be useful as part of any error message. If you're going to display an error in a message box, the stderr output may be useful. > If so, then there may be a bug somewhere in cmd.Comand since it is showing > non-meaningful error messages sometimes when the command operates fine. It isn't beyond the bounds of possibility that some commands return incorrect exit codes. In particular, if a script completes by reaching EOF (rather than using "exit"), its exit code will be that of the last command, which doesn't necessarily reflect the success or failure of the script as a whole. [Also, some commands have a notion of failure which isn't limited to errors. E.g. "grep" fails if nothing matches; 0 => match(es) found, 1 => no matches found, 2 => actual error (file not found, etc).] > An aside: g.mapset treats as an error (It says "ERROR", so I assume that it > generates a non-zero exit code) a situation where the location and mapset > are the current location and mapset. IMHO, this should not be an error. Agreed. > I guess it could be a "warning", but the module is operating correctly in that > it is 'changing' to the location and mapset specified; these just happen to > be the current one. This is similar to the discussions over whether g.remove "fails" if the entity (map etc) doesn't exist. For comparison, "rm" fails if the specified file doesn't exist whereas "rm -f" doesn't (it fails if the file exists but cannot be removed, e.g. due to permissions). -- Glynn Clements From michael.barton at asu.edu Tue Sep 4 17:13:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 4 17:13:59 2007 Subject: [GRASS-dev] script output for g.list In-Reply-To: Message-ID: Thanks very much Martin. Not knowing C, I'm not exactly sure what to do with this, but will try to work with it if no one else gets to it first. I'm not sure I'd hang the different format on the --q flag. Maybe a -l (for listing?) flag would be better. Once this is worked out and in the cvs, I'll put it into select.py. I don't know if you've had a chance to look, but I added a class to allow select to be called in a separate dialog and a method that lets you update the element list after you've created a selection control. Michael On 9/4/07 2:37 AM, "Martin Landa" wrote: > Hi Michael, > > I tried to modify g.list. Instead of G_list_element(), the patch call > G_list() and G_ls_format() . > > Patch attached (not committed to CVS). > > E.g. > > $ g.list rast > ---------------------------------------------- > raster files available in mapset : > asp > ---------------------------------------------- > raster files available in mapset : > aspect elevation.dem fields landuse roads > soil.br.depth soils.ph strm.dist trn.sites > bugsites elevation.dted geology owner > rstrct.areas soils soils.range texture uparea > density erode.index landcover.30m quads > rushmore soils.Kfactor spot.image tractids > vegcover > elevation.10m erosion1 landcover.orig railroads slope > soils.Tfactor streams transport.misc > > $ g.list rast --q > asp > aspect > bugsites > density > elevation.10m > elevation.dem > elevation.dted > erode.index > erosion1 > fields > geology > landcover.30m > landcover.orig > landuse > owner > quads > railroads > roads > rstrct.areas > rushmore > slope > soil.br.depth > soils > soils.Kfactor > soils.Tfactor > soils.ph > soils.range > spot.image > streams > strm.dist > texture > tractids > transport.misc > trn.sites > uparea > vegcover > > Martin > > 2007/9/3, Michael Barton : >> >> Awhile ago, I think g.mlist output was changed so that it sent out a single >> list of maps or other GIS elements rather than a multicolumn list. Is there >> a way to add a flag to g.list so that it can produce output in the same way? >> >> As it is, the output of g.list cannot easily be parsed within a script >> because of it's multicolumn output. If the output could be a nice, clean >> single list, it *would* be parsable. Within a script, g.list is preferable >> over g.mlist for finding all relevant files in a mapset because it seems >> considerably faster. >> >> 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 >> >> >> _______________________________________________ >> 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 michael.barton at asu.edu Tue Sep 4 17:19:15 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 4 17:24:21 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <18141.13391.884328.120773@cerise.gclements.plus.com> Message-ID: Thanks much for the explanation. I'll try this out with the wxPython georectifier I'm working on now. Michael On 9/4/07 3:32 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>> I'm not questioning whether it's necessary to switch mapsets. I'm >>> questioning whether modifying the existing $GISRC is the right >>> approach, or whether gis.m should create a new $GISRC solely for use >>> by the georectifier. >>> >>> Personally, I'd suggest the latter. >> >> OK. I see what you're getting at now. I'm not sure how to accomplish it. >> >> The active GISRC is a tempfile ( /tmp/grass6-cmbarton-6824/gisrc on my >> machine). >> >> Will simply creating a new temporary file with different values for >> LOCATION_NAME and MAPSET have the effect of 'switching' to a different >> working location/mapset? > > You also need to change $GISRC to refer to the new file. > >> If so, how to get the current GRASS session to >> recognize this? > > You don't want the "current GRASS session" to recognise it. What you > want is for the commands run from the georectifier (and nothing else) > to recognise it. > > In gis.m, "set env(GISRC) $tmp_gisrc" before calling such commands, > then set it back afterwards. > > In Python, change GISRC in the environment passed to Popen() for such > commands, e.g.: > > env = os.environ.copy() > env["GISRC"] = tmp_gisrc > child = subprocess.Popen(cmd, env = env, ...) > >> Does it even have to be a text file on disk somewhere or can it simply be >> set to a variable (e.g., Python data object) with the appropriate values? > > It needs to be a text file. > >> Can I just make a minimal GISRC with only location and mapset, or is it >> safer to copy whatever is in the currently active one and then modify >> location and mapset. > > I suggest the latter. If creating a new one, you need at least > GISDBASE, LOCATION_NAME and MAPSET for all commands. The others should > be optional. > >> My active one currently contains... >> >> DIGITIZER: none >> GISDBASE: /Users/Shared/grassdata >> GRASS_DB_ENCODING: utf-8 >> GRASS_ADDON_PATH: >> /Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/gm/script >> MONITOR: x0 >> LOCATION_NAME: xy >> MAPSET: test >> GRASS_RENDER_IMMEDIATE: TRUE >> GRASS_GUI: wx > > [I don't know how the GRASS_RENDER_IMMEDIATE setting got there; that's > an environment variable.] > > I have: > > GISDBASE: /opt/grass-data > LOCATION_NAME: spearfish57 > MAPSET: glynn > GRASS_DB_ENCODING: ascii > GRASS_GUI: text > > GRASS_DB_ENCODING is only used by the form library. GRASS_GUI is used > to remember the -text/-gui/etc setting between sessions and to > determine whether --ui uses Tcl/Tk or wxPython. Neither of these are > relevant for non-interactive commands. __________________________________________ 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 Sep 4 17:25:00 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 4 17:28:34 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: <18141.14326.444532.256423@cerise.gclements.plus.com> Message-ID: Thanks for the clarification. Hopefully NOW I understand how this is SUPPOSED to work. It will be particularly helpful with wxPython. At least now I know to check for an incorrect exit code if gcmd.Command doesn't work as expected. It is also not producing useful error messages. Perhaps it is not parsing stderror correctly. Michael On 9/4/07 3:48 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> So what is *supposed* to happen in a scripting environment is... >> >> 1) non-zero exit code returned >> 2) show whatever is in stderr to the user >> >> OR >> >> 1) 0 exit code returned >> 2) do not report with whatever is in stderr (not because it is unimportant, >> but because it is not an error) >> >> Correct? > > A GUI for GRASS should generally show everything written to both > stderr and stdout (unless explicitly redirected) to the user, > regardless of whether or not the command succeeds. IOW, you need a log > window. > > If a command succeeds but generates warnings, the user should be aware > of those warnings. It's not uncommon for a command to be able to > produce results yet have doubts as to whether the result is what the > user actually wanted. > > In the case of of a non-zero exit code, the output from stderr is > likely to be useful as part of any error message. If you're going to > display an error in a message box, the stderr output may be useful. > >> If so, then there may be a bug somewhere in cmd.Comand since it is showing >> non-meaningful error messages sometimes when the command operates fine. > > It isn't beyond the bounds of possibility that some commands return > incorrect exit codes. > > In particular, if a script completes by reaching EOF (rather than > using "exit"), its exit code will be that of the last command, which > doesn't necessarily reflect the success or failure of the script as a > whole. > > [Also, some commands have a notion of failure which isn't limited to > errors. E.g. "grep" fails if nothing matches; 0 => match(es) found, > 1 => no matches found, 2 => actual error (file not found, etc).] > >> An aside: g.mapset treats as an error (It says "ERROR", so I assume that it >> generates a non-zero exit code) a situation where the location and mapset >> are the current location and mapset. IMHO, this should not be an error. > > Agreed. > >> I guess it could be a "warning", but the module is operating correctly in >> that >> it is 'changing' to the location and mapset specified; these just happen to >> be the current one. > > This is similar to the discussions over whether g.remove "fails" if > the entity (map etc) doesn't exist. For comparison, "rm" fails if the > specified file doesn't exist whereas "rm -f" doesn't (it fails if the > file exists but cannot be removed, e.g. due to permissions). __________________________________________ 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 woklist at kyngchaos.com Tue Sep 4 17:34:27 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Sep 4 17:34:45 2007 Subject: [GRASS-dev] r.in.wms and wget Message-ID: With no offers of help on my request a while back, I decided to give it a go: http://wald.intevation.org/tracker/? func=detail&aid=380&group_id=21&atid=188 I think I figured out the equivalent curl command. Does anyone know of a WMS server I could try importing a small raster from to test it? ----- 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 neteler at itc.it Tue Sep 4 17:42:41 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Sep 4 17:42:44 2007 Subject: [GRASS-dev] r.in.wms and wget In-Reply-To: References: Message-ID: <20070904154241.GB23200@bartok.itc.it> On Tue, Sep 04, 2007 at 10:34:27AM -0500, William Kyngesburye wrote: > With no offers of help on my request a while back, I decided to give it a > go: > > http://wald.intevation.org/tracker/?func=detail&aid=380&group_id=21&atid=188 > > I think I figured out the equivalent curl command. Does anyone know of a > WMS server I could try importing a small raster from to test it? You can use the GRASS User Mapserver: http://grass.itc.it/community/index.php -> WFS GetCapabilities URL - WMS GetCapabilities URL Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From woklist at kyngchaos.com Tue Sep 4 17:48:31 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Sep 4 17:49:00 2007 Subject: [GRASS-dev] Add addon menu files to Tcl GUI menu? Message-ID: <5BF0E8B6-B1A5-4E6F-A487-0C33D6FE4B00@kyngchaos.com> Something that got pushed back in my head, I'd like to get this in the 6.3 release. I have the OSX app startup generating tcl menu files (similar to GEM menu files) for the OSX addon folders. Can you get these into gmmenu.tcl? OSX app addon menus are in: $HOME/Library/GRASS/$GRASS_VER/Modules/etc/gm/addons where $GRASS_VER is the major.minor version of the running GRASS. They are named with a .menu extension and are generated automatically on startup. I'm thinking there should also be a user-customizable menu that won't get zapped on every startup, maybe etc/gm/user.menu. When you settle on a way to extend the python gui menu, I'll do a similar thing for that. ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From Agustin.Diez at uv.es Tue Sep 4 19:27:36 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Tue Sep 4 19:30:58 2007 Subject: [GRASS-dev] r.in.wms and wget In-Reply-To: References: Message-ID: <91CCB4C0-263E-4E13-BF4E-F28972A735F1@uv.es> I will be more than happy to test it against that. http://wms.mapa.es/wms/wms.aspx?REQUEST=GetCapabilities&SERVICE=WMS You can find several wms servers in QGIS defaults or at http://www.idee.es/CatalogoServicios/cat2/indexWMS.html where those can be useful Demis World Map http://www2.demis.nl/mapserver/Request.asp? REQUEST=GetCapabilities&SERVICE=WMS Indice de Carb?n Org?nico (ORGANIC CARBON CONTENTS) http://eusoils.jrc.it:80/wmsconnector/com.esri.wms.Esrimap/OCTOP_WMS? REQUEST=GetCapabilities&SERVICE=WMS Mapa del Suelo (Eusoils_WMS) http://eusoils.jrc.it:80/wmsconnector/com.esri.wms.Esrimap/ Eusoils_WMS?REQUEST=GetCapabilities&SERVICE=WMS Mosaicos de Im?genes Landsat7, 15 m(1999-2003) http://wms.jpl.nasa.gov/wms.cgi?REQUEST=GetCapabilities&SERVICE=WMS Riesgo de Erosi?n del suelo estimado (SOIL EROSION RISK) http://eusoils.jrc.it:80/wmsconnector/com.esri.wms.Esrimap/PESERA_WMS? REQUEST=GetCapabilities&SERVICE=WMS Demis World Map http://www2.demis.nl/mapserver/Request.asp? REQUEST=GetCapabilities&SERVICE=WMS Indice de Carb?n Org?nico (ORGANIC CARBON CONTENTS) http://eusoils.jrc.it:80/wmsconnector/com.esri.wms.Esrimap/OCTOP_WMS? REQUEST=GetCapabilities&SERVICE=WMS Mapa del Suelo (Eusoils_WMS) http://eusoils.jrc.it:80/wmsconnector/com.esri.wms.Esrimap/ Eusoils_WMS?REQUEST=GetCapabilities&SERVICE=WMS Mosaicos de Im?genes Landsat7, 15 m(1999-2003) http://wms.jpl.nasa.gov/wms.cgi?REQUEST=GetCapabilities&SERVICE=WMS Riesgo de Erosi?n del suelo estimado (SOIL EROSION RISK) http://eusoils.jrc.it:80/wmsconnector/com.esri.wms.Esrimap/PESERA_WMS? REQUEST=GetCapabilities&SERVICE=WMS On Sep 4, 2007, at 5:34 PM, William Kyngesburye wrote: > http://wald.intevation.org/tracker/? > func=detail&aid=380&group_id=21&atid=188 With no offers of help on my request a while back, I decided to give it a go: http://wald.intevation.org/tracker/? func=detail&aid=380&group_id=21&atid=188 I think I figured out the equivalent curl command. Does anyone know of a WMS server I could try importing a small raster from to test it? ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070904/6f813dac/attachment-0001.html From woklist at kyngchaos.com Tue Sep 4 21:33:12 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Sep 4 21:33:33 2007 Subject: [GRASS-dev] r.in.wms and wget and curl Message-ID: <49CB69B3-C504-46FF-A3E7-A27F9C58C7AA@kyngchaos.com> (oh my!) For: http://wald.intevation.org/tracker/? func=detail&aid=380&group_id=21&atid=188 r.in.wms will now use curl if wget isn't found (and curl is found, of course). If both are installed, wget takes priority. I added an option: curloptions, because the default options equivalent to wget are different. I'll work on updating the help description next. ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From paul-grass at stjohnspoint.co.uk Mon Sep 3 17:48:14 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Sep 5 00:00:29 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <46DC2A6F.2050102@club.worldonline.be> References: <46DC2A6F.2050102@club.worldonline.be> Message-ID: On Mon, 3 Sep 2007, Moritz Lennert wrote: > Benjamin wrote: > >>> So, how are we going to go ahead? >> > > Glynn answered: > >> Figure out how to debug the processes. If you can't get gdb to work, I >> can only suggest logging every significant event at the lowest level, >> i.e. log every read/write operation: the arguments, the return code, >> and the complete data (i.e. the buffer contents before read and after >> write). This is all done in the RPC/XDR library, in xdr_stdio.c. It >> will probably help to also log the beginning/end of each procedure >> call (i.e. lib/db/dbmi_base/xdrprocedure.c). > > I would really like this to be solved, so I am willing to try to find some > time to do the logging effort. Benjamin, have you advanced on this ? > > I will need some time understanding the xdr logic and code, but hope to be > able to help with this. I have a feeling there is more than one C implementation of the XDR standard available on the 'net - perhaps trying an alternative one might be something to try, in case there's a bug in the version we're using. We already had undetectable (for a long time) problems caused by the current version needing to be compiled statically. I'd like to try this too if I had time but am unfortunately really busy right now. Paul From michael.barton at asu.edu Wed Sep 5 05:16:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Sep 5 05:17:06 2007 Subject: [GRASS-dev] testing tcltk animate Message-ID: Glynn, I took an initial look at the TclTk animator to replace xganim. I could get it started from the command line, but it only shows the display frame with buttons. I couldn't see a way to add maps. I also tried to run it from within the GUI by calling main. This returns an error " wrong # args: should be "main argc argv". So it needs to get passed something somewhere. What arguments is the program looking for to get started? A list of raster maps? Something else? I guess I should also ask, is 'main' the starting procedure? 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/20070904/570fd869/attachment.html From woklist at kyngchaos.com Wed Sep 5 05:43:12 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Sep 5 05:43:42 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: <1251.85.10.66.145.1188849126.squirrel@geog-pc40.ulb.ac.be> References: <46DBFFDD.6040606@club.worldonline.be> <127027AA-49E6-4A3D-8F2A-FA01964FFDC0@kyngchaos.com> <1196.85.10.66.145.1188846334.squirrel@geog-pc40.ulb.ac.be> <5F1E3329-226C-4D6B-89BB-DD39A1ABC9BC@kyngchaos.com> <1251.85.10.66.145.1188849126.squirrel@geog-pc40.ulb.ac.be> Message-ID: <3C109665-88A6-42EB-812D-425A3647B7AC@kyngchaos.com> Getting this thread back on track, any developments yet? Do you have something I can try in the Spearfish data? At least I can check if there is a library or other build problem with my binary. If it's a GUI problem, I probably won't be of much help. On Sep 3, 2007, at 2:52 PM, Moritz Lennert wrote: >> The OSX Console.app is where to look - find a crashlog in ~/Library/ >> Logs/Crashreporter. >> > > I'll try that when I next get in front of the OSX machine. ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From woklist at kyngchaos.com Wed Sep 5 05:50:12 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Sep 5 05:50:39 2007 Subject: [GRASS-dev] testing tcltk animate In-Reply-To: References: Message-ID: <069D9CAE-4239-40FF-A053-FA7E7ED25BAA@kyngchaos.com> Thanks for looking into this. After a quick look, I became lost and realized I didn't even know where to start to try to run this. On Sep 4, 2007, at 10:16 PM, Michael Barton wrote: > Glynn, > > I took an initial look at the TclTk animator to replace xganim. I > could get it started from the command line, but it only shows the > display frame with buttons. I couldn't see a way to add maps. > > I also tried to run it from within the GUI by calling main. This > returns an error " wrong # args: should be "main argc argv". > > So it needs to get passed something somewhere. What arguments is > the program looking for to get started? A list of raster maps? > Something else? I guess I should also ask, is 'main' the starting > procedure? > > Thanks > Michael ----- 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 michael.barton at asu.edu Wed Sep 5 05:55:53 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Sep 5 05:56:31 2007 Subject: [GRASS-dev] another not quiet GRASS command In-Reply-To: Message-ID: On 9/3/07 10:06 AM, "Paul Kelly" wrote: > On Mon, 3 Sep 2007, Michael Barton wrote: > >> The problem in this and other cases is that the warning is sent to stderr >> when the command operates and exits properly. Error messages are sent to >> stderr when the command does not operate properly and/or exits with an >> error. There is no easy way (maybe no way in many cases) for a script to >> tell the difference. > > I think Tcl's deficiencies are confusing you. Tcl cannot tell the > difference and this is IMHO a major bug in Tcl. But it is a single > exception. Operating systems and probably almost all other scripting > languages use the exit code of the program: a zero exit code indicates it > exited successfully; a non-zero exit code indicates it exited with an > error. You're probably right. I'm trying to work out a reasonable error trap function. Not very difficult in general, though replacing all the individual error traps will be tedious. > > In any case Maris seems to have found a workaround to Tcl's deficiency: > check the global variable errorcode after running an external command. I'm > waiting to see if anybody comes up with a problem with this approach. I looked at this and tried it out. I found that it doesn't work as expected. The reason is that all or most of the error codes returned by Tcl seem to potentially be ones we'd need to trap. See docs at . For example, I tried giving an incorrect module name in a menu to get a file not found error. In this case, Tcl_errorCode returns POSIX rather than CHILDSTATUS The generic error trap will allow for global formatting change in the future, but I don't see any way around the confusion of real error messages and other messages sent to stderr in Tcltk. 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 michael.barton at asu.edu Wed Sep 5 06:19:01 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Sep 5 06:19:35 2007 Subject: [GRASS-dev] error reporting In-Reply-To: <18140.5626.224323.508059@cerise.gclements.plus.com> Message-ID: Here's the generic error function I planning to add. It seems to work pretty good. Let me know if you see any problems or can suggest further enhancements. I'm going to put it into gm.tcl where it will be available to all GUI modules except gis_set.tcl (which runs before everything else, but is not sourced by the main GUI). proc Gm::errmsg { error args } { # send error report and optional message (args) to tk_messageBox set message "" if { $args != ""} { set message [G_msg [join $args]] append message ": " } tk_messageBox -type ok -icon error -title [G_msg "Error"] \ -message "$message[G_msg $error]" uplevel 1 return }; Michael On 9/3/07 7:11 AM, "Glynn Clements" wrote: > > For a start, if you add: > > proc errorBox {msg} { > tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg > } > > you would be able to replace e.g.: > > tk_messageBox -type ok -icon error -title [G_msg "Error"] \ > -message [G_msg "Error creating tempfile: $error"] > > (of which I see at least 102 occurrences) with just: > > errorBox [G_msg "Error creating tempfile: $error"] > > [ > BTW, this usage of G_msg is probably incorrect, as the entire message, > including $error, will be used as the key. It should probably be: > > errorBox "[G_msg {Error creating tempfile}]: $error" > > or even: > > errorBox "[G_msg {Error creating tempfile}]: [G_msg $error]" > > so that "Error creating tempfile" and the error message will be > translated independently. This means that you only need A+B > translations instead of A*B. The second G_msg is only necessary if > Tcl/Tk error messages aren't already localised by Tcl/Tk. > > Note that the situation is different with C, where "%s" is included > literally in the message key. In Tcl, $error will be substituted > before the message is translated. > ] __________________________________________ 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 cavallini at faunalia.it Wed Sep 5 08:16:37 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Wed Sep 5 08:16:47 2007 Subject: [GRASS-dev] China group Message-ID: <46DE49C5.3030702@faunalia.it> Hi all. I remember some times ago a team of Chinese devs started working on GRASS. Anyone knows about their results? All the best. pc -- Paolo Cavallini, see: http://www.faunalia.it/pc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070905/584cc2de/signature.bin From michael.barton at asu.edu Wed Sep 5 08:17:51 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Sep 5 08:19:14 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: <18141.11819.425557.461015@cerise.gclements.plus.com> Message-ID: I did some experimentation with the lpr part of mapprint.tcl tonight. I'm thinking that maybe I've done this before and come up with the same result--and that is why I turned to ghostscript. TclTk will output to a PS file that looks just fine when I open it. However, just sending this to lpr (>>lpr file.ps) gives a very poor result. The map is up against the upper right edges of the page, rather than being centered. It is clipped on all edges but the bottom and clipped a significant amount on the left side of the map (a side which is NOT against the edge of a page). Is there something I'm missing in sending this to lpr? Michael On 9/4/07 3:06 AM, "Glynn Clements" wrote: > > William Kyngesburye wrote: > >>> Yea. TclTk (at least the packages we use) doesn't have any good built in >>> printing routines. I wrote one that is included in the GUI, but it needs >>> ghostscript to translate from the native postscript of the canvas >>> into print output. > > On Unix, "print output" traditionally *is* PostScript. > > The backbone of most Unix printing setups is the use of Ghostscript to > make your printer look like a PostScript printer. If you happen to > have an actual PostScript printer, the Ghostscript step is omitted. > > There's no need for gis.m to invoke Ghostscript itself when printing; > it can just feed PostScript to "lpr" (with CUPS, you can feed a lot of > other formats, but PostScript is the one format which is likely to be > accepted on non-CUPS systems). > > Moreover, using gs to render to an image format then sending the image > to lpr will invariably produce worse results than letting the printing > system perform the rendering (or sending the data directly to a > PostScript printer). > >> I got to thinking about the GS license (it's GPL now) and I'll either >> have to make it a separate download or find an existing Mac binary, >> or maybe use an older AFPL GS. Maybe there's an equivalent in the >> system somewhere - it already uses CUPS for printing, maybe there's a >> CLI postscript renderer... > > "lpr file.ps" should work. > >> Is your GUI printing use of GS the only thing in GRASS that uses it? >> Does it generate an image, or print-ready postscript? > > Looking at mapprint.tcl, it either: > > 1. Generates an image and sends it to "lpr". (CUPS will first convert > this to PostScript, then either invoke Ghostscript to convert it to > the printer's raw image format or send it directly to a PostScript > printer). > > 2. Invokes gs with DEVICE set to a user-defined string. [This one > looks wrong; it doesn't appear to send the output anywhere.] > > 3. Generate a PDF. __________________________________________ 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 neteler at itc.it Wed Sep 5 09:27:30 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 5 09:27:41 2007 Subject: [GRASS-dev] China group In-Reply-To: <46DE49C5.3030702@faunalia.it> References: <46DE49C5.3030702@faunalia.it> Message-ID: <12493051.post@talk.nabble.com> Paolo Cavallini wrote: > > Hi all. > I remember some times ago a team of Chinese devs started working on > GRASS. Anyone knows about their results? > Here is a blog post (I don't know more): http://www.gaoang.com/?p=36 Markus -- View this message in context: http://www.nabble.com/China-group-tf4382183.html#a12493051 Sent from the Grass - Dev mailing list archive at Nabble.com. From landa.martin at gmail.com Wed Sep 5 09:46:26 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Sep 5 09:46:44 2007 Subject: [GRASS-dev] script output for g.list In-Reply-To: References: Message-ID: Hi Michael, Markus, ..., that's true, '--q/--v' should not influence format for listing in this way! I added parameter 'ncols' for "Number of elements per line". But the verbose listing still uses G_list_elements(), so 'ncols' doesn't work together with '-f' flag. Path attached. For scripting $ g.list rast ncols=1 --q $ g.list help Description: Lists available GRASS data base files of the user-specified data type to standard output. Keywords: general, map management Usage: g.list [-f] type=datatype[,datatype,...] [mapset=string] [ncols=value] [--verbose] [--quiet] Flags: -f Verbose listing (also list map titles) Prints one element per line --v Verbose module output --q Quiet module output Parameters: type Data type options: rast,rast3d,vect,oldvect,asciivect,icon,labels,sites, region,region3d,group,3dview mapset Mapset to list (default: current search path) ncols Number of elements per line (0 for autodetect) default: 0 Martin 2007/9/4, Michael Barton : > Thanks very much Martin. Not knowing C, I'm not exactly sure what to do with > this, but will try to work with it if no one else gets to it first. I'm not > sure I'd hang the different format on the --q flag. Maybe a -l (for > listing?) flag would be better. > > Once this is worked out and in the cvs, I'll put it into select.py. I don't > know if you've had a chance to look, but I added a class to allow select to > be called in a separate dialog and a method that lets you update the element > list after you've created a selection control. > > Michael > > > On 9/4/07 2:37 AM, "Martin Landa" wrote: > > > Hi Michael, > > > > I tried to modify g.list. Instead of G_list_element(), the patch call > > G_list() and G_ls_format() . > > > > Patch attached (not committed to CVS). > > > > E.g. > > > > $ g.list rast > > ---------------------------------------------- > > raster files available in mapset : > > asp > > ---------------------------------------------- > > raster files available in mapset : > > aspect elevation.dem fields landuse roads > > soil.br.depth soils.ph strm.dist trn.sites > > bugsites elevation.dted geology owner > > rstrct.areas soils soils.range texture uparea > > density erode.index landcover.30m quads > > rushmore soils.Kfactor spot.image tractids > > vegcover > > elevation.10m erosion1 landcover.orig railroads slope > > soils.Tfactor streams transport.misc > > > > $ g.list rast --q > > asp > > aspect > > bugsites > > density > > elevation.10m > > elevation.dem > > elevation.dted > > erode.index > > erosion1 > > fields > > geology > > landcover.30m > > landcover.orig > > landuse > > owner > > quads > > railroads > > roads > > rstrct.areas > > rushmore > > slope > > soil.br.depth > > soils > > soils.Kfactor > > soils.Tfactor > > soils.ph > > soils.range > > spot.image > > streams > > strm.dist > > texture > > tractids > > transport.misc > > trn.sites > > uparea > > vegcover > > > > Martin > > > > 2007/9/3, Michael Barton : > >> > >> Awhile ago, I think g.mlist output was changed so that it sent out a single > >> list of maps or other GIS elements rather than a multicolumn list. Is there > >> a way to add a flag to g.list so that it can produce output in the same way? > >> > >> As it is, the output of g.list cannot easily be parsed within a script > >> because of it's multicolumn output. If the output could be a nice, clean > >> single list, it *would* be parsable. Within a script, g.list is preferable > >> over g.mlist for finding all relevant files in a mapset because it seems > >> considerably faster. > >> > >> 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 > >> > >> > >> _______________________________________________ > >> 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 > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: g-list-vq-2.diff.gz Type: application/x-gzip Size: 2521 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070905/d9e4b94a/g-list-vq-2.diff.gz From neteler at itc.it Wed Sep 5 12:27:14 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 5 12:27:17 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: [winGRASS] native winGRASS pre-alpha testers needed In-Reply-To: <2902.128.40.195.179.1188984988.squirrel@webmail.mail.uni-kiel.de> References: <000e01c7eeee$12e2f780$9e476395@VALUED976296A0> <46DE665E.3040209@club.worldonline.be> <2902.128.40.195.179.1188984988.squirrel@webmail.mail.uni-kiel.de> Message-ID: <46DE8482.2030103@itc.it> (moved to grass-dev) benjamin.ducke@ufg.uni-kiel.de wrote on 09/05/2007 11:36 AM: > In addition, GRASS shell scripts and modules should be checked > and hardened for cases where spaces may appear in file or directory names. > > On a unix system, users generally don't store stuff in paths with > spaces, but Windows by its very design encourages this. > E.g. the user's home folder may well be something like > ... > > So I'd recommend to do just that: install WinGRASS into a dir with > spaces, create a GRASS mapset, also in a path with spaces, and > work from there to find all the vulnerable bits and pieces. > This can be done by Linux/Mac users, too, for testing. I just changed my grassdata/ to grass data/ and voila... cmd line startup fails: both grass63 "~/grass data/spearfish60/user1" grass63 ~/grass\ data/spearfish60/user1 fail in line 439 of Init.sh: + echo 'GRASS_GUI: text' + mv -f /tmp/grass6-neteler-27726/gisrc.27726 /tmp/grass6-neteler-27726/gisrc + '[' '!' /ssi0/ssi/neteler/grass ']' -> data of "grass data" got lost! The code snippet is: # Parsing argument to get LOCATION if [ ! "$1" ] ; then Apparently we need a trick since "$1" is taking only the first part. Substitute ' ' earlier in Init.sh with '_' and then replace back? Probably $@ isn't a good idea. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Wed Sep 5 14:54:57 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 5 14:55:00 2007 Subject: [GRASS-dev] Update of r.surf.idw to FP In-Reply-To: <17920.9929.112092.89990@cerise.gclements.plus.com> References: <20070320141805.GD2549@bartok.itc.it> <17920.9929.112092.89990@cerise.gclements.plus.com> Message-ID: <46DEA721.3030305@itc.it> Glynn Clements wrote on 03/20/2007 07:24 PM: > Markus Neteler wrote: > >> I have tried to update r.surf.idw to floating point: >> >> but I am not quite sure if this is efficient like this. >> Currently it doesn't compile due to some "extern" magic >> which I don't quite understand. >> I have been inspired by r.example. >> > > The problem is that you have renamed some (but not all) occurrences of > "cell" to "outrast", although the variable is still called "cell". > > (given that r.surf.idw should stay for more time) I have updated the patch (find attached) to the current CVS version, still crashing. Advice/fix most welcome... thanks Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: r_surf_idw_fp.patch.gz Type: application/x-gzip Size: 2657 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070905/30365cc9/r_surf_idw_fp.patch.gz From woklist at kyngchaos.com Wed Sep 5 16:14:04 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Sep 5 16:14:25 2007 Subject: [GRASS-dev] GRASS printing In-Reply-To: References: Message-ID: <3EC8ABD1-B23E-444D-9189-00084FF794CC@kyngchaos.com> On Sep 5, 2007, at 1:17 AM, Michael Barton wrote: > I did some experimentation with the lpr part of mapprint.tcl > tonight. I'm > thinking that maybe I've done this before and come up with the same > result--and that is why I turned to ghostscript. > > TclTk will output to a PS file that looks just fine when I open it. > > However, just sending this to lpr (>>lpr file.ps) gives a very poor > result. > The map is up against the upper right edges of the page, rather > than being > centered. It is clipped on all edges but the bottom and clipped a > significant amount on the left side of the map (a side which is NOT > against > the edge of a page). > > Is there something I'm missing in sending this to lpr? > > Michael What about job options? The CUPS manual has better documentation than the lpr man page. Check http://localhost:631/documentation.html. A mismatch of the document orientation and the job orientation can cause odd clipping. And default position is probably upper-left, but again orientation can cause trouble, rotation said upper left to another corner. ----- 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 michael.barton at asu.edu Wed Sep 5 17:08:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Sep 5 17:09:17 2007 Subject: [GRASS-dev] Re: GRASS printing In-Reply-To: <3EC8ABD1-B23E-444D-9189-00084FF794CC@kyngchaos.com> Message-ID: The options described in the CUPS docs may be what I need. Thanks. Michael On 9/5/07 7:14 AM, "William Kyngesburye" wrote: > On Sep 5, 2007, at 1:17 AM, Michael Barton wrote: > >> I did some experimentation with the lpr part of mapprint.tcl >> tonight. I'm >> thinking that maybe I've done this before and come up with the same >> result--and that is why I turned to ghostscript. >> >> TclTk will output to a PS file that looks just fine when I open it. >> >> However, just sending this to lpr (>>lpr file.ps) gives a very poor >> result. >> The map is up against the upper right edges of the page, rather >> than being >> centered. It is clipped on all edges but the bottom and clipped a >> significant amount on the left side of the map (a side which is NOT >> against >> the edge of a page). >> >> Is there something I'm missing in sending this to lpr? >> >> Michael > > What about job options? The CUPS manual has better documentation > than the lpr man page. Check http://localhost:631/documentation.html. > > A mismatch of the document orientation and the job orientation can > cause odd clipping. And default position is probably upper-left, but > again orientation can cause trouble, rotation said upper left to > another corner. > > ----- > 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 > __________________________________________ 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 Wed Sep 5 17:25:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 5 17:25:15 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: References: <18141.11819.425557.461015@cerise.gclements.plus.com> Message-ID: <18142.51798.853921.504813@cerise.gclements.plus.com> Michael Barton wrote: > I did some experimentation with the lpr part of mapprint.tcl tonight. I'm > thinking that maybe I've done this before and come up with the same > result--and that is why I turned to ghostscript. > > TclTk will output to a PS file that looks just fine when I open it. > > However, just sending this to lpr (>>lpr file.ps) gives a very poor result. > The map is up against the upper right edges of the page, rather than being > centered. It is clipped on all edges but the bottom and clipped a > significant amount on the left side of the map (a side which is NOT against > the edge of a page). > > Is there something I'm missing in sending this to lpr? When you say that it "looks just fine when I open it", are you looking at it as a page, or as EPS? Viewers such as GV typically show EPS files (which is what Tk's canvas generates) cropped to the bounding box, with no notion of a page. Also, it's possible that there's something wrong with your printer setup. Have you tried printing PostScript generated by other applications? -- Glynn Clements From glynn at gclements.plus.com Wed Sep 5 18:04:36 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 5 18:04:42 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <1364.85.10.66.145.1188851630.squirrel@geog-pc40.ulb.ac.be> References: <46DC2A6F.2050102@club.worldonline.be> <1364.85.10.66.145.1188851630.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18142.54164.325645.775834@cerise.gclements.plus.com> Moritz Lennert wrote: > > >> So, how are we going to go ahead? > > > > > > > Glynn answered: > > > > > Figure out how to debug the processes. If you can't get gdb to work, I > > > can only suggest logging every significant event at the lowest level, > > > i.e. log every read/write operation: the arguments, the return code, > > > and the complete data (i.e. the buffer contents before read and after > > > write). This is all done in the RPC/XDR library, in xdr_stdio.c. It > > > will probably help to also log the beginning/end of each procedure > > > call (i.e. lib/db/dbmi_base/xdrprocedure.c). > > > > I would really like this to be solved, so I am willing to try to find > > some time to do the logging effort. Benjamin, have you advanced on this ? > > > > I will need some time understanding the xdr logic and code, but hope to > > be able to help with this. > > > > Ok, very first simple debugging effort seems to confirm timin issue. > Here's what I did: > > diff -u dbmi_base dbmi_base_debug/ > Common subdirectories: dbmi_base/CVS and dbmi_base_debug/CVS > Only in dbmi_base_debug/: OBJ.i686-pc-mingw32 > diff -u dbmi_base/xdrint.c dbmi_base_debug/xdrint.c > --- dbmi_base/xdrint.c Thu Oct 5 06:13:28 2006 > +++ dbmi_base_debug/xdrint.c Mon Sep 3 20:17:35 2007 > @@ -10,10 +10,12 @@ > > stat = DB_OK; > > + G_debug(1, "xdrint.c: Begin send"); > xdr_begin_send (&xdrs); > if(!xdr_int (&xdrs, &n)) > stat = DB_PROTOCOL_ERR; > xdr_end_send (&xdrs); > + G_debug(1, "xdrint.c: End send"); > > if (stat == DB_PROTOCOL_ERR) > db_protocol_error(); > diff -u dbmi_base/xdrprocedure.c dbmi_base_debug/xdrprocedure.c > --- dbmi_base/xdrprocedure.c Thu Oct 5 06:13:28 2006 > +++ dbmi_base_debug/xdrprocedure.c Mon Sep 3 20:17:35 2007 > @@ -40,10 +40,12 @@ > > stat = DB_OK; > > + G_debug(1, "xdrprocedure.c: Begin receive"); > xdr_begin_recv (&xdrs); > if(!xdr_int (&xdrs, n)) > stat = DB_EOF; > xdr_end_recv (&xdrs); > + G_debug(1, "xdrprocedure.c: End receive"); > > return stat; > } > > and now, after setting 'g.gisenv set=DEBUG=1', I cannot reproduce the > deadlock anymore, using Benjamin's test data, except when I do other > things on the machine (open other windows, type an email, etc). When I > just run the command and stare at the screen I get no deadlock. With > DEBUG=0 I get the same irregular deadlock. > > I'll dig into xdrstdio.c now. If it is a timing issue, then you'll need to log the fread/fwrite return values, along with the actual data, for both ends (client and server). Then, find out where the two diverge (i.e. what is received isn't what was sent). However, I have a strong suspicion that the eventual answer will be "MSVCRT's stdio implementation sucks". I already know this to be true; what I don't know is whether it's the cause of the DBMI problems and, if so, how much stuff we will need to re-write. -- Glynn Clements From glynn at gclements.plus.com Wed Sep 5 18:09:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 5 18:09:16 2007 Subject: [GRASS-dev] testing tcltk animate In-Reply-To: References: Message-ID: <18142.54440.125554.96455@cerise.gclements.plus.com> Michael Barton wrote: > I took an initial look at the TclTk animator to replace xganim. I could get > it started from the command line, but it only shows the display frame with > buttons. I couldn't see a way to add maps. > > I also tried to run it from within the GUI by calling main. This returns an > error " wrong # args: should be "main argc argv". > > So it needs to get passed something somewhere. What arguments is the program > looking for to get started? A list of raster maps? Something else? It is supposed to accept the same options as xganim, i.e. view1=... etc, where the value of each option is a list of raster maps separated by commas. > I guess I should also ask, is 'main' the starting procedure? Yes. The top level is a bunch of "set" commands, then a bunch of "proc" commands, then a call to "main" on the last line. The parse_command procedure deals with parsing the command line. -- Glynn Clements From glynn at gclements.plus.com Wed Sep 5 18:27:46 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 5 18:27:51 2007 Subject: [GRASS-dev] error reporting In-Reply-To: References: <18140.5626.224323.508059@cerise.gclements.plus.com> Message-ID: <18142.55554.402938.602868@cerise.gclements.plus.com> Michael Barton wrote: > Here's the generic error function I planning to add. It seems to work pretty > good. Let me know if you see any problems or can suggest further > enhancements. I'm going to put it into gm.tcl where it will be available to > all GUI modules except gis_set.tcl (which runs before everything else, but > is not sourced by the main GUI). > > proc Gm::errmsg { error args } { > # send error report and optional message (args) to tk_messageBox > > set message "" > > if { $args != ""} { > set message [G_msg [join $args]] > append message ": " > } > > tk_messageBox -type ok -icon error -title [G_msg "Error"] \ > -message "$message[G_msg $error]" > uplevel 1 return > > }; I'm not sure that it's appropriate for the translation to be done here; the caller has a better understanding of where the message boundaries lie. If it's done here, each arg should probably be translated individually; the caller can always join any arguments which should be translated as a whole. Even then, there's no option to have a portion which doesn't get translated. -- Glynn Clements From neteler at itc.it Wed Sep 5 18:28:39 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 5 18:28:41 2007 Subject: [GRASS-dev] [grass-code I][470] i.atcorr: hardcoded input/output map names In-Reply-To: <200708291957.18503.yann.chemin@gmail.com> References: <20070827204117.029BE40077@pyrosoma.intevation.org> <200708290016.09767.yann.chemin@gmail.com> <12373373.post@talk.nabble.com> <200708291957.18503.yann.chemin@gmail.com> Message-ID: <12505895.post@talk.nabble.com> Hello Yann, Yann Chemin-3 wrote: > > Hello Markus, > > Here is a patch done with this command: > diff -Naur main.cppold main.cpp > main_atcorr.diff > > Just commented the '...->answer=...' pointers. > > Yann > > [patch] > I have applied your patch in CVS. thanks Markus -- View this message in context: http://www.nabble.com/-grass-code-I--470--i.atcorr%3A-hardcoded-input-output-map-names-tf4338122.html#a12505895 Sent from the Grass - Dev mailing list archive at Nabble.com. From rez at touchofmadness.com Thu Sep 6 02:45:22 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 6 02:45:47 2007 Subject: [GRASS-dev] autotools Message-ID: <1189039522.3129.5.camel@dev64.localdomain> What versions of autoconf, automake, etc. is everyone using? When I do autoreconf, I get errors. The generated configure script has extraneous 'fi' statements. It seems to be a problem with certain nested AC_CHECK_LIB() calls. Removing them allows me to progress further (curses, mysql), but obviously that's not the right way to go. Is there some version specific autotools calls I'm not aware of? autoconf: 2.59 automake: 1.9.6 libtool: 1.5 -- 73, de Brad KB8UYR/6 From hmitaso at unity.ncsu.edu Thu Sep 6 05:01:44 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Thu Sep 6 05:01:51 2007 Subject: [GRASS-dev] Fwd: LINEQS solvers and v.surf.rst References: <463DAB97.5020204@gmx.de> Message-ID: Soeren, I am forwarding the tests to the dev list so that it gets into the archive and everybody can check it out. For everybody - this relates to the discussion about the NR lineqs solver replacement, 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/ Begin forwarded message: > From: S?ren Gebbert > Date: May 6, 2007 6:19:03 AM EDT > To: Helena Mitasova > Subject: Re: LINEQS > > Helena, > Thanks for the chapter. > I have tested the solvers with several vector maps from the > new demo location. > > The script which performs the tests is attached. So you are > able to reproduce the tests. > The log file, including time measurement and error log, > is attached as well. > > I have created two simple bar charts. The first represents the > processed vector maps and > the cpu time consumption of each solver, measured by the time > command. The second one > represents the elev result error between the iterative solvers and > the nrlu solver > for each processed vector map. > > All the data presented in the charts is available in the log file. > > The cg solver is the fastest solver, the new direct lu and gauss > solver are 20% slower than the nrlu algorithm. > > The computation error of the iterative solvers is small enough to be > accepted. The gpde lu and gauss solver producing exactly the same > result as the nrlu > algorithm (see log file). > > So the new lu and the cg solver are the best replacement for nrlu. > I did not tested parallel computation, because i have no > multi core computer at home. > > But, the iterative solvers partially failed on vector maps with low > data density (contour lines > in maps elev_contour_3m and elev_ned10m_cont10m), > in case the npmin was set to 50 or lower. A value of 50 is not > meaningful for the maps, > but its the users choice ... . > > So much more testing is needed. > Anyway, the gpde lu solver can handle this. > > Important region and v.surf.rst settings: > > g.region rural_1m res=2 > npmin=500 > > Best regards > Soeren > > Helena Mitasova schrieb: >> On May 5, 2007, at 4:00 PM, S?ren Gebbert wrote: >>> Hi, >>> now i know the source of the linear equation solver >>> which you had send me. >>> Its is the solver implemented in v.vol.rst in user4.c. :D >> yes - actually v.surf.rst (s.surf.tps) originally looked like >> v.vol.rst which is a direct >> rewrite of our original fortran code. There should also be v.volt.rst >> that interpolates in 3D+time space. >> I really wanted all 3 programs and r.resamp.rst to be based on a >> single library as >> most of the code is almost the same, only the dimensions change, >> but Irina (one of the russian twins that worked with me at CERL >> and did a lot of coding for GRASS, you can see Olga and Irina >> mentioned throughout various GRASS modules) >> managed to get it to where it is now by the time she finished her >> Masters >> and CERL dropped the GRASS project. So it is a quite ugly code >> right now >> but it works . I doubt that anybody would have time to rewrite it. >>> >>> Looks like good old fortran code converted to C. >>> I think i will patch v.vol.rst too. >> yes that would be good. I am thinking that it may be useful to submit >> the options for solvers that you have added into CVS, I would like >> to let >> people from GEON project try it out too (http://lidar.asu.edu/), >> especially >> the parallel processing. >> It would be great if you could try out the performance of the >> solvers with >> the new data set - both in terms of how fast they are and whether >> there are >> any differences in the results. The data are here, (set the region >> to rural_1m) >> http://mpa.itc.it/grasstutor/data_menu3rd.phtml >> Try it with elev_lid792_bepts, elev_lid792_mrpts, >> elev_lid792_randpts and >> elev_contour_3m. I have attached chapter6.tex file that has all >> the commands >> so you can just cut and paste them into a script and run it all at >> once >> (ignore the figures in the pdf file - they are still for sperafish). >> These are all small files so a few tests with millions of points >> would be useful >> too (e.g. the Jockey's ridge data from the second edition >> available at the same web site). >> That should help to decide which method put as default and which >> are not >> needed (to make the life easier for the user). I will then get >> Jaro and some >> other people test it more to make sure that the new solvers work >> for everybody's data. >> Helena >> >>> Best regards >>> Soeren -------------- next part -------------- A non-text attachment was scrubbed... Name: RST_solver_test.sh Type: application/x-shellscript Size: 2330 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070905/8c77ffd2/RST_solver_test-0001.bin -------------- next part -------------- > > ########################################################## > ++ Testing solver nrlu with map elev_lid792_bepts > > 647.86user 4.10system 10:52.79elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+89167minor)pagefaults 0swaps > > ########################################################## > ++ Testing solver lu with map elev_lid792_bepts > > 853.22user 5.02system 14:19.62elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+89451minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and lu solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > -- statistics of differences bewteen nrlu and lu solver based on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > ########################################################## > ++ Testing solver gauss with map elev_lid792_bepts > > 844.28user 5.10system 14:10.43elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+88890minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and gauss solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > -- statistics of differences bewteen nrlu and gauss solver based on > slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > ########################################################## > ++ Testing solver cg with map elev_lid792_bepts > > 298.31user 2.34system 5:01.01elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+89731minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and cg solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -1.52588e-05 > maximum: 1.52588e-05 > range: 3.05176e-05 > mean: 9.53311e-09 > mean of absolute values: 5.71057e-07 > standard deviation: 2.25911e-06 > variance: 5.10356e-12 > variation coefficient: 23697.5 % > sum: 0.0012512207 > > -- statistics of differences bewteen nrlu and cg solver based on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -1.52588e-05 > maximum: 1.52588e-05 > range: 3.05176e-05 > mean: 9.53311e-09 > mean of absolute values: 5.71057e-07 > standard deviation: 2.25911e-06 > variance: 5.10356e-12 > variation coefficient: 23697.5 % > sum: 0.0012512207 > > ########################################################## > ++ Testing solver bicgstab with map elev_lid792_bepts > > 451.35user 3.36system 7:42.13elapsed 98%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+90562minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and bicgstab solver based > on elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -3.8147e-05 > maximum: 1.52588e-05 > range: 5.34058e-05 > mean: -6.01051e-08 > mean of absolute values: 3.5133e-07 > standard deviation: 1.90371e-06 > variance: 3.62411e-12 > variation coefficient: -3167.3 % > sum: -0.0078887939 > > -- statistics of differences bewteen nrlu and bicgstab solver based > on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -3.8147e-05 > maximum: 1.52588e-05 > range: 5.34058e-05 > mean: -6.01051e-08 > mean of absolute values: 3.5133e-07 > standard deviation: 1.90371e-06 > variance: 3.62411e-12 > variation coefficient: -3167.3 % > sum: -0.0078887939 > > ########################################################## > ++ Testing solver nrlu with map elev_lidrural_mrpts > > 427.92user 2.97system 7:11.51elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+87940minor)pagefaults 0swaps > > ########################################################## > ++ Testing solver lu with map elev_lidrural_mrpts > > 587.63user 3.81system 9:52.25elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+88206minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and lu solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > -- statistics of differences bewteen nrlu and lu solver based on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > ########################################################## > ++ Testing solver gauss with map elev_lidrural_mrpts > > 578.09user 3.75system 9:42.95elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+87672minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and gauss solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > -- statistics of differences bewteen nrlu and gauss solver based on > slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > ########################################################## > ++ Testing solver cg with map elev_lidrural_mrpts > > 233.33user 1.98system 4:10.17elapsed 94%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+88477minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and cg solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -3.05176e-05 > maximum: 3.05176e-05 > range: 6.10352e-05 > mean: -1.02307e-08 > mean of absolute values: 5.68266e-07 > standard deviation: 4.16437e-06 > variance: 1.7342e-11 > variation coefficient: -40704.9 % > sum: -0.0013427734 > > -- statistics of differences bewteen nrlu and cg solver based on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -3.05176e-05 > maximum: 3.05176e-05 > range: 6.10352e-05 > mean: -1.02307e-08 > mean of absolute values: 5.68266e-07 > standard deviation: 4.16437e-06 > variance: 1.7342e-11 > variation coefficient: -40704.9 % > sum: -0.0013427734 > > ########################################################## > ++ Testing solver bicgstab with map elev_lidrural_mrpts > > 359.87user 2.86system 6:03.24elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+89273minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and bicgstab solver based > on elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -0.000244141 > maximum: 0.000518799 > range: 0.000762939 > mean: -1.28813e-07 > mean of absolute values: 6.98475e-07 > standard deviation: 9.99815e-06 > variance: 9.99631e-11 > variation coefficient: -7761.74 % > sum: -0.0169067383 > > -- statistics of differences bewteen nrlu and bicgstab solver based > on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -0.000244141 > maximum: 0.000518799 > range: 0.000762939 > mean: -1.28813e-07 > mean of absolute values: 6.98475e-07 > standard deviation: 9.99815e-06 > variance: 9.99631e-11 > variation coefficient: -7761.74 % > sum: -0.0169067383 > > ########################################################## > ++ Testing solver nrlu with map elev_contour_3m > > 126.94user 0.88system 2:08.91elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+13106minor)pagefaults 0swaps > > ########################################################## > ++ Testing solver lu with map elev_contour_3m > > 157.57user 1.10system 2:38.99elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+13143minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and lu solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > -- statistics of differences bewteen nrlu and lu solver based on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > ########################################################## > ++ Testing solver gauss with map elev_contour_3m > > 158.20user 1.08system 2:39.61elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+13074minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and gauss solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > -- statistics of differences bewteen nrlu and gauss solver based on > slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > ########################################################## > ++ Testing solver cg with map elev_contour_3m > > 69.81user 0.65system 1:10.61elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+13184minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and cg solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -1.52588e-05 > maximum: 1.52588e-05 > range: 3.05176e-05 > mean: -8.77162e-08 > mean of absolute values: 5.67859e-07 > standard deviation: 2.28233e-06 > variance: 5.20904e-12 > variation coefficient: -2601.95 % > sum: -0.0115127563 > > -- statistics of differences bewteen nrlu and cg solver based on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -1.52588e-05 > maximum: 1.52588e-05 > range: 3.05176e-05 > mean: -8.77162e-08 > mean of absolute values: 5.67859e-07 > standard deviation: 2.28233e-06 > variance: 5.20904e-12 > variation coefficient: -2601.95 % > sum: -0.0115127563 > > ########################################################## > ++ Testing solver bicgstab with map elev_contour_3m > > 93.88user 0.72system 1:34.81elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+13286minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and bicgstab solver based > on elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -3.8147e-05 > maximum: 3.8147e-05 > range: 7.62939e-05 > mean: -2.70705e-07 > mean of absolute values: 5.87391e-07 > standard deviation: 3.21259e-06 > variance: 1.03207e-11 > variation coefficient: -1186.75 % > sum: -0.0355300903 > > -- statistics of differences bewteen nrlu and bicgstab solver based > on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -3.8147e-05 > maximum: 3.8147e-05 > range: 7.62939e-05 > mean: -2.70705e-07 > mean of absolute values: 5.87391e-07 > standard deviation: 3.21259e-06 > variance: 1.03207e-11 > variation coefficient: -1186.75 % > sum: -0.0355300903 > > ########################################################## > ++ Testing solver nrlu with map elev_ned10m_cont10m > > 57.10user 0.52system 0:57.80elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+22349minor)pagefaults 0swaps > > ########################################################## > ++ Testing solver lu with map elev_ned10m_cont10m > > 71.86user 0.62system 1:12.66elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+22374minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and lu solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > -- statistics of differences bewteen nrlu and lu solver based on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > ########################################################## > ++ Testing solver gauss with map elev_ned10m_cont10m > > 71.32user 0.56system 1:12.09elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+22339minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and gauss solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > -- statistics of differences bewteen nrlu and gauss solver based on > slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: 0 > maximum: 0 > range: 0 > mean: 0 > mean of absolute values: 0 > standard deviation: 0 > variance: 0 > variation coefficient: nan % > sum: 0 > > ########################################################## > ++ Testing solver cg with map elev_ned10m_cont10m > > 40.79user 0.38system 0:41.30elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+22403minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and cg solver based on > elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -1.52588e-05 > maximum: 1.52588e-05 > range: 3.05176e-05 > mean: 5.26356e-07 > mean of absolute values: 1.0859e-06 > standard deviation: 2.93473e-06 > variance: 8.61265e-12 > variation coefficient: 557.557 % > sum: 0.0690841675 > > -- statistics of differences bewteen nrlu and cg solver based on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -1.52588e-05 > maximum: 1.52588e-05 > range: 3.05176e-05 > mean: 5.26356e-07 > mean of absolute values: 1.0859e-06 > standard deviation: 2.93473e-06 > variance: 8.61265e-12 > variation coefficient: 557.557 % > sum: 0.0690841675 > > ########################################################## > ++ Testing solver bicgstab with map elev_ned10m_cont10m > > 50.83user 0.52system 0:51.49elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+22467minor)pagefaults 0swaps > > -- statistics of differences bewteen nrlu and bicgstab solver based > on elevation > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -1.52588e-05 > maximum: 1.52588e-05 > range: 3.05176e-05 > mean: -1.2271e-07 > mean of absolute values: 4.69854e-07 > standard deviation: 2.02924e-06 > variance: 4.1178e-12 > variation coefficient: -1653.69 % > sum: -0.0161056519 > > -- statistics of differences bewteen nrlu and bicgstab solver based > on slope > total null and non-null cells: 131250 > total null cells: 0 > > Of the non-null cells: > ---------------------- > n: 131250 > minimum: -1.52588e-05 > maximum: 1.52588e-05 > range: 3.05176e-05 > mean: -1.2271e-07 > mean of absolute values: 4.69854e-07 > standard deviation: 2.02924e-06 > variance: 4.1178e-12 > variation coefficient: -1653.69 % > sum: -0.0161056519 -------------- next part -------------- A non-text attachment was scrubbed... Name: RST_solver_test_bar_charts.pdf Type: application/pdf Size: 15889 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070905/8c77ffd2/RST_solver_test_bar_charts-0001.pdf -------------- next part -------------- From neteler at itc.it Thu Sep 6 06:55:30 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 6 06:55:32 2007 Subject: [GRASS-dev] autotools In-Reply-To: <1189039522.3129.5.camel@dev64.localdomain> References: <1189039522.3129.5.camel@dev64.localdomain> Message-ID: <12515625.post@talk.nabble.com> Brad, AFAIK we use autoconf-2.13 and nothing else. Markus Brad Douglas wrote: > > What versions of autoconf, automake, etc. is everyone using? When I do > autoreconf, I get errors. The generated configure script has extraneous > 'fi' statements. > > It seems to be a problem with certain nested AC_CHECK_LIB() calls. > Removing them allows me to progress further (curses, mysql), but > obviously that's not the right way to go. > > Is there some version specific autotools calls I'm not aware of? > > autoconf: 2.59 > automake: 1.9.6 > libtool: 1.5 > > -- > 73, de Brad KB8UYR/6 > -- View this message in context: http://www.nabble.com/autotools-tf4389087.html#a12515625 Sent from the Grass - Dev mailing list archive at Nabble.com. From michael.barton at asu.edu Thu Sep 6 07:45:51 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Sep 6 08:00:13 2007 Subject: [GRASS-dev] autotools In-Reply-To: <1189039522.3129.5.camel@dev64.localdomain> Message-ID: On my Mactel MacBook Pro, I have... cmb-MBP:~ cmbarton$ autoconf -V autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. cmb-MBP:~ cmbarton$ automake --version automake (GNU automake) 1.6.3 Written by Tom Tromey . Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. cmb-MBP:~ cmbarton$ libtool -V Apple Computer, Inc. version cctools-622.5 cmb-MBP:~ cmbarton$ On 9/5/07 5:45 PM, "Brad Douglas" wrote: > What versions of autoconf, automake, etc. is everyone using? When I do > autoreconf, I get errors. The generated configure script has extraneous > 'fi' statements. > > It seems to be a problem with certain nested AC_CHECK_LIB() calls. > Removing them allows me to progress further (curses, mysql), but > obviously that's not the right way to go. > > Is there some version specific autotools calls I'm not aware of? > > autoconf: 2.59 > automake: 1.9.6 > libtool: 1.5 > __________________________________________ 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 Thu Sep 6 08:01:46 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Sep 6 08:02:09 2007 Subject: [GRASS-dev] error reporting In-Reply-To: <18142.55554.402938.602868@cerise.gclements.plus.com> Message-ID: On 9/5/07 9:27 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> Here's the generic error function I planning to add. It seems to work pretty >> good. Let me know if you see any problems or can suggest further >> enhancements. I'm going to put it into gm.tcl where it will be available to >> all GUI modules except gis_set.tcl (which runs before everything else, but >> is not sourced by the main GUI). >> >> proc Gm::errmsg { error args } { >> # send error report and optional message (args) to tk_messageBox >> >> set message "" >> >> if { $args != ""} { >> set message [G_msg [join $args]] >> append message ": " >> } >> >> tk_messageBox -type ok -icon error -title [G_msg "Error"] \ >> -message "$message[G_msg $error]" >> uplevel 1 return >> >> }; > > I'm not sure that it's appropriate for the translation to be done > here; the caller has a better understanding of where the message > boundaries lie. It seems cleaner to work with in the scripts if we only need to put in the error variable and a text string. This way ensures that the message gets translated. Is there someone out there with a non-english system that could test whether this is a problem? > > If it's done here, each arg should probably be translated > individually; the caller can always join any arguments which should be > translated as a whole. Even then, there's no option to have a portion > which doesn't get translated. Like this??? proc Gm::errmsg { error args } { # send error report and optional message (args) to tk_messageBox set message "" for arg in $args { if { $arg != "" } { append message "$arg " } } append message ": " tk_messageBox -type ok -icon error -title [G_msg "Error"] \ -message "$message[G_msg $error]" uplevel 1 return }; Only formatting drawback is that the end result will have "string string : " (space before colon). Not a huge problem I guess. You are right. A downside of enforcing translation within the function, rather than relying on it to be done in the original script, is that the whole thing gets translated. I'm not sure if this is really a problem with short, optional error messages in reality. 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 mlennert at club.worldonline.be Thu Sep 6 08:07:57 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Sep 6 08:03:01 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: <3C109665-88A6-42EB-812D-425A3647B7AC@kyngchaos.com> References: <46DBFFDD.6040606@club.worldonline.be> <127027AA-49E6-4A3D-8F2A-FA01964FFDC0@kyngchaos.com> <1196.85.10.66.145.1188846334.squirrel@geog-pc40.ulb.ac.be> <5F1E3329-226C-4D6B-89BB-DD39A1ABC9BC@kyngchaos.com> <1251.85.10.66.145.1188849126.squirrel@geog-pc40.ulb.ac.be> <3C109665-88A6-42EB-812D-425A3647B7AC@kyngchaos.com> Message-ID: <46DF993D.1080609@club.worldonline.be> William Kyngesburye wrote: > Getting this thread back on track, any developments yet? Do you have > something I can try in the Spearfish data? At least I can check if > there is a library or other build problem with my binary. If it's a GUI > problem, I probably won't be of much help. Haven't been able to look into the specific v.surf.rst crash, but I have another problem now: I installed your GRASS 6.3 package plus the QGIS 0.8.1 package, but when I launch the GRASS plugin in QGIS, it tells me that it cannot find the GRASS installation. Not being mac proficient at all, I have not been able to find the path to the installation... Moritz > > On Sep 3, 2007, at 2:52 PM, Moritz Lennert wrote: > >>> The OSX Console.app is where to look - find a crashlog in ~/Library/ >>> Logs/Crashreporter. >>> >> >> I'll try that when I next get in front of the OSX machine. > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > All generalizations are dangerous, even this one. > > From rez at touchofmadness.com Thu Sep 6 08:28:36 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 6 08:28:41 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] BLAS/LAPACK In-Reply-To: <200709052324690.SM06616@grass.itc.it> References: <46DD01E3.7010207@wheregroup.com> <20070904080551.GA5674@bartok.itc.it> <1188960924.17622.16.camel@dev64.localdomain> <7EF8BBF4-0C1A-48C7-9C65-1C99623F3FE5@unity.ncsu.edu> <1189021344.17622.28.camel@dev64.localdomain> <200709052324690.SM06616@grass.itc.it> Message-ID: <1189060116.3129.48.camel@dev64.localdomain> On Thu, 2007-09-06 at 15:24 +1200, Hamish wrote: > Brad Douglas wrote: > > Both Soren and myself would like to replace the BLAS/LAPACK (Fortran > > code) libraries with ATLAS, a tuned C version. This also gets us away > > from the Fortran issues suffered by gcc4. > > > > If there are no objections, I would like to go ahead and modify > > configure.in and include/ to reflect this. > .. > > One thing we have not discussed yet is possibly merging lib/gmath and > > lib/gpde. Right now, we should probably leave it alone. I haven't > > checked to see what all uses lib/gpde. > > Hi, > > IMO important technical decisions such as this need to happen over on > the grass-dev mailing list to allow contributions from all devels and > a single source for future thread archive searches. I've already discussed most of this without objection on the dev list. cc'ing this email. > and FWIW, fortran90 support in the latest gcc4 releases seems to be much > improved over earlier versions. (but AFAIK grass has ever only linked to > f77 stuff) That requires that BLAS/LAPACK be ported to f90. BTW, I have created a work-around that allows gcc4 to still use f77. Regardless, BLAS/LAPACK needs better definition in autoconf. I have autoconf code that allows us to pick and close the BLAS/LAPACK implementation that best suits our needs. That could be traditional f77 BLAS/LAPACK, ATLAS, SciLAPACK, etc. This gives the person compiling the ability to "tune" to their application (cluster, SMP, SMP cluster). Unfortunately, I haven't been able to test it (autoreconf issues). -- 73, de Brad KB8UYR/6 From rez at touchofmadness.com Thu Sep 6 08:39:05 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 6 08:39:09 2007 Subject: [GRASS-dev] autotools In-Reply-To: <12515625.post@talk.nabble.com> References: <1189039522.3129.5.camel@dev64.localdomain> <12515625.post@talk.nabble.com> Message-ID: <1189060745.3129.56.camel@dev64.localdomain> Thanks! That seems to work. On Wed, 2007-09-05 at 21:55 -0700, Markus Neteler wrote: > Brad, > > AFAIK we use autoconf-2.13 and nothing else. > > Markus > > > Brad Douglas wrote: > > > > What versions of autoconf, automake, etc. is everyone using? When I do > > autoreconf, I get errors. The generated configure script has extraneous > > 'fi' statements. > > > > It seems to be a problem with certain nested AC_CHECK_LIB() calls. > > Removing them allows me to progress further (curses, mysql), but > > obviously that's not the right way to go. > > > > Is there some version specific autotools calls I'm not aware of? -- 73, de Brad KB8UYR/6 From frankie at debian.org Thu Sep 6 10:40:17 2007 From: frankie at debian.org (Francesco P. Lovergine) Date: Thu Sep 6 10:40:21 2007 Subject: [GRASS-dev] MISR HDF-EOS2 data Message-ID: <20070906084017.GB3271@mithrandir> Could someone confirm that MISR radiance/geometric data need an ad-hoc importer for grass? I'm going to write down such a tool based on MISR toolkit, just like to know if i'm wasting my time... -- Francesco P. Lovergine From neteler at itc.it Thu Sep 6 11:11:23 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 6 11:11:25 2007 Subject: [GRASS-dev] MISR HDF-EOS2 data In-Reply-To: <20070906084017.GB3271@mithrandir> References: <20070906084017.GB3271@mithrandir> Message-ID: <46DFC43B.8050406@itc.it> Francesco P. Lovergine wrote on 09/06/2007 10:40 AM: > Could someone confirm that MISR radiance/geometric data need an ad-hoc > importer for grass? I'm going to write down such a tool based on > MISR toolkit, just like to know if i'm wasting my time... > > Maybe yes - did you check GDAL support? In the end everything goes through GDAL into GRASS. That would be the best start to add a driver (if needed). Does 'gdalinfo' fail? Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From rez at touchofmadness.com Thu Sep 6 11:32:52 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Sep 6 11:32:57 2007 Subject: [GRASS-dev] MISR HDF-EOS2 data In-Reply-To: <20070906084017.GB3271@mithrandir> References: <20070906084017.GB3271@mithrandir> Message-ID: <1189071172.3129.79.camel@dev64.localdomain> On Thu, 2007-09-06 at 10:40 +0200, Francesco P. Lovergine wrote: > Could someone confirm that MISR radiance/geometric data need an ad-hoc > importer for grass? I'm going to write down such a tool based on > MISR toolkit, just like to know if i'm wasting my time... There is no module to specifically import the data easily, but r.in.gdal will work. Take a look at the r.in.aster script for details on importing HDF-EOS imagery. -- 73, de Brad KB8UYR/6 From frankie at debian.org Thu Sep 6 12:53:35 2007 From: frankie at debian.org (Francesco P. Lovergine) Date: Thu Sep 6 12:53:35 2007 Subject: [GRASS-dev] MISR HDF-EOS2 data In-Reply-To: <1189071172.3129.79.camel@dev64.localdomain> References: <20070906084017.GB3271@mithrandir> <1189071172.3129.79.camel@dev64.localdomain> Message-ID: <20070906105335.GF3271@mithrandir> On Thu, Sep 06, 2007 at 02:32:52AM -0700, Brad Douglas wrote: > On Thu, 2007-09-06 at 10:40 +0200, Francesco P. Lovergine wrote: > > Could someone confirm that MISR radiance/geometric data need an ad-hoc > > importer for grass? I'm going to write down such a tool based on > > MISR toolkit, just like to know if i'm wasting my time... > > There is no module to specifically import the data easily, but r.in.gdal > will work. > > Take a look at the r.in.aster script for details on importing HDF-EOS > imagery. > > Eh, unfortunately ASTER and MODIS data _are_ supported for geolocation in gdal, so r.in.aster is able to manage a few products directly through gdal_warp. That's not the same for MISR where a few additional metadata also need to be used to extract the true radiance and BRF fields and so on. I think the most clean and effective approach is specializing the HDF4 driver for MISR products in GDAL... -- Francesco P. Lovergine From mlennert at club.worldonline.be Thu Sep 6 13:58:00 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Sep 6 13:58:16 2007 Subject: [GRASS-dev] 6.2.2 packages for Ubuntu Dapper ? Message-ID: <46DFEB48.8030200@club.worldonline.be> Hello, Does anyone know of or even have Ubuntu debs of GRASS 6.2.2 for Dapper ? Even better if QGIS 0.8.1 was also available... Moritz From frankie at debian.org Thu Sep 6 14:51:22 2007 From: frankie at debian.org (Francesco P. Lovergine) Date: Thu Sep 6 14:51:25 2007 Subject: [GRASS-dev] 6.2.2 packages for Ubuntu Dapper ? In-Reply-To: <46DFEB48.8030200@club.worldonline.be> References: <46DFEB48.8030200@club.worldonline.be> Message-ID: <20070906125122.GG3271@mithrandir> On Thu, Sep 06, 2007 at 01:58:00PM +0200, Moritz Lennert wrote: > > Does anyone know of or even have Ubuntu debs of GRASS 6.2.2 for Dapper ? > Even better if QGIS 0.8.1 was also available... > I think basically backports sources for etch at backports.org can be used without major issues also for Dapper. I think 0.8.1 will be available within a reasonable time also, after entering lenny. -- Francesco P. Lovergine From woklist at kyngchaos.com Thu Sep 6 17:30:25 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Sep 6 17:30:52 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: References: Message-ID: <8C6337B2-2D21-41B0-9EE4-98FF05FBC8EF@kyngchaos.com> On Sep 6, 2007, at 2:05 AM, Michael Barton wrote: > I'm printing on an inkjet printer (Epson) connected to another > computer to > which I'm networked. However, this works for other printing with no > problems--including using gs to change the PS file to a PNG and > then sending > the PNG to lpr. > > Michael Does the Epson OSX printer driver handle postscript (in the past they've required a 3rd-party PS RIP)? CUPS (lpr) itself doesn't do any PS rendering, just hands the job to the correct printer driver (as far as I know). Or it at least adds printer-specific PS data to the job. If it does render PS for non-PS printers, it may be crude. I just remembered that Gimp-Print, which provides postscript printing to many non-PS printers, was renamed to Gutenprint, and an installer is included in Tiger (ie it's another "printer drivers" option in the Tiger installer, and it might still be called Gimp-print). This would allow proper PS printing if the Epson driver isn't PS. ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070906/5ed5e18d/attachment.html From michael.barton at asu.edu Thu Sep 6 17:54:37 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Sep 6 17:54:59 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: <8C6337B2-2D21-41B0-9EE4-98FF05FBC8EF@kyngchaos.com> Message-ID: Well, if I open the same PS file in preview and print it through the regular Mac print system on this printer it looks fine -- centered, not truncated, the correct size, etc. Does that mean anything in this context? Michael On 9/6/07 8:30 AM, "William Kyngesburye" wrote: > On Sep 6, 2007, at 2:05 AM, Michael Barton wrote: > >> I'm printing on an inkjet printer (Epson) connected to another computer to >> which I'm networked. However, this works for other printing with no >> problems--including using gs to change the PS file to a PNG and then sending >> the PNG to lpr. >> >> Michael > > Does the Epson OSX printer driver handle postscript (in the past they've > required a 3rd-party PS RIP)?? CUPS (lpr) itself doesn't do any PS rendering, > just hands the job to the correct printer driver (as far as I know).? Or it at > least adds printer-specific PS data to the job.? If it does render PS for > non-PS printers, it may be crude. > > I just remembered that Gimp-Print, which provides postscript printing to many > non-PS printers, was renamed to Gutenprint, and an installer is included in > Tiger (ie it's another "printer drivers" option in the Tiger installer, and it > might still be called Gimp-print).? This would allow proper PS printing if the > Epson driver isn't PS. > > > ----- > William Kyngesburye? > http://www.kyngchaos.com/ > > Earth: "Mostly harmless" > > - revised entry in the HitchHiker's Guide to the Galaxy > > > > __________________________________________ 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/20070906/2316fcec/attachment.html From woklist at kyngchaos.com Thu Sep 6 18:44:42 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Sep 6 18:45:08 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: References: Message-ID: <15405149-8C19-44D8-B4D5-79761CC81B38@kyngchaos.com> Preview might know what to send to non-PS printers, or the Epson drivers might be PS now (I had one many years ago, when they were definitely not PS). Or, given the PDF-nature of much of OSX, Preview might be sending a PDF to the printer. I haven't used ps.map before - do you have something I can try to generate a simple ps map from Spearfish? I can try lpr on our HP printers. On Sep 6, 2007, at 10:54 AM, Michael Barton wrote: > Well, if I open the same PS file in preview and print it through > the regular Mac print system on this printer it looks fine -- > centered, not truncated, the correct size, etc. Does that mean > anything in this context? > > Michael > ----- 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 woklist at kyngchaos.com Thu Sep 6 22:08:22 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Sep 6 22:08:50 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: References: Message-ID: <44213A52-617D-4F3E-AB04-CB09076DE2D2@kyngchaos.com> Ah, got it on the first try (Color Laserjet 8550). I used: lpr -o position=center mapout.ps I figured that the left/right/top/bottom params were unnecessary since the center param would set those implicitly. When I opened it in Preview, the message about converting PS to PDF tells me that that is probably why it works from Preview to the Epson - the Epson drivers, or maybe CUPS, can render PDF (the core of the OSX display system, and much if not all of the printing, is PDF- based). And many modern printers support PDF natively. Maybe if you can generate a PDF from Tcl and pass that to lpr? Or look at that Gimp/Guten-print driver for your Epson. On Sep 6, 2007, at 2:34 PM, Michael Barton wrote: > William, > > I've put the PS map into > . Let me know if > you can get it to print nicely on your HP. > > Michael ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From michael.barton at asu.edu Fri Sep 7 01:01:12 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 7 01:01:35 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: <44213A52-617D-4F3E-AB04-CB09076DE2D2@kyngchaos.com> Message-ID: On 9/6/07 1:08 PM, "William Kyngesburye" wrote: > Ah, got it on the first try (Color Laserjet 8550). I used: > > lpr -o position=center mapout.ps I tried that first and it didn't work. So I added the margin settings, which equally did nothing. This suggests to me that the problems might well be in my printer and setup. This will make it very difficult to test any updates to the mapprint.tcl module. If I make a change (I think I'll just use the -o position-center setting like you did) and send the file to you, can you drop it in and try it out? Michael > > I figured that the left/right/top/bottom params were unnecessary > since the center param would set those implicitly. > > When I opened it in Preview, the message about converting PS to PDF > tells me that that is probably why it works from Preview to the Epson > - the Epson drivers, or maybe CUPS, can render PDF (the core of the > OSX display system, and much if not all of the printing, is PDF- > based). And many modern printers support PDF natively. > > Maybe if you can generate a PDF from Tcl and pass that to lpr? > > Or look at that Gimp/Guten-print driver for your Epson. > > On Sep 6, 2007, at 2:34 PM, Michael Barton wrote: > >> William, >> >> I've put the PS map into >> . Let me know if >> you can get it to print nicely on your HP. >> >> Michael > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "Mon Dieu! but they are all alike. Cheating, murdering, lying, > fighting, and all for things that the beasts of the jungle would not > deign to possess - money to purchase the effeminate pleasures of > weaklings. And yet withal bound down by silly customs that make them > slaves to their unhappy lot while firm in the belief that they be the > lords of creation enjoying the only real pleasures of existence.... > > - the wisdom of Tarzan > > __________________________________________ 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 michael.barton at asu.edu Fri Sep 7 01:02:38 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 7 01:02:50 2007 Subject: [GRASS-dev] Re: Add addon menu files to Tcl GUI menu? In-Reply-To: <5BF0E8B6-B1A5-4E6F-A487-0C33D6FE4B00@kyngchaos.com> Message-ID: William, I don't currently have a way to get these into gmmenu.tcl in such a way as to have them show up on a Mac but not be a problem on other systems that don't have this new feature. Do you have any suggestions along these lines? Michael On 9/4/07 8:48 AM, "William Kyngesburye" wrote: > Something that got pushed back in my head, I'd like to get this in > the 6.3 release. I have the OSX app startup generating tcl menu > files (similar to GEM menu files) for the OSX addon folders. Can you > get these into gmmenu.tcl? > > OSX app addon menus are in: > > $HOME/Library/GRASS/$GRASS_VER/Modules/etc/gm/addons > > where $GRASS_VER is the major.minor version of the running GRASS. > They are named with a .menu extension and are generated automatically > on startup. I'm thinking there should also be a user-customizable > menu that won't get zapped on every startup, maybe etc/gm/user.menu. > > When you settle on a way to extend the python gui menu, I'll do a > similar thing for that. > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > All generalizations are dangerous, even this one. > > __________________________________________ 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 woklist at kyngchaos.com Fri Sep 7 01:38:36 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Sep 7 01:39:06 2007 Subject: [GRASS-dev] Re: [GRASSGUI] Re: Add addon menu files to Tcl GUI menu? In-Reply-To: References: Message-ID: <9EB53A34-36C4-460B-819C-470802ADC988@kyngchaos.com> From what I can understand of the logic in gmmenu.tcl, it tests for the GEM menu dir (etc/gm/Xtns), so it ignores it if it doesn't exist. Then it concats all .gem files there. The same method could be used for the OSX user folder, since it will not exist on other systems. Though if this user support setup is adopted by other systems it could be easily extended to them. To make it system-agnostic, instead of hardwiring the OSX path (mainly the Library/ part, other systems could be .grass6/ on linux and whatever the user prefs or support folder is in a Windows user's home), it might try to use $GRASS_ADDON_ETC which would be set at startup per system (either init.sh or the initial grass script startup - currently the OSX startup sets this). This can have multiple paths separated by colons, like $PATH. Just check each path in $GRASS_ADDON_ETC for menu files in gm/addons. I could probably duplicate that block and figure out how to handle a single hardwired path, but I'm not sure about splitting a string and adding a loop for the resulting pieces. On Sep 6, 2007, at 6:02 PM, Michael Barton wrote: > William, > > I don't currently have a way to get these into gmmenu.tcl in such a > way as > to have them show up on a Mac but not be a problem on other systems > that > don't have this new feature. Do you have any suggestions along > these lines? > > Michael > > > On 9/4/07 8:48 AM, "William Kyngesburye" > wrote: > >> Something that got pushed back in my head, I'd like to get this in >> the 6.3 release. I have the OSX app startup generating tcl menu >> files (similar to GEM menu files) for the OSX addon folders. Can you >> get these into gmmenu.tcl? >> >> OSX app addon menus are in: >> >> $HOME/Library/GRASS/$GRASS_VER/Modules/etc/gm/addons >> >> where $GRASS_VER is the major.minor version of the running GRASS. >> They are named with a .menu extension and are generated automatically >> on startup. I'm thinking there should also be a user-customizable >> menu that won't get zapped on every startup, maybe etc/gm/user.menu. >> >> When you settle on a way to extend the python gui menu, I'll do a >> similar thing for that. >> >> ----- >> William Kyngesburye >> http://www.kyngchaos.com/ >> >> All generalizations are dangerous, even this one. >> ----- 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 grass-dev at grass.itc.it Fri Sep 7 03:41:15 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Fri Sep 7 03:34:35 2007 Subject: [GRASS-dev] [grass-web I][475] Version numbers inconsistent Message-ID: <20070907014115.AF2BC40203@pyrosoma.intevation.org> web I item #475, was opened at 2007-09-07 01:41 Status: Open Priority: 3 Submitted By: Iuri Gavronski (iuri_gavronski) Assigned to: Nobody (None) Summary: Version numbers inconsistent Issue status: None Site section: Download Site timestamp (YYMMDD): Initial Comment: I am trying to download Windows GRASS using Cygwin setup, using the instructions on http://grass.itc.it/grass62/binary/mswindows/ but the download fails. Looking at the files listing: grass-6.2.2-2.cygwin.tar.bz2 Looking at the setup.ini: @ grass sdesc: "GRASS - Geographic Resources Analysis Support System" category: Database requires: cygwin gdal libintl8 libiconv2 freetype2 libpng12 fftw3 libncurses8 proj readline libtiff5 xterm xorg-x11-base lesstif tcltk-grass version: 6.2.2-1 install: grass-6.2.2-1.cygwin.tar.bz2 16313625 5506d382b1e1b010b66677cb99991bb8 The last number is different on the file on setup.ini and the file that is actually on the directory. Please update setup.ini Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=210&aid=475&group_id=21 From hamish_nospam at yahoo.com Fri Sep 7 06:12:06 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 7 06:12:15 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: References: <44213A52-617D-4F3E-AB04-CB09076DE2D2@kyngchaos.com> Message-ID: <20070907161206.8d7acae6.hamish_nospam@yahoo.com> lpr (lpd) should take .ps output directly regardless of the printer being PostScript enabled or not. If not PS enabled, the driver takes care of translating it. I expect the ps -> png conversion is done at the bounding box not the page size, which crops off the margins from the original print and resets the .png image to the top corner. PostScript coords are given in inches from the corner of the page. PNG files are like a GRASS x,y location with a 0,0 corner. ie by doing the conversion you are throwing away the "georeferencing" in the PS file. see earlier discussions about the meaning of PostScript/EPS bounding boxes WRT r.out.file & the EPS driver. ? Hamish From hamish_nospam at yahoo.com Fri Sep 7 06:14:50 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 7 06:14:55 2007 Subject: [GRASS-dev] Add addon menu files to Tcl GUI menu? In-Reply-To: <5BF0E8B6-B1A5-4E6F-A487-0C33D6FE4B00@kyngchaos.com> References: <5BF0E8B6-B1A5-4E6F-A487-0C33D6FE4B00@kyngchaos.com> Message-ID: <20070907161450.91149565.hamish_nospam@yahoo.com> William Kyngesburye wrote: > > Something that got pushed back in my head, I'd like to get this in > the 6.3 release. I have the OSX app startup generating tcl menu > files (similar to GEM menu files) for the OSX addon folders. Can you > get these into gmmenu.tcl? Is it possible to share the Extensions menu with GEM? ie it's cleaner to use a single hook into the menu system versus a number of duplicate implementations. Hamish From michael.barton at asu.edu Fri Sep 7 06:50:49 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 7 06:51:21 2007 Subject: [GRASS-dev] Re: [GRASS-user] need help with mac os x installation In-Reply-To: <20070907161206.8d7acae6.hamish_nospam@yahoo.com> Message-ID: On 9/6/07 9:12 PM, "Hamish" wrote: > lpr (lpd) should take .ps output directly regardless of the printer > being PostScript enabled or not. If not PS enabled, the driver takes care > of translating it. > > I expect the ps -> png conversion is done at the bounding box not the > page size, which crops off the margins from the original print and resets > the .png image to the top corner. PostScript coords are given in inches > from the corner of the page. PNG files are like a GRASS x,y location with > a 0,0 corner. ie by doing the conversion you are throwing away the > "georeferencing" in the PS file. Actually the problem was the other way around. I got good results sending the PNG to lpr but bad results sending the PS file to lpr. Interestingly, William Kyngesbury tried the same PS file on a different printer and it looked fine. So it may be a function my Epson inkjet here at home. If so, this will make it difficult for me to test changes to the print routines in TclTk. Michael > > see earlier discussions about the meaning of PostScript/EPS bounding > boxes WRT r.out.file & the EPS driver. > > > ? > 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 michael.barton at asu.edu Fri Sep 7 07:16:56 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 7 07:17:22 2007 Subject: [GRASS-dev] Re: Gm::errmsg not defined in lib/gtcltk/gronsole.tcl In-Reply-To: <20070907050115.GB24456@bartok.itc.it> Message-ID: I took out this error reporting message box. It is not needed and clearly causes occasional problems. Michael On 9/6/07 10:01 PM, "Markus Neteler" wrote: > Michael, > > since I didn't see a change I guess so that it remains. > If you run a command (v.info somemap) and then, in the output > window click on the grey across (like rotated x) then > you should get the tcl error. > > Markus > > On Thu, Sep 06, 2007 at 09:59:01PM -0700, Michael Barton wrote: >> Markus, >> >> Is this still a problem? I don't source gm.tcl in gronsole.tcl because >> gronsole.tcl is called by gm.tcl. So there should be no need to source >> gm.tcl. >> >> I'm running this now in x11 with no problem at all. Gm::errmsg is only being >> called in 2 places, neither critical I think. If this is a general problem, >> I can just take it out. >> >> Michael >> >> >> On 9/6/07 5:34 AM, "Markus Neteler" wrote: >> >>> Michael, >>> >>> I am currently getting errors due to Gm::errmsg not defined in >>> lib/gtcltk/gronsole.tcl >>> (but used). Including >>> source $env(GISBASE)/etc/gm/gm.tcl >>> >>> leads to an infinite loop... Maybe Gm::errmsg definition needs >>> to go into a different file? >>> >>> Markus >>> >>> ------------------ >>> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler >>> ITC -> since 1 March 2007 Fondazione Bruno Kessler >>> ------------------ >> >> __________________________________________ >> 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 neteler at itc.it Fri Sep 7 14:10:40 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Sep 7 14:10:44 2007 Subject: [GRASS-dev] new std options for files In-Reply-To: <20070322150430.08c004bb.hamish_nospam@yahoo.com> References: <20070321175131.60cf41d9.hamish_nospam@yahoo.com> <20070321181925.39048f2b.hamish_nospam@yahoo.com> <17921.29100.35768.91243@cerise.gclements.plus.com> <20070322150430.08c004bb.hamish_nospam@yahoo.com> Message-ID: <12554008.post@talk.nabble.com> HamishB wrote: > >> Hamish wrote: >> > as earlier mentioned* I'd like to change the Option struct to >> > rationalize the ->description and ->label parts. >> > >> > currently, if a label is defined it becomes the description, and the >> > description becomes the tooltip. This is non-intuitive and >> > inconsistent. > ... > so we have three possible levels of verbosity for an option description: > ->label: a few words > ->description: a sentence > ->tooltip: a paragraph/short example showing format (doesn't exist) > > I think it is a good idea to keep ->description (as commonly used now) > short and to the point, ie shorter than ~65 chars (so it fits on one > line). Certainly the label should quite short. It looks bad when the > description is line wrapped in --help, or colliding with the right side > of the GUI window. > I would like to bring up this issue again (since I am confused): Currently only about 10 modules use module->label In the GUI pop up it is even printed in the wrong vertical order if above definition is true + there is ugly vertical space between these two lines. Question: what's the point of module->label? Take it out or modify 290+ modules? We need some consistency... Is there anything using module->label|description as tooltip? confused (about why we need two things to do nearly the same), Markus -- View this message in context: http://www.nabble.com/new-std-options-for-files-tf3438602.html#a12554008 Sent from the Grass - Dev mailing list archive at Nabble.com. From landa.martin at gmail.com Fri Sep 7 14:18:50 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Sep 7 14:18:54 2007 Subject: [GRASS-dev] new std options for files In-Reply-To: <12554008.post@talk.nabble.com> References: <20070321175131.60cf41d9.hamish_nospam@yahoo.com> <20070321181925.39048f2b.hamish_nospam@yahoo.com> <17921.29100.35768.91243@cerise.gclements.plus.com> <20070322150430.08c004bb.hamish_nospam@yahoo.com> <12554008.post@talk.nabble.com> Message-ID: Hi, you are not only one confused Markus by this;-) The label/description stuff is a bit illogical. I suppose to change in this way: * Use 'description' as short sentence describing module/flag/option (must be defined). * Rename 'label' to 'tooltip'. Martin 2007/9/7, Markus Neteler : > > > HamishB wrote: > > > >> Hamish wrote: > >> > as earlier mentioned* I'd like to change the Option struct to > >> > rationalize the ->description and ->label parts. > >> > > >> > currently, if a label is defined it becomes the description, and the > >> > description becomes the tooltip. This is non-intuitive and > >> > inconsistent. > > ... > > so we have three possible levels of verbosity for an option description: > > ->label: a few words > > ->description: a sentence > > ->tooltip: a paragraph/short example showing format (doesn't exist) > > > > I think it is a good idea to keep ->description (as commonly used now) > > short and to the point, ie shorter than ~65 chars (so it fits on one > > line). Certainly the label should quite short. It looks bad when the > > description is line wrapped in --help, or colliding with the right side > > of the GUI window. > > > > I would like to bring up this issue again (since I am confused): > > Currently only about 10 modules use > module->label > > In the GUI pop up it is even printed in the wrong vertical order > if above definition is true + there is ugly vertical space between > these two lines. > > Question: what's the point of module->label? Take it out or > modify 290+ modules? We need some consistency... > Is there anything using module->label|description as tooltip? > > confused (about why we need two things to do nearly the same), > Markus > -- > View this message in context: http://www.nabble.com/new-std-options-for-files-tf3438602.html#a12554008 > Sent from the Grass - Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 Sep 7 15:40:19 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Fri Sep 7 15:33:32 2007 Subject: [GRASS-dev] [grass-code I][478] tcl/tk gui startup screen launches grass even when 'Exit' is pushed Message-ID: <20070907134019.4D8304027C@pyrosoma.intevation.org> code I item #478, was opened at 2007-09-07 15:40 Status: Open Priority: 3 Submitted By: Moritz Lennert (moritz) Assigned to: Nobody (None) Summary: tcl/tk gui startup screen launches grass even when 'Exit' is pushed Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: gis.m Operating system: Linux Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070903 Initial Comment: When I launch grass with -tcl/tk, but then press Exit on the startup screen, GRASS starts anyhow, instead of exiting. Moritz ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=478&group_id=21 From woklist at kyngchaos.com Fri Sep 7 15:55:56 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Sep 7 15:56:25 2007 Subject: [GRASS-dev] Add addon menu files to Tcl GUI menu? In-Reply-To: <20070907161450.91149565.hamish_nospam@yahoo.com> References: <5BF0E8B6-B1A5-4E6F-A487-0C33D6FE4B00@kyngchaos.com> <20070907161450.91149565.hamish_nospam@yahoo.com> Message-ID: <7FF69DAF-5D59-4A70-A026-85EEA6E4084F@kyngchaos.com> That pretty much what I'm thinking - adding it to the Xtns menu below any GEM stuff. And I'm using (I think) the same format in the menu files, so the same code could be used to construct the menus, with a little change. On Sep 6, 2007, at 11:14 PM, Hamish wrote: > William Kyngesburye wrote: >> >> Something that got pushed back in my head, I'd like to get this in >> the 6.3 release. I have the OSX app startup generating tcl menu >> files (similar to GEM menu files) for the OSX addon folders. Can you >> get these into gmmenu.tcl? > > > Is it possible to share the Extensions menu with GEM? ie it's cleaner > to use a single hook into the menu system versus a number of duplicate > implementations. > > > Hamish ----- 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 grass-dev at grass.itc.it Fri Sep 7 21:19:06 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Fri Sep 7 21:12:18 2007 Subject: [GRASS-dev] [grass-code I][479] Gis.m produces error upon saving current workspace to a grc file Message-ID: <20070907191906.6F66040282@pyrosoma.intevation.org> code I item #479, was opened at 2007-09-07 16:19 Status: Open Priority: 3 Submitted By: Eric Patton (eric) Assigned to: Nobody (None) Summary: Gis.m produces error upon saving current workspace to a grc file Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: gis.m Operating system: Linux Operating system version: Ubuntu - GNU/Linux GRASS CVS checkout date, if applies (YYMMDD): 070907 Initial Comment: Upon attempting to save my current workspace to a grc file while using Gis.m, I get the attached error. The error recurs no matter how many map layers I have displayed in the GIS Manager window. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=479&group_id=21 From glynn at gclements.plus.com Fri Sep 7 22:30:37 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 7 22:30:43 2007 Subject: [GRASS-dev] error reporting In-Reply-To: References: <18142.55554.402938.602868@cerise.gclements.plus.com> Message-ID: <18145.46317.84886.748617@cerise.gclements.plus.com> Michael Barton wrote: > > If it's done here, each arg should probably be translated > > individually; the caller can always join any arguments which should be > > translated as a whole. Even then, there's no option to have a portion > > which doesn't get translated. > > Like this??? > > proc Gm::errmsg { error args } { > # send error report and optional message (args) to tk_messageBox > set message "" > for arg in $args { > > if { $arg != "" } { > append message "$arg " > } > } > > append message ": " > > tk_messageBox -type ok -icon error -title [G_msg "Error"] \ > -message "$message[G_msg $error]" > uplevel 1 return > > }; I meant to pass each individual arg to G_msg then join the result, i.e. replace: if { $args != ""} { set message [G_msg [join $args]] append message ": " } with: if { $args != ""} { set trans {} foreach msg $args { lappend trans [G_msg $msg] } set message [G_msg [join $trans]] append message ": " } > You are right. A downside of enforcing translation within the function, > rather than relying on it to be done in the original script, is that the > whole thing gets translated. I'm not sure if this is really a problem with > short, optional error messages in reality. The problem occurs if the error message includes variable components, e.g. "unable to open $filename" or "error executing $prog". Only the fixed portions should be translated (otherwise the message catalogue would need an entry for every possible string), then the variable portions should be inserted afterwards. If the variable portions occur in the middle of the string, you would want something like: set template [G_msg {unable to open $filename for reading}] set message [subst -nobackslashes -nocommands $template] Actually, this could be done in the error handling procedure, using "uplevel" to allow "subst" to use variables from the caller. Ultimately, I still think that it's better to have the caller perform the translation. In C code, the _() macro is always applied to the literal string; we don't make G_fatal_error() call _(). Apart from anything else, it makes it easier to identify strings which require translation ("grep G_msg"). -- Glynn Clements From glynn at gclements.plus.com Fri Sep 7 22:32:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 7 22:32:51 2007 Subject: [GRASS-dev] autotools In-Reply-To: <12515625.post@talk.nabble.com> References: <1189039522.3129.5.camel@dev64.localdomain> <12515625.post@talk.nabble.com> Message-ID: <18145.46448.531423.971425@cerise.gclements.plus.com> Markus Neteler wrote: > > What versions of autoconf, automake, etc. is everyone using? When I do > > autoreconf, I get errors. The generated configure script has extraneous > > 'fi' statements. > > > > It seems to be a problem with certain nested AC_CHECK_LIB() calls. > > Removing them allows me to progress further (curses, mysql), but > > obviously that's not the right way to go. > > > > Is there some version specific autotools calls I'm not aware of? > > > > autoconf: 2.59 > > automake: 1.9.6 > > libtool: 1.5 > > AFAIK we use autoconf-2.13 and nothing else. That's correct. GRASS requires autoconf 2.13; later versions aren't remotely compatible. We don't use automake or libtool. -- Glynn Clements From glynn at gclements.plus.com Fri Sep 7 22:57:17 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 7 22:57:19 2007 Subject: [GRASS-dev] new std options for files In-Reply-To: <12554008.post@talk.nabble.com> References: <20070321175131.60cf41d9.hamish_nospam@yahoo.com> <20070321181925.39048f2b.hamish_nospam@yahoo.com> <17921.29100.35768.91243@cerise.gclements.plus.com> <20070322150430.08c004bb.hamish_nospam@yahoo.com> <12554008.post@talk.nabble.com> Message-ID: <18145.47917.231126.679080@cerise.gclements.plus.com> Markus Neteler wrote: > >> Hamish wrote: > >> > as earlier mentioned* I'd like to change the Option struct to > >> > rationalize the ->description and ->label parts. > >> > > >> > currently, if a label is defined it becomes the description, and the > >> > description becomes the tooltip. This is non-intuitive and > >> > inconsistent. > > ... > > so we have three possible levels of verbosity for an option description: > > ->label: a few words > > ->description: a sentence > > ->tooltip: a paragraph/short example showing format (doesn't exist) > > > > I think it is a good idea to keep ->description (as commonly used now) > > short and to the point, ie shorter than ~65 chars (so it fits on one > > line). Certainly the label should quite short. It looks bad when the > > description is line wrapped in --help, or colliding with the right side > > of the GUI window. > > I would like to bring up this issue again (since I am confused): > > Currently only about 10 modules use > module->label > > In the GUI pop up it is even printed in the wrong vertical order > if above definition is true + there is ugly vertical space between > these two lines. > > Question: what's the point of module->label? For use as a label in the GUI in case the description is too verbose. > Take it out or > modify 290+ modules? We need some consistency... Leave it as-is. > Is there anything using module->label|description as tooltip? Any option which has a separate label will have the description as the tooltip. > confused (about why we need two things to do nearly the same), Some descriptions are too verbose to use as labels in the GUI. -- Glynn Clements From michael.barton at asu.edu Sat Sep 8 00:49:45 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 8 00:50:08 2007 Subject: [GRASS-dev] error reporting In-Reply-To: <18145.46317.84886.748617@cerise.gclements.plus.com> Message-ID: OK. I see what you mean. Michael On 9/7/07 1:30 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>> If it's done here, each arg should probably be translated >>> individually; the caller can always join any arguments which should be >>> translated as a whole. Even then, there's no option to have a portion >>> which doesn't get translated. >> >> Like this??? >> >> proc Gm::errmsg { error args } { >> # send error report and optional message (args) to tk_messageBox >> set message "" >> for arg in $args { >> >> if { $arg != "" } { >> append message "$arg " >> } >> } >> >> append message ": " >> >> tk_messageBox -type ok -icon error -title [G_msg "Error"] \ >> -message "$message[G_msg $error]" >> uplevel 1 return >> >> }; > > I meant to pass each individual arg to G_msg then join the result, > i.e. replace: > > if { $args != ""} { > set message [G_msg [join $args]] > append message ": " > } > > with: > > if { $args != ""} { > set trans {} > foreach msg $args { > lappend trans [G_msg $msg] > } > set message [G_msg [join $trans]] > append message ": " > } > > >> You are right. A downside of enforcing translation within the function, >> rather than relying on it to be done in the original script, is that the >> whole thing gets translated. I'm not sure if this is really a problem with >> short, optional error messages in reality. > > The problem occurs if the error message includes variable components, > e.g. "unable to open $filename" or "error executing $prog". > > Only the fixed portions should be translated (otherwise the message > catalogue would need an entry for every possible string), then the > variable portions should be inserted afterwards. > > If the variable portions occur in the middle of the string, you would > want something like: > > set template [G_msg {unable to open $filename for reading}] > set message [subst -nobackslashes -nocommands $template] > > Actually, this could be done in the error handling procedure, using > "uplevel" to allow "subst" to use variables from the caller. > > Ultimately, I still think that it's better to have the caller perform > the translation. In C code, the _() macro is always applied to the > literal string; we don't make G_fatal_error() call _(). > > Apart from anything else, it makes it easier to identify strings which > require translation ("grep G_msg"). __________________________________________ 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 mlennert at club.worldonline.be Sat Sep 8 08:04:02 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sat Sep 8 07:58:29 2007 Subject: [GRASS-dev] 6.2.2 packages for Ubuntu Dapper ? In-Reply-To: <20070906125122.GG3271@mithrandir> References: <46DFEB48.8030200@club.worldonline.be> <20070906125122.GG3271@mithrandir> Message-ID: <46E23B52.30002@club.worldonline.be> Francesco P. Lovergine wrote: > On Thu, Sep 06, 2007 at 01:58:00PM +0200, Moritz Lennert wrote: >> Does anyone know of or even have Ubuntu debs of GRASS 6.2.2 for Dapper ? >> Even better if QGIS 0.8.1 was also available... >> > > I think basically backports sources for etch at backports.org can be used > without major issues also for Dapper. I think 0.8.1 will be available > within a reasonable time also, after entering lenny. backports has GRASS 6.2.1, not 6.2.2. That is in Sid, don't know how long it will take to get into lenny and then to get backported... QGIS is completely absent from backports, and Sid has 0.8.0... How long do you think it will take for 0.8.1 to appear in lenny ? 0.9.0 is about to come out as well... Moritz From frankie at debian.org Sat Sep 8 11:30:02 2007 From: frankie at debian.org (Francesco P. Lovergine) Date: Sat Sep 8 11:30:07 2007 Subject: [GRASS-dev] 6.2.2 packages for Ubuntu Dapper ? In-Reply-To: <46E23B52.30002@club.worldonline.be> References: <46DFEB48.8030200@club.worldonline.be> <20070906125122.GG3271@mithrandir> <46E23B52.30002@club.worldonline.be> Message-ID: <20070908093000.GA3938@ba.issia.cnr.it> On Sat, Sep 08, 2007 at 08:04:02AM +0200, Moritz Lennert wrote: > > backports has GRASS 6.2.1, not 6.2.2. That is in Sid, don't know how long > it will take to get into lenny and then to get backported... > Backports.org is limited to what's present in testing at the time of building. That avoids major breakages with unsufficiently tested stuff. If you need on-the-edge programs you need sid. -- Francesco P. Lovergine From michael.barton at asu.edu Sun Sep 9 00:26:29 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 9 00:26:50 2007 Subject: [GRASS-dev] animation missing pnmscale Message-ID: Glynn, I've made a lot of progress getting your TclTk replacement for Xganim into the GUI. However, I haven't been able to make it animate anything. I finally tracked this down to the line... catch {exec r.out.ppm input=$name output=- 2>@stderr | pnmscale $vscale >$tmpfile 2>@stderr} This requires a program pnmscale. I don't have pnmscale. Does it comes with GRASS and I somehow don't have it or is it a 3rd party program? 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/20070908/fc400128/attachment.html From hmitaso at unity.ncsu.edu Sun Sep 9 00:59:56 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sun Sep 9 01:00:00 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: References: Message-ID: <83EEAC65-ADCC-4560-A959-92D08F0636D7@unity.ncsu.edu> On Sep 8, 2007, at 6:26 PM, Michael Barton wrote: > Glynn, > > I've made a lot of progress getting your TclTk replacement for > Xganim into the GUI. However, I haven't been able to make it > animate anything. I finally tracked this down to the line... > > catch {exec r.out.ppm input=$name output=- 2>@stderr | pnmscale > $vscale >$tmpfile 2>@stderr} > > This requires a program pnmscale. I don't have pnmscale. Does it > comes with GRASS and I somehow don't have it or is it a 3rd party > program? Michael, you have to install it http://netpbm.sourceforge.net/doc/index.html Also I found in the pnmscale manual: pnmscale was obsoleted by pamscale, introduced with Netpbm 10.20 (January 2004) I have it on RedHat linux box but I don't have it on Mac or Ubuntu so apparently you have to install it yourself. Helena > > 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 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From woklist at kyngchaos.com Sun Sep 9 01:27:55 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Sep 9 01:28:03 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: References: Message-ID: Check the source/macosx readme. I have build instructions there for the netpbm tools source (it's an annoying one to build). Knowing this tool is needed, I'll add it to my bundling for binaries when you get the xganim.tcl working (I already bundle a few other netpbm tools for other GRASS modules). On Sep 8, 2007, at 5:26 PM, Michael Barton wrote: > Glynn, > > I've made a lot of progress getting your TclTk replacement for > Xganim into the GUI. However, I haven't been able to make it > animate anything. I finally tracked this down to the line... > > catch {exec r.out.ppm input=$name output=- 2>@stderr | pnmscale > $vscale >$tmpfile 2>@stderr} > > This requires a program pnmscale. I don't have pnmscale. Does it > comes with GRASS and I somehow don't have it or is it a 3rd party > program? > > Michael > ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From michael.barton at asu.edu Sun Sep 9 06:00:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 9 06:00:57 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: Message-ID: I thought that of the (main?) goals of doing a TclTk animation replacement for Xganim was so that we no longer needed motif/lesstif as a GRASS dependency. While the TclTk animator is nicer looking than xganim, if pnmscale is required, we just replace one dependency with another one. Maybe there is another way to do this??? Michael On 9/8/07 4:27 PM, "William Kyngesburye" wrote: > Check the source/macosx readme. I have build instructions there for > the netpbm tools source (it's an annoying one to build). Knowing > this tool is needed, I'll add it to my bundling for binaries when you > get the xganim.tcl working (I already bundle a few other netpbm tools > for other GRASS modules). > > On Sep 8, 2007, at 5:26 PM, Michael Barton wrote: > >> Glynn, >> >> I've made a lot of progress getting your TclTk replacement for >> Xganim into the GUI. However, I haven't been able to make it >> animate anything. I finally tracked this down to the line... >> >> catch {exec r.out.ppm input=$name output=- 2>@stderr | pnmscale >> $vscale >$tmpfile 2>@stderr} >> >> This requires a program pnmscale. I don't have pnmscale. Does it >> comes with GRASS and I somehow don't have it or is it a 3rd party >> program? >> >> Michael >> > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > [Trillian] What are you supposed to do WITH a maniacally depressed > robot? > > [Marvin] You think you have problems? What are you supposed to do > if you ARE a maniacally depressed robot? No, don't try and answer, > I'm 50,000 times more intelligent than you and even I don't know the > answer... > > - HitchHiker's Guide to the Galaxy > > __________________________________________ 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 Sun Sep 9 06:09:31 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 9 06:09:51 2007 Subject: [GRASS-dev] error reporting In-Reply-To: <18145.46317.84886.748617@cerise.gclements.plus.com> Message-ID: I redid this last night to follow this model. It's in the cvs now. Michael On 9/7/07 1:30 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>> If it's done here, each arg should probably be translated >>> individually; the caller can always join any arguments which should be >>> translated as a whole. Even then, there's no option to have a portion >>> which doesn't get translated. >> >> Like this??? >> >> proc Gm::errmsg { error args } { >> # send error report and optional message (args) to tk_messageBox >> set message "" >> for arg in $args { >> >> if { $arg != "" } { >> append message "$arg " >> } >> } >> >> append message ": " >> >> tk_messageBox -type ok -icon error -title [G_msg "Error"] \ >> -message "$message[G_msg $error]" >> uplevel 1 return >> >> }; > > I meant to pass each individual arg to G_msg then join the result, > i.e. replace: > > if { $args != ""} { > set message [G_msg [join $args]] > append message ": " > } > > with: > > if { $args != ""} { > set trans {} > foreach msg $args { > lappend trans [G_msg $msg] > } > set message [G_msg [join $trans]] > append message ": " > } > > >> You are right. A downside of enforcing translation within the function, >> rather than relying on it to be done in the original script, is that the >> whole thing gets translated. I'm not sure if this is really a problem with >> short, optional error messages in reality. > > The problem occurs if the error message includes variable components, > e.g. "unable to open $filename" or "error executing $prog". > > Only the fixed portions should be translated (otherwise the message > catalogue would need an entry for every possible string), then the > variable portions should be inserted afterwards. > > If the variable portions occur in the middle of the string, you would > want something like: > > set template [G_msg {unable to open $filename for reading}] > set message [subst -nobackslashes -nocommands $template] > > Actually, this could be done in the error handling procedure, using > "uplevel" to allow "subst" to use variables from the caller. > > Ultimately, I still think that it's better to have the caller perform > the translation. In C code, the _() macro is always applied to the > literal string; we don't make G_fatal_error() call _(). > > Apart from anything else, it makes it easier to identify strings which > require translation ("grep G_msg"). __________________________________________ 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 woklist at kyngchaos.com Sun Sep 9 06:25:55 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Sep 9 06:26:00 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: References: Message-ID: some netpbm tools are already needed by a couple other script modules, so it's not a new requirement. But it seems it is not mentioned in the GRASS requirements. On Sep 8, 2007, at 11:00 PM, Michael Barton wrote: > I thought that of the (main?) goals of doing a TclTk animation > replacement > for Xganim was so that we no longer needed motif/lesstif as a GRASS > dependency. While the TclTk animator is nicer looking than xganim, if > pnmscale is required, we just replace one dependency with another > one. Maybe > there is another way to do this??? > > Michael ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy From grass-dev at grass.itc.it Sun Sep 9 15:44:21 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Sun Sep 9 15:37:22 2007 Subject: [GRASS-dev] [grass-code I][480] d.what vect -e fails to issue an error if wrong data type is entered Message-ID: <20070909134421.5EA15401AE@pyrosoma.intevation.org> code I item #480, was opened at 2007-09-09 15:44 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: d.what vect -e fails to issue an error if wrong data type is entered 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): 070909 Initial Comment: When a vector has eg. an integer column and the user enters a character instead of a number in d.what.vect -e window, the module will still report "Record successfully updated" after pressing Submit button, although this is not true. The module should yield an error that the string enetered does not match columns's data type. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=480&group_id=21 From grass-dev at grass.itc.it Sun Sep 9 16:02:34 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Sun Sep 9 15:55:36 2007 Subject: [GRASS-dev] [grass-code I][481] v.db.connect -p always reports for layer 1 only Message-ID: <20070909140234.943F3401A7@pyrosoma.intevation.org> code I item #481, was opened at 2007-09-09 16:02 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: v.db.connect -p always reports for layer 1 only 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): 070909 Initial Comment: v.db.connect -p always reports for layer 1 only. Even if I specify layer=2, it still talks about layer 1: Vector map is connected by: layer <1> table in database through driver with key Same happens in current 6.2 CVS. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=481&group_id=21 From tutey at o2.pl Sun Sep 9 15:56:21 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Sep 9 15:56:29 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems with v.report In-Reply-To: <46E3BABB.5030005@o2.pl> References: <59f453130709081948i8381bb6v844652ad734a59ee@mail.gmail.com> <46E3BABB.5030005@o2.pl> Message-ID: <46E3FB85.7070403@o2.pl> Maciej Sieczka wrote: > dziadgba dziadgba wrote: >> hy everybody, I am working on a project involving geografical data. >> I used grass61 until the end of june, now I reinstalled my system >> and but grass62. >> >> The problem is that when I try to use v.report on a layer containing >> points. >> >> v.report map=roadmapCleanedAndSplit layer=1 option=coor >> >> strangely the list I get includes only the x coordinate, y coodinate >> is missing. >> >> output: cat|type|name|active|line|segment|x|y >> 16021||||||681109.126691232 16022||||||678959.20221614 > I confirm the bug in GRASS 6.3 CVS. Please report it to the tracker. > Maybe someone will take care of it. I did :). Submitted to 6.3 CVS. Also attached to this email - please test. I'd like to backport it to 6.2 if nobody minds. Maciek -------------- next part -------------- #!/bin/sh # ############################################################################ # # MODULE: v.report # AUTHOR(S): Markus Neteler # PURPOSE: Reports geometry statistics for vector maps # COPYRIGHT: (C) 2005, 2007 by MN and the GRASS Development Team # # This program is free software under the GNU General Public # License (>=v2). Read the file COPYING that comes with GRASS # for details. # ############################################################################# #%Module #% description: Reports geometry statistics for vectors. #% keywords: vector, report, statistics #%End #%Flag #% key: r #% description: Reverse sort the result #%End #%Flag #% key: s #% description: Sort the result #%End #%option #% key: map #% type: string #% gisprompt: old,vector,vector #% description: Name of input vector map #% required: yes #%end #%option #% key: layer #% type: integer #% answer: 1 #% description: Layer number #% required: no #%end #%option #% key: option #% type: string #% description: Value to calculate #% options: area,length,coor #% required: yes #%end #%option #% key: units #% type: string #% description: mi(les),f(eet),me(ters),k(ilometers),a(cres),h(ectares) #% options: mi,miles,f,feet,me,meters,k,kilometers,a,acres,h,hectares,p,percent #% required: no #%end if [ -z "$GISBASE" ] ; then echo "You must be in GRASS GIS to run this program." >&2 exit 1 fi if [ "$1" != "@ARGS_PARSED@" ] ; then exec g.parser "$0" "$@" fi ### setup enviro vars ### eval `g.gisenv` : ${GISBASE?} ${GISDBASE?} ${LOCATION_NAME?} ${MAPSET?} LOCATION=$GISDBASE/$LOCATION_NAME/$MAPSET ### trap - so that we can clean up tmp and exit trap 'rm -f "$TMP1" "$TMP2" "$TMP3" "$TMP4"; exit 1' 2 3 15 # setting environment, so that sort works properly in all languages LC_ALL=C # according to 'man sort' export LC_ALL LC_NUMERIC=C export LC_NUMERIC if [ $GIS_FLAG_R -eq 1 -a $GIS_FLAG_S -eq 1 ] ; then g.message -e "Either -r or -s flag" exit 1 fi ### secure temporary files: TMP1="`g.tempfile pid=$$`" TMP2="`g.tempfile pid=$$`" TMP3="`g.tempfile pid=$$`" TMP4="`g.tempfile pid=$$`" MAP=$GIS_OPT_MAP OPTION=$GIS_OPT_OPTION LAYER=$GIS_OPT_LAYER # does the input vector exist? eval `g.findfile element=vector file=$GIS_OPT_MAP` if [ ! "$file" ] ; then g.message -e "Vector map '$GIS_OPT_MAP' not found in mapset search path" exit 1 fi #test if the input vector has a table attached in the given layer v.info -c map=$MAP layer=$LAYER >/dev/null 2>&1 if [ $? -eq 0 ] ; then TABLEEXISTS=1 else TABLEEXISTS=0 fi #fetch column names if [ $TABLEEXISTS -eq 1 ] ; then COLNAMES="`v.info -c map=$MAP layer=$LAYER | grep -v '^Displaying column type' | cut -d '|' -f2 | tr '\n' '|'`" else COLNAMES="cat|" fi #special treatment for opt=coor parameter: if [ "$GIS_OPT_OPTION" = "coor" ] ; then COLUMS="dummy1,dummy2,dummy3" EXTRACOLNAMES="x|y|z" else COLUMS="dummy1" EXTRACOLNAMES="$OPTION" fi #check for optional units parameter: if [ ! -z $GIS_OPT_UNITS ] ; then UNITSPARAM="units=$GIS_OPT_UNITS" # reset to meters since percent are unsupported in v.to.db if [ "$GIS_OPT_UNITS" = "p" -o "$GIS_OPT_UNITS" = "percent" ] ; then UNITSPARAM="units=meters" fi fi ## NOTE: we suppress -1 cat and 0 cat #fetch the attributes sorted by cat: if [ $TABLEEXISTS -eq 1 ] ; then v.db.select -c map=$MAP layer=$LAYER | sort -n -t'|' -k 1 | grep -v '^0' > "$TMP1" else v.category input=$MAP layer=$LAYER option=print | sort -n -t'|' -k 1 | grep -v '^0' > "$TMP1" fi if [ `wc -l "$TMP1" | awk '{print $1}'` -eq 0 ] ; then #fetch the areas/line lengths sorted by cat: v.to.db -p map=$MAP opt=$OPTION col=$COLUMS $UNITSPARAM \ layer=$LAYER 2> /dev/null | grep -v '^cat' | grep -v '^-1' | grep -v '^0'\ | sort -n -t'|' -k 1 > "$TMP2" else #fetch the areas/line lengths sorted by cat: v.to.db -p map=$MAP opt=$OPTION col=$COLUMS $UNITSPARAM \ layer=$LAYER 2> /dev/null | grep -v '^cat' | grep -v '^-1' | grep -v '^0'\ | sort -n -t'|' -k 1 | cut -d'|' -f2-4 > "$TMP2" fi #make and print the table: NUMCOLS=`echo "$COLNAMES$EXTRACOLNAMES" | tr -s '|' ' ' | wc -w | awk '{print $1}'` # save pre-table echo "$COLNAMES$EXTRACOLNAMES" paste -d'|' "$TMP1" "$TMP2" > "$TMP3" if [ ! -z $GIS_OPT_UNITS ] ; then if [ "$GIS_OPT_UNITS" = "p" -o "$GIS_OPT_UNITS" = "percent" ] ; then # calculate total area value AREATOT=`cat "$TMP3" | cut -d'|' -f$NUMCOLS | awk -F '|' 'BEGIN {sum = 0.0} NR == 1{} {sum += $1} END{ print sum }'` # calculate area percentages cat "$TMP3" | cut -d'|' -f$NUMCOLS | awk '{printf "%f\n", $1/'$AREATOT' * 100.}' > "$TMP4" paste -d'|' "$TMP1" "$TMP4" > "$TMP3" fi fi if [ $GIS_FLAG_S -eq 1 ] ; then # sort cat "$TMP3" | sort -n -t'|' -k${NUMCOLS} else if [ $GIS_FLAG_R -eq 1 ] ; then # reverse sort cat "$TMP3" | sort -n -r -t'|' -k${NUMCOLS} else # no sort (order by cat) cat "$TMP3" fi fi #cleanup: rm -f "$TMP1" rm -f "$TMP2" rm -f "$TMP3" rm -f "$TMP4" exit 0 From glynn at gclements.plus.com Sun Sep 9 16:02:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Sep 9 16:02:04 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: References: Message-ID: <18147.64728.618351.744584@cerise.gclements.plus.com> Michael Barton wrote: > I've made a lot of progress getting your TclTk replacement for Xganim into > the GUI. However, I haven't been able to make it animate anything. I finally > tracked this down to the line... > > catch {exec r.out.ppm input=$name output=- 2>@stderr | pnmscale $vscale > >$tmpfile 2>@stderr} > > This requires a program pnmscale. I don't have pnmscale. Does it comes with > GRASS and I somehow don't have it or is it a 3rd party program? xganim.tcl can probably be modified to rescale the image itself, using the -zoom and -subsample options to the "copy" image command (see the photo(n) manpage), but that will probably be slower than using pnmscale. Also, I don't think that those options can be combined, so you would have to zoom the image first then subsample the zoomed image. One consequence is that it may not be practical to get the exact size required (the zoom factor needs to be reasonably small to avoid creating a huge intermediate image). If the lack of pnmscale is the only issue, I can create a local version. The main question is whether the Tcl/Tk version is fast enough to act as a replacement for xganim. When I originally posted it, the comments suggested that the speed difference was enough that xganim needed to be retained. -- Glynn Clements From tutey at o2.pl Sun Sep 9 17:38:05 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Sep 9 17:38:08 2007 Subject: [GRASS-dev] Re: [grass-code I][481] v.db.connect -p always reports for layer 1 only In-Reply-To: <20070909141256.1D862401A7@pyrosoma.intevation.org> References: <20070909141256.1D862401A7@pyrosoma.intevation.org> Message-ID: <46E4135D.6090706@o2.pl> >> Comment By: Martin Landa (martinl) > Parameter 'layer' is completely ignored during printing. It > means *all* available connections are printed, which I think make > sense. Maybe the module description is not so clear. Thanks for the information. Yes, module description is not clear. > For GRASS7 maybe it would be good to add parameter > "option=add,delete,print" > > For 'add' you need map,driver,database,table,key,layer For 'delete' > you need map,layer For 'print' just map Maciek From michael.barton at asu.edu Sun Sep 9 17:43:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 9 17:44:13 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: Message-ID: Is netpbm available for Windows? Michael On 9/8/07 9:25 PM, "William Kyngesburye" wrote: > some netpbm tools are already needed by a couple other script > modules, so it's not a new requirement. But it seems it is not > mentioned in the GRASS requirements. > > On Sep 8, 2007, at 11:00 PM, Michael Barton wrote: > >> I thought that of the (main?) goals of doing a TclTk animation >> replacement >> for Xganim was so that we no longer needed motif/lesstif as a GRASS >> dependency. While the TclTk animator is nicer looking than xganim, if >> pnmscale is required, we just replace one dependency with another >> one. Maybe >> there is another way to do this??? >> >> Michael > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > Earth: "Mostly harmless" > > - revised entry in the HitchHiker's Guide to the Galaxy > > __________________________________________ 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 Sun Sep 9 17:57:47 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 9 17:58:23 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: <18147.64728.618351.744584@cerise.gclements.plus.com> Message-ID: On 9/9/07 7:02 AM, "Glynn Clements" wrote: > Also, I don't think that those options can be combined, so you would > have to zoom the image first then subsample the zoomed image. One > consequence is that it may not be practical to get the exact size > required (the zoom factor needs to be reasonably small to avoid > creating a huge intermediate image). I played around with TclTk rescaling a little when initially working out how to display GRASS maps in a Tcltk canvas and was disappointed in how it worked--especially quality. > > If the lack of pnmscale is the only issue, I can create a local > version. This would be especially good for Windows users. Maybe just build it into r.out.ppm??? > > The main question is whether the Tcl/Tk version is fast enough to act > as a replacement for xganim. When I originally posted it, the comments > suggested that the speed difference was enough that xganim needed to > be retained. > I was wondering this too. I'd originally thought that the best way to go about this was to render all the maps to PPM first, and then display the animation in a second step. But I was able to get the TclTk animation running without scaling so that I could continue to get the rest of it working. I'm surprised at how fast it runs. The maps I'm testing are very simple. Is the speed of r.out.ppm affected by the amount of non-null data or just the total number of cells? If the latter, then it may well be quite fast enough. 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 neteler at itc.it Sun Sep 9 20:14:47 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Sep 9 20:14:51 2007 Subject: [GRASS-dev] [GRASS-user] problems with v.report In-Reply-To: <46E3FB85.7070403@o2.pl> References: <46E3FB85.7070403@o2.pl> Message-ID: <12581423.post@talk.nabble.com> Maciej Sieczka wrote: > > Maciej Sieczka wrote: >> dziadgba dziadgba wrote: > >>> hy everybody, I am working on a project involving geografical data. >>> I used grass61 until the end of june, now I reinstalled my system >>> and but grass62. >>> >>> The problem is that when I try to use v.report on a layer containing >>> points. >>> >>> v.report map=roadmapCleanedAndSplit layer=1 option=coor >>> >>> strangely the list I get includes only the x coordinate, y coodinate >>> is missing. >>> >>> output: cat|type|name|active|line|segment|x|y >>> 16021||||||681109.126691232 16022||||||678959.20221614 > >> I confirm the bug in GRASS 6.3 CVS. Please report it to the tracker. >> Maybe someone will take care of it. > > I did :). Submitted to 6.3 CVS. Also attached to this email - please test. > > I'd like to backport it to 6.2 if nobody minds. > > Maciek, looks good to me! For the 6.2 backport, please keep in mind that g.message doesn't exist - so a minimized patch is needed there. Markus -- View this message in context: http://www.nabble.com/Re%3A--GRASS-user--problems-with-v.report-tf4409393.html#a12581423 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Sun Sep 9 21:04:55 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Sep 9 21:04:57 2007 Subject: [GRASS-dev] g.mlist as C implementation? Message-ID: <20070909190455.GB8769@bartok.itc.it> Hi, when using g.mlist in mapsets with thousands of maps in it (as happens with MODIS time series), it gets extremely slow. I wonder - if a C implementation would be faster (I usually need the * wildcard to match file names) - if yes, how complicated it is to write. ? Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Sun Sep 9 21:21:12 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Sep 9 21:21:15 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: References: Message-ID: <12582052.post@talk.nabble.com> William Kyngesburye wrote: > > some netpbm tools are already needed by a couple other script > modules, so it's not a new requirement. But it seems it is not > mentioned in the GRASS requirements. > Do you have a list? netpbm is rather fat; especially if you only want a few lines of code from it. Markus -- View this message in context: http://www.nabble.com/animation-missing-pnmscale-tf4407452.html#a12582052 Sent from the Grass - Dev mailing list archive at Nabble.com. From tutey at o2.pl Sun Sep 9 21:50:47 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Sep 9 21:50:54 2007 Subject: [GRASS-dev] [GRASS-user] problems with v.report In-Reply-To: <12581423.post@talk.nabble.com> References: <46E3FB85.7070403@o2.pl> <12581423.post@talk.nabble.com> Message-ID: <46E44E97.50704@o2.pl> Markus Neteler wrote: > > Maciej Sieczka wrote: >> I'd like to backport it to 6.2 if nobody minds. > looks good to me! For the 6.2 backport, please keep in mind that > g.message doesn't exist - so a minimized patch is needed there. Will do soon. Thanks for the tip. I'm pretty sure I'd forget about the g.message otherwise. Maciek From woklist at kyngchaos.com Sun Sep 9 21:54:36 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Sep 9 21:54:43 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: <12582052.post@talk.nabble.com> References: <12582052.post@talk.nabble.com> Message-ID: <82E5C133-E7ED-48F9-BF84-E397C88A2804@kyngchaos.com> These are the ones I've found so far (searching for 'netpbm'): ppmtompeg: r.out.mpeg pngtopnm: d.out.gpsdrive pnmtojpeg: d.out.gpsdrive pnmscale: xganim.tcl or by module: d.out.gpsdrive: pngtopnm, pnmtojpeg r.out.mpeg: ppmtompeg (but can also use mpeg_encode instead) xganim.tcl: pnmscale NetPBM is also mentioned in: drivers/HTMLMAP drivers/PNG NVIZ r.in/out.gdal (as a format) r.out.ppm r.texture On Sep 9, 2007, at 2:21 PM, Markus Neteler wrote: > > > William Kyngesburye wrote: >> >> some netpbm tools are already needed by a couple other script >> modules, so it's not a new requirement. But it seems it is not >> mentioned in the GRASS requirements. >> > > Do you have a list? netpbm is rather fat; especially if > you only want a few lines of code from it. > > Markus ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy From glynn at gclements.plus.com Mon Sep 10 02:07:37 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 10 02:07:40 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <20070909190455.GB8769@bartok.itc.it> References: <20070909190455.GB8769@bartok.itc.it> Message-ID: <18148.35529.597752.912149@cerise.gclements.plus.com> Markus Neteler wrote: > when using g.mlist in mapsets with thousands of maps in > it (as happens with MODIS time series), it gets extremely > slow. I wonder > > - if a C implementation would be faster (I usually need > the * wildcard to match file names) It's certainly possible to improve upon the efficiency of g.mlist, although there's a lot which could be done without resorting to C. The main thing which stands out is that it invokes "grep" once for every name returned by g.list: list="" for i in `g.list type=$type mapset=$mapset | grep -v '^-\+$' | grep -v "files available" | grep -vi "mapset"` do if [ ! "$search" ] ; then list="$list $i" else list="$list `echo $i | grep \"$search\"`" fi done Feeding a stream of names to a single grep process would be far more efficient. The g.list output can be "unformatted" so that each name appears on a separate line by filtering through: sed 's/ */\/g' where is a literal newline character (\n works, but appears to be a GNU extension). Also, use of "for var in `command` ..." is sub-optimal; using "command | while read var ..." is preferable. > - if yes, how complicated it is to write. The code itself is fairly straightforward, provided that you can rely upon the existence of either fnmatch() and/or regexec() et al. The former is POSIX.2, the latter POSIX.1. IOW, neither are standard on Windows. DIY glob matching isn't hard if you impose a restriction that the pattern may not contain more than one asterisk: check that the part before the asterisk matches the beginning of the string, the part after it matches the end, and the two don't overlap (i.e. the string is at least as long as the pattern without the asterisk). Matching regular expressions is rather more complex; you don't want to do it yourself. -- Glynn Clements From glynn at gclements.plus.com Mon Sep 10 02:18:43 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 10 02:18:45 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: <82E5C133-E7ED-48F9-BF84-E397C88A2804@kyngchaos.com> References: <12582052.post@talk.nabble.com> <82E5C133-E7ED-48F9-BF84-E397C88A2804@kyngchaos.com> Message-ID: <18148.36195.144574.498975@cerise.gclements.plus.com> William Kyngesburye wrote: > These are the ones I've found so far (searching for 'netpbm'): > > ppmtompeg: r.out.mpeg This is bound to require some kind of external tool, be it ppmtompeg, mencoder (from mplayer), etc. > pngtopnm: d.out.gpsdrive This is gratuitous. The PNG file is generated by the PNG driver, which can generate PPM files by itself. Moreover, the ability to generate PPM files is unconditional, while generating PNG files is optional (using --without-png will disable it). The "PNG driver" name is a historical artifact. > pnmtojpeg: d.out.gpsdrive This will require an external utility, but "cjpeg" would have been a better choice. "cjpeg" is built and installed along with libjpeg, which pnmtojpeg requires. IOW, if you have pnmtojpeg, you already have cjpeg, but the reverse isn't true. > pnmscale: xganim.tcl xganim.tcl was something I hacked together in an hour to determine the feasibility of replacing xganim. AFAICT, it isn't actually part of GRASS (yet). -- Glynn Clements From glynn at gclements.plus.com Mon Sep 10 02:31:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 10 02:31:09 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: References: <18147.64728.618351.744584@cerise.gclements.plus.com> Message-ID: <18148.36937.352204.906602@cerise.gclements.plus.com> Michael Barton wrote: > > If the lack of pnmscale is the only issue, I can create a local > > version. > > This would be especially good for Windows users. Maybe just build it into > r.out.ppm??? You can achieve the same result by running r.out.ppm with a different region resolution. I'm not sure why I didn't do that in xganim.tcl. > Is the speed of r.out.ppm affected by the amount of non-null data or > just the total number of cells? It's affected by the speed of G__lookup_colors(), which has an optimisation for runs of a single value: if the value matches the previous value, it uses the previous colour. This can be significant for FP maps, where you can't create a lookup table, but have to locate and interpolate the appropriate colour rule. But the same is true for xganim. -- Glynn Clements From hamish_nospam at yahoo.com Mon Sep 10 05:52:00 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 10 05:52:10 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18148.35529.597752.912149@cerise.gclements.plus.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> Message-ID: <20070910155200.35f8eb18.hamish_nospam@yahoo.com> Glynn Clements wrote: > > Markus Neteler wrote: > > when using g.mlist in mapsets with thousands of maps in > > it (as happens with MODIS time series), it gets extremely > > slow. .. Glynn Clements wrote: > The main thing which stands out is that it invokes "grep" once for > every name returned by g.list: Hi, see attached patch for consideration. Following Glynn's suggestion it gets rid of the loop for each map name, making the script ~50% faster than before, but still about twice as slow as a single call to g.list. I haven't put it in CVS as I haven't really tested it. Hamish -------------- next part -------------- A non-text attachment was scrubbed... Name: g.mlist_HB20070910.diff Type: text/x-diff Size: 2298 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070910/215d7b87/g.mlist_HB20070910.bin From Juan.Giraldo at upct.es Mon Sep 10 17:17:40 2007 From: Juan.Giraldo at upct.es (Juan Diego Giraldo Osorio) Date: Mon Sep 10 17:45:35 2007 Subject: [GRASS-dev] About signature files. Message-ID: <3837488753jdgiraldo@upct.es> Hi coworkers I'm working with grass62. Now I'm trying to develop a code to classify MODIS images. I have been using i.cluster, but this code perform an unsupervised classification (in conjunction with i.maxlik). I have three categories built with v.digit, then I need the signature file for this training pixels like input to i.maxlik. Someone have developed an "i.signature" code, with a categorized map like input, and the signature file like output? Thanks to all. Juan Diego From michael.barton at asu.edu Mon Sep 10 17:45:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 10 17:46:16 2007 Subject: [GRASS-dev] TclTk interface to d.nviz Message-ID: I've gone ahead and committed the TclTk interface I've done for d.nviz. This is a pure TclTk interactive interface that doesn't require an xterm. So it ought to work on all platforms. There is a bug in the d.nviz C module in that it won't recognize --o for overwriting an existing script file. 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/20070910/5e28152e/attachment.html From neteler at itc.it Mon Sep 10 18:18:03 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 10 18:18:05 2007 Subject: [GRASS-dev] About signature files. In-Reply-To: <3837488753jdgiraldo@upct.es> References: <3837488753jdgiraldo@upct.es> Message-ID: <46E56E3B.6040602@itc.it> Juan Diego Giraldo Osorio wrote on 09/10/2007 05:17 PM: > Hi coworkers > > I'm working with grass62. Now I'm trying to develop a code to classify > MODIS images. I have been using i.cluster, but this code perform an > unsupervised classification (in conjunction with i.maxlik). I have three > categories built with v.digit, then I need the signature file for this > training pixels like input to i.maxlik. Someone have developed an > "i.signature" code, with a categorized map like input, and the signature > file like output? > It is there: i.gensig. Here the overview: Classification methods in GRASS (table best seen with courier font): |radiometric,| radiometric, supervised | radio- and geo- |unsupervised| |metric, supervised --------------+------------+---------------------------------+------------------ Preprocessing | i.cluster |i.class (monitor) i.gensig (maps)|i.gensigset (maps) --------------+------------+---------------------------------+------------------ Computation | i.maxlik | i.maxlik i.maxlik | i.smap Hope this helps, Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Mon Sep 10 17:09:20 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 10 18:23:01 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <20070910155200.35f8eb18.hamish_nospam@yahoo.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> Message-ID: <46E55E20.7030602@itc.it> Hamish wrote on 09/10/2007 05:52 AM: > Glynn Clements wrote: > >> Markus Neteler wrote: >> >>> when using g.mlist in mapsets with thousands of maps in >>> it (as happens with MODIS time series), it gets extremely >>> slow. >>> > .. > Glynn Clements wrote: > >> The main thing which stands out is that it invokes "grep" once for >> every name returned by g.list: >> > > > Hi, > > see attached patch for consideration. Following Glynn's suggestion it > gets rid of the loop for each map name, making the script ~50% faster > than before, but still about twice as slow as a single call to g.list. > > I haven't put it in CVS as I haven't really tested it. > > I have made these tests: for i in `seq 1 2000` ; do r.mapcalc map$i=1 ;done # old g.mlist time g.mlist type=rast pat="map*" real 0m7.496s user 0m2.417s sys 0m4.983s # new g.mlist time g.mlist type=rast pat="map*" real 0m0.230s user 0m0.157s sys 0m0.058s => 0.230/7.496 = 0.031 for i in `seq 1 10000` ; do r.mapcalc map$i=1 ;done # old g.mlist real 0m54.725s user 0m24.809s sys 0m28.944s # new g.mlist real 0m0.416s user 0m0.229s sys 0m0.087s => 0.416/54.725 = 0.0076 # paranoia test: new g.mlist g.mlist type=rast pat="map*" | wc -l 10000 Amazing! Also g.mremove will be finally fast then since it calls g.mlist. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Mon Sep 10 18:35:58 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 10 18:36:00 2007 Subject: [GRASS-dev] About signature files. In-Reply-To: <46E56E3B.6040602@itc.it> References: <3837488753jdgiraldo@upct.es> <46E56E3B.6040602@itc.it> Message-ID: <46E5726E.9020603@itc.it> Markus Neteler wrote on 09/10/2007 06:18 PM: > Juan Diego Giraldo Osorio wrote on 09/10/2007 05:17 PM: > >> Hi coworkers >> >> I'm working with grass62. Now I'm trying to develop a code to classify >> MODIS images. I have been using i.cluster, but this code perform an >> unsupervised classification (in conjunction with i.maxlik). I have three >> categories built with v.digit, then I need the signature file for this >> training pixels like input to i.maxlik. Someone have developed an >> "i.signature" code, with a categorized map like input, and the signature >> file like output? >> >> > It is there: i.gensig. Here the overview: > > Classification methods in GRASS (table best seen with courier font): > > OK, the table didn't survive the formatting. Just have a look here: g.manual imageryintro or http://grass.itc.it/grass63/manuals/html63_user/imageryintro.html -> Image classification Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From michael.barton at asu.edu Mon Sep 10 18:57:47 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 10 18:58:14 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: <18148.36195.144574.498975@cerise.gclements.plus.com> Message-ID: On 9/9/07 5:18 PM, "Glynn Clements" wrote: > > William Kyngesburye wrote: > >> These are the ones I've found so far (searching for 'netpbm'): >> >> ppmtompeg: r.out.mpeg > > This is bound to require some kind of external tool, be it ppmtompeg, > mencoder (from mplayer), etc. > >> pngtopnm: d.out.gpsdrive > > This is gratuitous. The PNG file is generated by the PNG driver, which > can generate PPM files by itself. Moreover, the ability to generate > PPM files is unconditional, while generating PNG files is optional > (using --without-png will disable it). The "PNG driver" name is a > historical artifact. > >> pnmtojpeg: d.out.gpsdrive > > This will require an external utility, but "cjpeg" would have been a > better choice. "cjpeg" is built and installed along with libjpeg, > which pnmtojpeg requires. IOW, if you have pnmtojpeg, you already have > cjpeg, but the reverse isn't true. > >> pnmscale: xganim.tcl > > xganim.tcl was something I hacked together in an hour to determine the > feasibility of replacing xganim. AFAICT, it isn't actually part of > GRASS (yet). This won't need pnmscale. Glynn's solution to do scaling via adjusting the resolution prior to running r.out.pnm works fine. 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 woklist at kyngchaos.com Mon Sep 10 19:10:50 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Sep 10 19:11:10 2007 Subject: [GRASS-dev] animation missing pnmscale In-Reply-To: References: Message-ID: <5E08AB9D-A0B4-44C2-82FF-66D7CAA4C2A2@kyngchaos.com> On Sep 10, 2007, at 11:57 AM, Michael Barton wrote: > This won't need pnmscale. Glynn's solution to do scaling via > adjusting the > resolution prior to running r.out.pnm works fine. > > Michael Cool. ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From michael.barton at asu.edu Mon Sep 10 20:09:05 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 10 20:09:10 2007 Subject: [GRASS-dev] compiling the new Mac OS X grass Message-ID: William, Today was my first attempt at compiling GRASS with your new arrangement (on a PPC). It went well and I had no problems. Also, everything seems to work AFAICT. I did get the following error at the end of make install. It doesn?t seem to have any effects, but I thought I?d send it on to you anyway. Michael ======== make install error ============ ...snip... # TEMPORARY tar cBf - wx | (cd /Applications/Grass/GRASS-6.3.app/Contents/MacOS/etc ; tar xBf - ) tar: wx: Cannot stat: No such file or directory tar: Error exit delayed from previous errors mv -f /Applications/Grass/GRASS-6.3.app/Contents/MacOS/etc/wx/wxgrass /Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/ mv: rename /Applications/Grass/GRASS-6.3.app/Contents/MacOS/etc/wx/wxgrass to /Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/wxgrass: No such file or directory make[3]: [real-install-macosx] Error 1 (ignored) mv -f /Applications/Grass/GRASS-6.3.app/Contents/MacOS/etc/wx/scripts/* /Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/ mv: rename /Applications/Grass/GRASS-6.3.app/Contents/MacOS/etc/wx/scripts/* to /Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/*: No such file or directory make[3]: [real-install-macosx] Error 1 (ignored) __________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070910/e281fdac/attachment.html From glynn at gclements.plus.com Mon Sep 10 20:25:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 10 20:25:13 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <20070910155200.35f8eb18.hamish_nospam@yahoo.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> Message-ID: <18149.35846.508751.103954@cerise.gclements.plus.com> Hamish wrote: > Glynn Clements wrote: > > > > Markus Neteler wrote: > > > when using g.mlist in mapsets with thousands of maps in > > > it (as happens with MODIS time series), it gets extremely > > > slow. > .. > Glynn Clements wrote: > > The main thing which stands out is that it invokes "grep" once for > > every name returned by g.list: > > see attached patch for consideration. Following Glynn's suggestion it > gets rid of the loop for each map name, making the script ~50% faster > than before, but still about twice as slow as a single call to g.list. Here's my proposed alternative. It avoids the use of backticks in favour of a pipeline ending in a while loop. -- Glynn Clements -------------- next part -------------- --- scripts/g.mlist/g.mlist~ 2007-04-19 17:45:00.000000000 +0100 +++ scripts/g.mlist/g.mlist 2007-09-10 19:20:51.000000000 +0100 @@ -56,29 +56,25 @@ #%end do_list() { - list="" - for i in `g.list type=$type mapset=$mapset | grep -v '^-\+$' | grep -v "files available" | grep -vi "mapset"` - do - if [ ! "$search" ] ; then - list="$list $i" - else - list="$list `echo $i | grep \"$search\"`" - fi - done - - if [ ! "$list" ] ; then - return + if [ ! "$search" ] ; then + search="." fi - sorted_list=`echo "$list" | tr ' ' '\n' | sort | tr '\n' ' '` - if [ $GIS_FLAG_M -eq 1 ] ; then MAPSET="@$mapset" else MAPSET="" fi - i="" - for i in $sorted_list + + g.list type=$type mapset=$mapset \ + | grep -v '^-\+$' \ + | grep -v "files available" \ + | grep -vi "mapset" \ + | sed 's/ */\n/g' \ + | grep -v '^$' \ + | grep "$search" \ + | sort \ + | while read i do if [ "$start" ] ; then if [ -z "$sep" ] ; then From neteler at itc.it Mon Sep 10 20:25:37 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 10 20:25:39 2007 Subject: [GRASS-dev] TclTk interface to d.nviz In-Reply-To: References: Message-ID: <12599324.post@talk.nabble.com> Michael Barton wrote: > > I've gone ahead and committed the TclTk interface I've done for d.nviz. > This > is a pure TclTk interactive interface that doesn't require an xterm. So it > ought to work on all platforms. There is a bug in the d.nviz C module in > that it won't recognize --o for overwriting an existing script file. > Bug fixed in CVS. Markus -- View this message in context: http://www.nabble.com/TclTk-interface-to-d.nviz-tf4416124.html#a12599324 Sent from the Grass - Dev mailing list archive at Nabble.com. From michael.barton at asu.edu Mon Sep 10 20:28:03 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Sep 10 20:28:09 2007 Subject: [GRASS-dev] TclTk interface to d.nviz In-Reply-To: <12599324.post@talk.nabble.com> Message-ID: Thanks Markus. Michael On 9/10/07 11:25 AM, "Markus Neteler" wrote: > > > Michael Barton wrote: >> >> I've gone ahead and committed the TclTk interface I've done for d.nviz. >> This >> is a pure TclTk interactive interface that doesn't require an xterm. So it >> ought to work on all platforms. There is a bug in the d.nviz C module in >> that it won't recognize --o for overwriting an existing script file. >> > > Bug fixed in CVS. > > Markus __________________________________________ 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 woklist at kyngchaos.com Mon Sep 10 20:45:43 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Sep 10 20:45:54 2007 Subject: [GRASS-dev] compiling the new Mac OS X grass In-Reply-To: References: Message-ID: <0739F94D-A7DE-415C-AB3A-1F91EF5C393C@kyngchaos.com> Oops, I left a bit of customization in there - for my use to install the wx stuff. Fixed in CVS. On Sep 10, 2007, at 1:09 PM, Michael Barton wrote: > William, > > Today was my first attempt at compiling GRASS with your new > arrangement (on a PPC). It went well and I had no problems. Also, > everything seems to work AFAICT. > > I did get the following error at the end of make install. It > doesn?t seem to have any effects, but I thought I?d send it on to > you anyway. > ----- 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 wolf+grass at bergenheim.net Mon Sep 10 23:56:32 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Mon Sep 10 23:57:06 2007 Subject: [GRASS-dev] Automatic smart label placement (v.label.sa) Message-ID: <46E5BD90.5080708@bergenheim.net> Hi! I'm happy to report that I finally had time to spend on debugging my v.label.sa (automatic label placement) and fixed three serious bugs. The bugs resulted in labels being placed over lines and other labels even if more optimal places were available. Also the current (fixed) cvs version fixes the issue that labels are supposed to be around the center of the line, rather then in the ends. I'd appreciate it if someone could test it a bit, and give me feedback. I plan on changing the font handling so that it takes the name of a (truetype) font and finds the path from the fontcap. Also customizable label color and labeling of areas will come later. If you have other wishes, please don't hesitate to ask. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From hamish_nospam at yahoo.com Tue Sep 11 01:46:01 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 11 01:46:35 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <46E55E20.7030602@itc.it> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> Message-ID: <20070911114601.9465b7c5.hamish_nospam@yahoo.com> Markus Neteler wrote: > >>> when using g.mlist in mapsets with thousands of maps in > >>> it (as happens with MODIS time series), it gets extremely > >>> slow. Hamish: > > see attached patch for consideration. Following Glynn's suggestion it > > gets rid of the loop for each map name, Markus: > I have made these tests: .. > for i in `seq 1 10000` ; do r.mapcalc map$i=1 ;done > # old g.mlist > real 0m54.725s .. > # new g.mlist > real 0m0.416s .. > => 0.416/54.725 = 0.0076 .. > Amazing! well, the time is just proportional to the number of program calls. by removing that loop that number is now finite, whereas before it depended on the number of maps. Of course the expanded g.list solution is just 1 program call. Glynn: > Here's my proposed alternative. It avoids the use of backticks in > favour of a pipeline ending in a while loop. I don't mind which patch gets used; the simpler the better. I noticed parts of the script may be a bit fragile/inefficient, which is of concern for a module mainly intended as a scripting tool. - The script relies on "echo -n"; not portable? http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html + g.list type=$type mapset=$mapset \ + | grep -v '^-\+$' \ + | grep -v "files available" \ + | grep -vi "mapset" \ + | sed 's/ */\n/g' \ + | grep -v '^$' \ + | grep "$search" \ + | sort \ + | while read i - combine the groups of sequential greps into single calls with the \| "OR" expr. - The `grep -v "files available"` will fail when translated, 'raster files available in mapset :' I assume the `grep -vi "mapset"` is there as a poor workaround for that. ("mapset" will not be as translated as often as "files available") :-/ Is there a standard C library fn we can call to get regex support? Direct pattern searching in g.list would be preferable; I agree that a DIY reimplementation is a lot more trouble than it is worth. (unless some standard GPL code is copied verbatim into a new G_regex() libgis fn) ? things like r.out.mpeg have basic map-name matching capabilities already. Hamish From glynn at gclements.plus.com Tue Sep 11 04:20:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 11 04:20:17 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <20070911114601.9465b7c5.hamish_nospam@yahoo.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> Message-ID: <18149.64351.26767.344460@cerise.gclements.plus.com> Hamish wrote: > I noticed parts of the script may be a bit fragile/inefficient, which is > of concern for a module mainly intended as a scripting tool. > > - The script relies on "echo -n"; not portable? Nope. According to the official specification, echo doesn't accept any switches. OTOH, the GNU version doesn't support the \c sequence. IOW, there is no portable way to echo a string without appending a newline. > http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html > > > + g.list type=$type mapset=$mapset \ > + | grep -v '^-\+$' \ > + | grep -v "files available" \ > + | grep -vi "mapset" \ > + | sed 's/ */\n/g' \ > + | grep -v '^$' \ > + | grep "$search" \ > + | sort \ > + | while read i > > - combine the groups of sequential greps into single calls with the \| > "OR" expr. The second and third can certainly be combined that way, provided that you can use (or not use) -i for both (which is probably the case). I'm not sure whether you can include the anchors (^ and $) within a branch. Hmm; this is wrong: grep -vi "mapset" Nothing (other than common sense) prevents you from creating a map named "mapset". > - The `grep -v "files available"` will fail when translated, > 'raster files available in mapset :' > I assume the `grep -vi "mapset"` is there as a poor workaround for that. > ("mapset" will not be as translated as often as "files available") :-/ One more reason why we need a g.list which isn't quite so "hostile" to scripting. > Is there a standard C library fn we can call to get regex support? > Direct pattern searching in g.list would be preferable; I agree that > a DIY reimplementation is a lot more trouble than it is worth. (unless > some standard GPL code is copied verbatim into a new G_regex() libgis fn)? > things like r.out.mpeg have basic map-name matching capabilities already. For regular expressions, regcomp(), regexec(), regfree() and regerror() are specified by POSIX.1. For shell "glob" patterns, fnmatch() is specified by POSIX.2. None of these are specified by either version of ANSI C, so we would need additional libraries for Windows. -- Glynn Clements From frankie at debian.org Tue Sep 11 14:42:48 2007 From: frankie at debian.org (Francesco Paolo Lovergine) Date: Tue Sep 11 14:43:01 2007 Subject: [GRASS-dev] Le =?iso-8859-1?q?Troph=E9es?= du Libre -- International free software contest 2007 Message-ID: <20070911124248.GA16615@mithrandir> Hi Grass fellows In behalf of the organizer committee I'm forwarding you the main URL of the 2007 prize event: http://www.tropheesdulibre.org/?lang=en This year a Science section is open, so it could be of interest to submit projects candidatures. -- Francesco P. Lovergine From michael.barton at asu.edu Tue Sep 11 17:05:09 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 11 17:05:31 2007 Subject: [GRASS-dev] Re: [grass-code I][479] Gis.m produces error upon saving current workspace to a grc file In-Reply-To: <20070911143830.1BD5B40180@pyrosoma.intevation.org> Message-ID: Thanks for finding this and submitting a fix. It's in the cvs now. Michael On 9/11/07 7:38 AM, "grass-dev@grass.itc.it" wrote: > code I item #479, was opened at 2007-09-07 22:19 > Status: Open > Priority: 3 > Submitted By: Eric Patton (eric) >> Assigned to: Michael Barton (michael) > Summary: Gis.m produces error upon saving current workspace to a grc file > Issue type: module bug >> Issue status: confirmed > GRASS version: CVS HEAD > GRASS component: gis.m > Operating system: Linux > Operating system version: Ubuntu - GNU/Linux > GRASS CVS checkout date, if applies (YYMMDD): 070907 > > >> Comment By: M?ris Narti?s (marisn) > Date: 2007-09-11 17:38 > > Message: > Yes, there is a bug in code. Here is a patch to fix problem: > Index: gui/tcltk/gis.m/gmtree.tcl > =================================================================== > RCS file: /home/grass/grassrepository/grass6/gui/tcltk/gis.m/gmtree.tcl,v > retrieving revision 1.25 > diff -r1.25 gmtree.tcl > 976c976 > < if {[catch {GmTree::node_type $current_node}] error } { > --- >> if {[catch {GmTree::node_type $current_node} error ] } { > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=479&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 From tutey at o2.pl Tue Sep 11 18:36:09 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Sep 11 18:36:14 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18149.64351.26767.344460@cerise.gclements.plus.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> Message-ID: <46E6C3F9.9050008@o2.pl> Glynn Clements wrote: > Hamish wrote: >> I noticed parts of the script may be a bit fragile/inefficient, which is >> of concern for a module mainly intended as a scripting tool. >> >> - The script relies on "echo -n"; not portable? > Nope. According to the official specification, echo doesn't accept any > switches. OTOH, the GNU version doesn't support the \c sequence. IOW, > there is no portable way to echo a string without appending a newline. We can use printf instead I guess. By default it does not append a newline (to append it, add \n at the end of the string to be printed). It seems to be portable and POSIX compliant, see eg. [1]. [1]http://pwet.fr/man/linux/commandes/posix/echo Maciek From paul-grass at stjohnspoint.co.uk Tue Sep 11 18:56:05 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Sep 11 18:57:20 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <46E6C3F9.9050008@o2.pl> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> <46E6C3F9.9050008@o2.pl> Message-ID: On Tue, 11 Sep 2007, Maciej Sieczka wrote: > Glynn Clements wrote: >> Hamish wrote: > >>> I noticed parts of the script may be a bit fragile/inefficient, which is >>> of concern for a module mainly intended as a scripting tool. >>> >>> - The script relies on "echo -n"; not portable? > >> Nope. According to the official specification, echo doesn't accept any >> switches. OTOH, the GNU version doesn't support the \c sequence. IOW, >> there is no portable way to echo a string without appending a newline. What about the echo that is included with GRASS: $GISBASE/etc/echo? It suppresses a new line if the -n flag is used, and prints to stderr if -e is used, otherwise stdout. Might be another use for it? Paul From landa.martin at gmail.com Tue Sep 11 20:02:39 2007 From: landa.martin at gmail.com (Martin Landa) Date: Tue Sep 11 20:02:42 2007 Subject: [GRASS-dev] Re: export 3d vector line map to shp In-Reply-To: References: Message-ID: OK, this ugly patch enables to export 3d shapefile using v.out.ogr lco="SHPT=ARCZ" ... Martin 2007/9/11, Martin Landa : > Hi, > > I got problem exporting 3d GRASS vector map to Shapefile. I have a > vector map with 3d lines (contours). > > $ .out.ascii isolines_reggio format=standard | head -n 20 > ORGANIZATION: > DIGIT DATE: > DIGIT NAME: martin > MAP NAME: Output from v.overlay > MAP DATE: Tue Sep 11 00:50:19 2007 > MAP SCALE: 1 > OTHER INFO: > ZONE: 0 > MAP THRESH: 0.000000 > VERTI: > L 20 1 > 618866 949571.5625 100 > 618824.8125 949549.6875 100 > 618815.8125 949537.1875 100 > 618820.8125 949524.6875 100 > 618810.8125 949486.3125 100 > 618774.5625 949423.6875 100 > 618767.0625 949372.8125 100 > 618746.375 949349.8125 100 > 618728.8125 949360.3125 100 > > I tried to export the map using > > $ v.out.ogr in=isolines_reggio dsn=./ olay=isolines_reggio > > For testing... > $ v.in.ogr dsn=isolines_reggio.shp out=test -z > > v.out.ascii test format=standard | head -n 20 > ORGANIZATION: > DIGIT DATE: > DIGIT NAME: martin > MAP NAME: > MAP DATE: Tue Sep 11 19:46:07 2007 > MAP SCALE: 1 > OTHER INFO: > ZONE: 0 > MAP THRESH: 0.000000 > VERTI: > L 20 1 > 618866 949571.5625 0 > 618824.8125 949549.6875 0 > 618815.8125 949537.1875 0 > 618820.8125 949524.6875 0 > 618810.8125 949486.3125 0 > 618774.5625 949423.6875 0 > 618767.0625 949372.8125 0 > 618746.375 949349.8125 0 > 618728.8125 949360.3125 0 > > The Z coordinate is lost... > > According > > http://gdal.org/ogr/drv_shapefile.html > > I tried > > v.out.ogr in=isolines_reggio dsn=./ olay=isolines_reggio lco=SHPT=ARCZ > ERROR 6: Unknown SHPT value of `ARCZ=YES' passed to Shapefile layer > creation. Creation aborted. > > ERROR: Cannot create layer > > Thanks for any tip... > > Martin > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Tue Sep 11 20:03:26 2007 From: landa.martin at gmail.com (Martin Landa) Date: Tue Sep 11 20:03:38 2007 Subject: [GRASS-dev] Re: export 3d vector line map to shp In-Reply-To: References: Message-ID: ... sorry, forgot to attach the patch... 2007/9/11, Martin Landa : > OK, > > this ugly patch enables to export 3d shapefile using v.out.ogr > lco="SHPT=ARCZ" ... > > Martin > > 2007/9/11, Martin Landa : > > Hi, > > > > I got problem exporting 3d GRASS vector map to Shapefile. I have a > > vector map with 3d lines (contours). > > > > $ .out.ascii isolines_reggio format=standard | head -n 20 > > ORGANIZATION: > > DIGIT DATE: > > DIGIT NAME: martin > > MAP NAME: Output from v.overlay > > MAP DATE: Tue Sep 11 00:50:19 2007 > > MAP SCALE: 1 > > OTHER INFO: > > ZONE: 0 > > MAP THRESH: 0.000000 > > VERTI: > > L 20 1 > > 618866 949571.5625 100 > > 618824.8125 949549.6875 100 > > 618815.8125 949537.1875 100 > > 618820.8125 949524.6875 100 > > 618810.8125 949486.3125 100 > > 618774.5625 949423.6875 100 > > 618767.0625 949372.8125 100 > > 618746.375 949349.8125 100 > > 618728.8125 949360.3125 100 > > > > I tried to export the map using > > > > $ v.out.ogr in=isolines_reggio dsn=./ olay=isolines_reggio > > > > For testing... > > $ v.in.ogr dsn=isolines_reggio.shp out=test -z > > > > v.out.ascii test format=standard | head -n 20 > > ORGANIZATION: > > DIGIT DATE: > > DIGIT NAME: martin > > MAP NAME: > > MAP DATE: Tue Sep 11 19:46:07 2007 > > MAP SCALE: 1 > > OTHER INFO: > > ZONE: 0 > > MAP THRESH: 0.000000 > > VERTI: > > L 20 1 > > 618866 949571.5625 0 > > 618824.8125 949549.6875 0 > > 618815.8125 949537.1875 0 > > 618820.8125 949524.6875 0 > > 618810.8125 949486.3125 0 > > 618774.5625 949423.6875 0 > > 618767.0625 949372.8125 0 > > 618746.375 949349.8125 0 > > 618728.8125 949360.3125 0 > > > > The Z coordinate is lost... > > > > According > > > > http://gdal.org/ogr/drv_shapefile.html > > > > I tried > > > > v.out.ogr in=isolines_reggio dsn=./ olay=isolines_reggio lco=SHPT=ARCZ > > ERROR 6: Unknown SHPT value of `ARCZ=YES' passed to Shapefile layer > > creation. Creation aborted. > > > > ERROR: Cannot create layer > > > > Thanks for any tip... > > > > Martin > > > > -- > > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- ? OBJ.i686-pc-linux-gnu ? isolines_reggio.dbf ? isolines_reggio.shp ? isolines_reggio.shx ? main.c.diff Index: main.c =================================================================== RCS file: /home/grass/grassrepository/grass6/vector/v.out.ogr/main.c,v retrieving revision 1.45 diff -u -r1.45 main.c --- main.c 10 Aug 2007 14:31:12 -0000 1.45 +++ main.c 11 Sep 2007 18:01:30 -0000 @@ -124,7 +124,7 @@ dsco->key = "dsco"; dsco->type = TYPE_STRING; dsco->required = NO; - dsco->multiple = NO; + dsco->multiple = YES; dsco->answer = ""; dsco->description = _("OGR dataset creation option (format specific, NAME=VALUE)"); @@ -132,7 +132,7 @@ lco->key = "lco"; lco->type = TYPE_STRING; lco->required = NO; - lco->multiple = NO; + lco->multiple = YES; lco->answer = ""; lco->description = _("OGR layer creation option (format specific, NAME=VALUE)"); @@ -223,12 +223,14 @@ } if ( drn == -1 ) G_fatal_error ( _("Driver %s not found"), frmt_opt->answer ); Ogr_driver = OGRGetDriver( drn ); - papszDSCO = CSLSetNameValue( papszDSCO, dsco->answer,"YES"); + /* papszDSCO = CSLSetNameValue( papszDSCO, dsco->answer,"YES"); */ + papszDSCO = dsco->answers; Ogr_ds = OGR_Dr_CreateDataSource( Ogr_driver, dsn_opt->answer, papszDSCO ); CSLDestroy( papszDSCO ); if ( Ogr_ds == NULL ) G_fatal_error (_("Cannot open OGR data source '%s'"), dsn_opt->answer); - papszLCO = CSLSetNameValue( papszLCO, lco->answer,"YES"); + /* papszLCO = CSLSetNameValue( papszLCO, lco->answer,""); */ + papszLCO = lco->answers; Ogr_layer = OGR_DS_CreateLayer( Ogr_ds, layer_opt->answer, Ogr_projection, wkbtype, papszLCO ); CSLDestroy( papszLCO ); if ( Ogr_layer == NULL ) G_fatal_error (_("Cannot create layer")); From michael.barton at asu.edu Tue Sep 11 20:10:00 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 11 20:10:27 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18149.64351.26767.344460@cerise.gclements.plus.com> Message-ID: Another reason to consider extending the functionality of g.list over improvements to the g.mlist script is that a C-module would run in a Windows environment and the script contains a lot of *nix-isms that could be problematic even with Mysys. Michael On 9/10/07 7:20 PM, "Glynn Clements" wrote: > > Hamish wrote: > >> I noticed parts of the script may be a bit fragile/inefficient, which is >> of concern for a module mainly intended as a scripting tool. >> >> - The script relies on "echo -n"; not portable? > > Nope. According to the official specification, echo doesn't accept any > switches. OTOH, the GNU version doesn't support the \c sequence. IOW, > there is no portable way to echo a string without appending a newline. > >> http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html >> >> >> + g.list type=$type mapset=$mapset \ >> + | grep -v '^-\+$' \ >> + | grep -v "files available" \ >> + | grep -vi "mapset" \ >> + | sed 's/ */\n/g' \ >> + | grep -v '^$' \ >> + | grep "$search" \ >> + | sort \ >> + | while read i >> >> - combine the groups of sequential greps into single calls with the \| >> "OR" expr. > > The second and third can certainly be combined that way, provided that > you can use (or not use) -i for both (which is probably the case). I'm > not sure whether you can include the anchors (^ and $) within a > branch. > > Hmm; this is wrong: > > grep -vi "mapset" > > Nothing (other than common sense) prevents you from creating a map > named "mapset". > >> - The `grep -v "files available"` will fail when translated, >> 'raster files available in mapset :' >> I assume the `grep -vi "mapset"` is there as a poor workaround for that. >> ("mapset" will not be as translated as often as "files available") :-/ > > One more reason why we need a g.list which isn't quite so "hostile" to > scripting. > >> Is there a standard C library fn we can call to get regex support? >> Direct pattern searching in g.list would be preferable; I agree that >> a DIY reimplementation is a lot more trouble than it is worth. (unless >> some standard GPL code is copied verbatim into a new G_regex() libgis fn)? >> things like r.out.mpeg have basic map-name matching capabilities already. > > For regular expressions, regcomp(), regexec(), regfree() and > regerror() are specified by POSIX.1. For shell "glob" patterns, > fnmatch() is specified by POSIX.2. None of these are specified by > either version of ANSI C, so we would need additional libraries for > Windows. __________________________________________ 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 glynn at gclements.plus.com Tue Sep 11 21:38:24 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 11 21:38:26 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> <46E6C3F9.9050008@o2.pl> Message-ID: <18150.61104.185425.173372@cerise.gclements.plus.com> Paul Kelly wrote: > >>> I noticed parts of the script may be a bit fragile/inefficient, which is > >>> of concern for a module mainly intended as a scripting tool. > >>> > >>> - The script relies on "echo -n"; not portable? > > > >> Nope. According to the official specification, echo doesn't accept any > >> switches. OTOH, the GNU version doesn't support the \c sequence. IOW, > >> there is no portable way to echo a string without appending a newline. > > What about the echo that is included with GRASS: $GISBASE/etc/echo? That would work, but it could have a substantial performance hit, as it can be executed twice per name ("echo" is normally a shell built-in). One solution would be to use "$echo", and set it to either "echo" or "$GISBASE/etc/echo" depending upon whether the default echo command understands the -n switch. Patch attached. -- Glynn Clements -------------- next part -------------- --- scripts/g.mlist/g.mlist~ 2007-09-11 16:19:42.000000000 +0100 +++ scripts/g.mlist/g.mlist 2007-09-11 20:34:45.000000000 +0100 @@ -55,6 +55,12 @@ #% required : no #%end +if [ "`echo -n foo | wc -l`" = 0 ] ; then + echo=echo +else + echo="$GISBASE/etc/echo" +fi + do_list() { if [ ! "$search" ] ; then search="." @@ -80,11 +86,11 @@ if [ -z "$sep" ] ; then echo else - echo -n "$sep" + "$echo" -n "$sep" fi fi start=1 - echo -n "$i$MAPSET" + "$echo" -n "$i$MAPSET" done } From glynn at gclements.plus.com Tue Sep 11 21:44:13 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 11 21:44:19 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: References: <18149.64351.26767.344460@cerise.gclements.plus.com> Message-ID: <18150.61453.333429.942080@cerise.gclements.plus.com> Michael Barton wrote: > Another reason to consider extending the functionality of g.list over > improvements to the g.mlist script is that a C-module would run in a Windows > environment and the script contains a lot of *nix-isms that could be > problematic even with Mysys. Or use Tcl or Python; both of those have regexp support as part of the language. OTOH, there's no guarantee that either of those will be installed. The only practical option which doesn't require additional dependencies is a C module with no support for regexps and glob patterns limited to a single asterisk. -- Glynn Clements From hamish_nospam at yahoo.com Wed Sep 12 12:47:58 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Sep 12 12:48:04 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> <46E6C3F9.9050008@o2.pl> Message-ID: <20070912224758.07be097d.hamish_nospam@yahoo.com> > - The script relies on "echo -n"; not portable? Instead of "echo -n" to build the output map by map, what if a string was constructed within the loop like: if [ $first ] ; then OUTSTRING="$MAPNAME$MAPSET" else OUTSTRING="$OUTSTRING$SEP$MAPNAME$MAPSET" fi and then at end of the script just a single echo "$OUTSTRING" is that going to max out at 4096 chars? what should a the C flat 'g.list -g' output look like? how about: [user1] map1 map2 map3 [PERMANENT] map_a map_b map_c ? Hamish From landa.martin at gmail.com Wed Sep 12 13:22:20 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Sep 12 13:22:25 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <20070912224758.07be097d.hamish_nospam@yahoo.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> <46E6C3F9.9050008@o2.pl> <20070912224758.07be097d.hamish_nospam@yahoo.com> Message-ID: Hi, 2007/9/12, Hamish : > what should a the C flat 'g.list -g' output look like? how about: > [user1] > map1 > map2 > map3 > [PERMANENT] > map_a > map_b > map_c BTW, I tried to implement something similar in the past... g.list rast ncols=1 ---------------------------------------------- raster files available in mapset : dem_reggio_10 dem_reggio_10_fp ---------------------------------------------- raster files available in mapset : MASK elev_reggio elev_reggio_10 Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: g-list-ncols.diff Type: application/octet-stream Size: 4436 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070912/a70f78f4/g-list-ncols-0001.obj From neteler at itc.it Wed Sep 12 13:27:23 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 12 13:27:25 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18149.35846.508751.103954@cerise.gclements.plus.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <18149.35846.508751.103954@cerise.gclements.plus.com> Message-ID: <46E7CD1B.1080905@itc.it> Glynn Clements wrote on 09/10/2007 08:25 PM: > Hamish wrote: > > >> Glynn Clements wrote: >> >>> Markus Neteler wrote: >>> >>>> when using g.mlist in mapsets with thousands of maps in >>>> it (as happens with MODIS time series), it gets extremely >>>> slow. >>>> >> .. >> Glynn Clements wrote: >> >>> The main thing which stands out is that it invokes "grep" once for >>> every name returned by g.list: >>> >> see attached patch for consideration. Following Glynn's suggestion it >> gets rid of the loop for each map name, making the script ~50% faster >> than before, but still about twice as slow as a single call to g.list. >> > > Here's my proposed alternative. It avoids the use of backticks in > favour of a pipeline ending in a while loop. > > It appears that Hamish's implementation based on Glynn's former notes is much faster: time sh g.mlist_glynn type=rast map=neteler pat="map*" real 0m1.200s user 0m0.749s sys 0m0.464s time sh g.mlist_hamish type=rast map=neteler pat="map*" real 0m0.338s user 0m0.190s sys 0m0.052s Is that the contribution to portability? :) Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Wed Sep 12 13:30:08 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Sep 12 13:30:11 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <20070912224758.07be097d.hamish_nospam@yahoo.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> <46E6C3F9.9050008@o2.pl> <20070912224758.07be097d.hamish_nospam@yahoo.com> Message-ID: <46E7CDC0.3040607@itc.it> Hamish wrote on 09/12/2007 12:47 PM: > what should a the C flat 'g.list -g' output look like? how about: > [user1] > map1 > map2 > map3 > [PERMANENT] > map_a > map_b > map_c > For parsing reasons, it should be [user1] map1 [user1] map2 [user1] map3 [PERMANENT] map1 [PERMANENT] map2 [PERMANENT] map3 or even user1:map1 user1:map2 user1:map3 PERMANENT:map1 PERMANENT:map2 PERMANENT:map3 and 'g.list -gf': user1:map1:title1 user1:map2:title2 PERMANENT:map1:title1 Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From glynn at gclements.plus.com Wed Sep 12 15:06:35 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 12 15:06:38 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <20070912224758.07be097d.hamish_nospam@yahoo.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> <46E6C3F9.9050008@o2.pl> <20070912224758.07be097d.hamish_nospam@yahoo.com> Message-ID: <18151.58459.182113.15270@cerise.gclements.plus.com> Hamish wrote: > > - The script relies on "echo -n"; not portable? > > Instead of "echo -n" to build the output map by map, what if a string was > constructed within the loop like: > > if [ $first ] ; then > OUTSTRING="$MAPNAME$MAPSET" > else > OUTSTRING="$OUTSTRING$SEP$MAPNAME$MAPSET" > fi > > > and then at end of the script just a single > echo "$OUTSTRING" > > is that going to max out at 4096 chars? It's going to create the string in memory, then write it in one go. It could potentially hit a limit on the maximum length of a command if echo isn't a built-in. I don't know whether this is anything other than a theoretical possibility, though. > what should a the C flat 'g.list -g' output look like? how about: > [user1] > map1 > map2 > map3 > [PERMANENT] > map_a > map_b > map_c It would be simpler to parse if the mapset was part of each name, e.g.: map1@user1 map2@user1 map3@user1 map_a@PERMANENT map_b@PERMANENT map_c@PERMANENT -- Glynn Clements From glynn at gclements.plus.com Wed Sep 12 15:54:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Sep 12 15:54:21 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <46E7CD1B.1080905@itc.it> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <18149.35846.508751.103954@cerise.gclements.plus.com> <46E7CD1B.1080905@itc.it> Message-ID: <18151.61324.6182.934042@cerise.gclements.plus.com> Markus Neteler wrote: > >>> The main thing which stands out is that it invokes "grep" once for > >>> every name returned by g.list: > >>> > >> see attached patch for consideration. Following Glynn's suggestion it > >> gets rid of the loop for each map name, making the script ~50% faster > >> than before, but still about twice as slow as a single call to g.list. > >> > > > > Here's my proposed alternative. It avoids the use of backticks in > > favour of a pipeline ending in a while loop. > > > > > It appears that Hamish's implementation based on Glynn's former notes > is much faster: > > time sh g.mlist_glynn type=rast map=neteler pat="map*" > real 0m1.200s > user 0m0.749s > sys 0m0.464s > > time sh g.mlist_hamish type=rast map=neteler pat="map*" > real 0m0.338s > user 0m0.190s > sys 0m0.052s > > Is that the contribution to portability? :) I had overlooked the part where loop which adds the separator was replaced with a call to "tr". Technically, this corresponds to a reduction in functionality, as the previous version would accept any string as a separator, but using "tr" restricts it to a single character (which is probably all that's required). I've committed an update which has no loops other than the top-level "for mapset in $mapsets" loop. -- Glynn Clements From michael.barton at asu.edu Wed Sep 12 16:56:00 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Sep 12 16:56:22 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: Message-ID: Martin, Is this in the cvs yet? Michael On 9/12/07 4:22 AM, "Martin Landa" wrote: > Hi, > > 2007/9/12, Hamish : > >> what should a the C flat 'g.list -g' output look like? how about: >> [user1] >> map1 >> map2 >> map3 >> [PERMANENT] >> map_a >> map_b >> map_c > > BTW, I tried to implement something similar in the past... > > g.list rast ncols=1 > ---------------------------------------------- > raster files available in mapset : > dem_reggio_10 > dem_reggio_10_fp > ---------------------------------------------- > raster files available in mapset : > MASK > elev_reggio > elev_reggio_10 > > Martin __________________________________________ 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 Sep 13 05:24:13 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Sep 13 05:29:27 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18151.61324.6182.934042@cerise.gclements.plus.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <18149.35846.508751.103954@cerise.gclements.plus.com> <46E7CD1B.1080905@itc.it> <18151.61324.6182.934042@cerise.gclements.plus.com> Message-ID: <20070913152413.b1111594.hamish_nospam@yahoo.com> Glynn Clements wrote: > I had overlooked the part where loop which adds the separator was > replaced with a call to "tr". > > Technically, this corresponds to a reduction in functionality, as the > previous version would accept any string as a separator, but using > "tr" restricts it to a single character (which is probably all that's > required). is it possible to use sed instead of tr? sed -e "s/\n/$sep/" # doesn't work > I've committed an update which has no loops other than the top-level > "for mapset in $mapsets" loop. thanks. I will have a look at merging Martin, Markus and Glynn's suggestions for a flat output g.list flag. As the feature is needed for parsing, I'd rather do it as a flag vs. a ncols= option which retains the text and fancy format mapset underlines. I've never really known what the "g" stands for, but as we use it a lot for parsable output, the flag will be '-g' here too. so it would look like: G63> g.list -g rast map1@user1 map2@user1 map3@user1 map_a@PERMANENT map_b@PERMANENT map_c@PERMANENT G63> g.list -gf rast map1@user1: map2@user1:This map has a title map3@user1: map_a@PERMANENT:Raw x,y,z data binned into a raster grid by cell min map_b@PERMANENT:Land Use map_c@PERMANENT: Once that is firm we can revisit g.mlist to make it fully locale independent by removing the < grep -vi "files available\|mapset" > part. Hamish From glynn at gclements.plus.com Thu Sep 13 05:58:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 13 05:58:45 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <20070913152413.b1111594.hamish_nospam@yahoo.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <18149.35846.508751.103954@cerise.gclements.plus.com> <46E7CD1B.1080905@itc.it> <18151.61324.6182.934042@cerise.gclements.plus.com> <20070913152413.b1111594.hamish_nospam@yahoo.com> Message-ID: <18152.46448.816172.298686@cerise.gclements.plus.com> Hamish wrote: > > I had overlooked the part where loop which adds the separator was > > replaced with a call to "tr". > > > > Technically, this corresponds to a reduction in functionality, as the > > previous version would accept any string as a separator, but using > > "tr" restricts it to a single character (which is probably all that's > > required). > > is it possible to use sed instead of tr? > sed -e "s/\n/$sep/" # doesn't work Yes, but you can't do it with a single "s" command. You would need to collect all of the input into the pattern space with the N command. This could be a problem for non-GNU versions of sed which may have a limit on the maximum length of the pattern space. OTOH, tr acts as a filter, writing out data as it processes it, so there is no limit on the amount of data. > I will have a look at merging Martin, Markus and Glynn's suggestions for > a flat output g.list flag. As the feature is needed for parsing, I'd > rather do it as a flag vs. a ncols= option which retains the text and > fancy format mapset underlines. I've never really known what the "g" > stands for, but as we use it a lot for parsable output, the flag will > be '-g' here too. > > so it would look like: > > G63> g.list -g rast > map1@user1 > map2@user1 > map3@user1 > map_a@PERMANENT > map_b@PERMANENT > map_c@PERMANENT > > G63> g.list -gf rast > map1@user1: > map2@user1:This map has a title > map3@user1: > map_a@PERMANENT:Raw x,y,z data binned into a raster grid by cell min > map_b@PERMANENT:Land Use > map_c@PERMANENT: According to G_legal_filename(), ":" is legal in map names (that won't work on Windows): if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || *s == '@' || *s == ',' || *s == '=' || *s == '*' || *s > 0176) { fprintf(stderr, _("Illegal filename. Character <%c> not allowed.\n"), *s); I'd suggest using a comma for the field separator. -- Glynn Clements From maris.gis at gmail.com Thu Sep 13 08:09:18 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Thu Sep 13 08:09:24 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18152.46448.816172.298686@cerise.gclements.plus.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <18149.35846.508751.103954@cerise.gclements.plus.com> <46E7CD1B.1080905@itc.it> <18151.61324.6182.934042@cerise.gclements.plus.com> <20070913152413.b1111594.hamish_nospam@yahoo.com> <18152.46448.816172.298686@cerise.gclements.plus.com> Message-ID: <2b3d8c1c0709122309j5579a21bmf9b684d44c7a7986@mail.gmail.com> Hi, back to old discussions? http://grass.itc.it/pipermail/grass-dev/2007-January/028510.html Just a idea - would it be possible to #IFDEF OS specific illegal chars for this function? Only problem for such approach could be tar'ing location/gisdbase and moving to other system (move *nix files with ":" to windows). Or - for GRASS 7 - get rid of map_name==file_name at all. Assign some random file name (gr_0982193) and store map name in it's header (my!@*&^*!#(*^!*@&raster). Such approach could eliminate illegal map name problem at all. Drawback - no easy way how to tell which map is stored in which file w/o GRASS (it can be solved by providing some "table of contents" file). Just trying to confuse everyone, Maris. 2007/9/13, Glynn Clements : > > According to G_legal_filename(), ":" is legal in map names (that won't > work on Windows): > > if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || > *s == '@' || *s == ',' || *s == '=' || *s == '*' || *s > 0176) { > fprintf(stderr, _("Illegal filename. Character <%c> not allowed.\n"), *s); > > I'd suggest using a comma for the field separator. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From michael.barton at asu.edu Thu Sep 13 09:03:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Sep 13 09:03:59 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim Message-ID: I finished updating the new TclTk animation module and committed it to the cvs. It does pretty much what xganim did, but with somewhat nicer interface. It also has several important improvements over xganim. Enter up to 4 animation series "views", following same format used by xganim rast[1-n],rast2[1-n],... where rast[1-n] refers to raster maps rast1,rast2,rast3,...,rastn You can also enter maps in the format, not supported by xganim rast1,rast2,rast3,...,rastn An important improvement is that xganim currently will only actually work with a series of 10 maps, rast[0-9]. Because it seek only individual characters at the end of each map in the series, it cannot recognize numbers higher than the numerals 0-9. That is 11 is simply two ones. The TclTk animator WILL recognize these as numbers, so that you can animate a series of maps limited only by system capabilities. As with xganim, single animation series will be displayed to fill the TclTk canvas window; a multi-view animation (up to 4 views) will divide the canvas into 4 subwindows with an animation series in each subwindow. Up to 4 simultaneous animations can be run. Another improvement over xganim is that you can animate series with different numbers of frames simutaneously (e.g., a multi-view animation with a 100 frame animation in one subwindow and a 20 frame animation in another subwindow). I'm not sure if the labels are working properly yet, but everything else seems to be. Give it a try and let me know if you run into any snags. 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/20070913/8cc23b46/attachment-0001.html From landa.martin at gmail.com Thu Sep 13 10:34:10 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Sep 13 10:34:14 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <46E7CDC0.3040607@itc.it> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> <46E6C3F9.9050008@o2.pl> <20070912224758.07be097d.hamish_nospam@yahoo.com> <46E7CDC0.3040607@itc.it> Message-ID: Hi, I modified my previous patch, now with -g flag... $ g.list rast map=overlay ---------------------------------------------- raster files available in mapset : r r1 $ g.list rast map=overlay -f ---------------------------------------------- raster files available in mapset : r1: test r: $ g.list rast map=overlay -g r1@overlay r@overlay $ g.list rast map=overlay -gf r1@overlay:test r@overlay: BTW the patch is really not nice, maybe it would be better to modify G_list() to add mapset to the element name automatically and lister() fn for titles... Martin 2007/9/12, Markus Neteler : > Hamish wrote on 09/12/2007 12:47 PM: > > what should a the C flat 'g.list -g' output look like? how about: > > [user1] > > map1 > > map2 > > map3 > > [PERMANENT] > > map_a > > map_b > > map_c > > > For parsing reasons, it should be > [user1] map1 > [user1] map2 > [user1] map3 > [PERMANENT] map1 > [PERMANENT] map2 > [PERMANENT] map3 > > or even > user1:map1 > user1:map2 > user1:map3 > PERMANENT:map1 > PERMANENT:map2 > PERMANENT:map3 > > and 'g.list -gf': > user1:map1:title1 > user1:map2:title2 > PERMANENT:map1:title1 > > Markus > > ------------------ > 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 > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- ? general/manage/cmd/OBJ.i686-pc-linux-gnu ? general/manage/lib/OBJ.i686-pc-linux-gnu ? general/manage/lister/OBJ.i686-pc-linux-gnu ? lib/gis/OBJ.i686-pc-linux-gnu ? lib/gis/html ? lib/gis/latex Index: general/manage/list.h =================================================================== RCS file: /home/grass/grassrepository/grass6/general/manage/list.h,v retrieving revision 1.4 diff -u -r1.4 list.h --- general/manage/list.h 13 Jan 2007 19:09:45 -0000 1.4 +++ general/manage/list.h 13 Sep 2007 08:27:41 -0000 @@ -39,6 +39,7 @@ int do_copy(int, char *, char *, char *); /* do_list.c */ int do_list(int, char *); +int do_list2(int, char *, int, int); /* do_remove.c */ int do_remove(int, char *); /* do_rename.c */ Index: general/manage/cmd/list.c =================================================================== RCS file: /home/grass/grassrepository/grass6/general/manage/cmd/list.c,v retrieving revision 1.7 diff -u -r1.7 list.c --- general/manage/cmd/list.c 12 Feb 2007 15:01:02 -0000 1.7 +++ general/manage/cmd/list.c 13 Sep 2007 08:27:41 -0000 @@ -32,7 +32,7 @@ int i, n, len; struct GModule *module; struct Option *mapset; - struct Flag *full; + struct Flag *full, *shell; init (argv[0]); @@ -48,7 +48,7 @@ element->type = TYPE_STRING; element->required = YES; element->multiple = YES; - element->description = "Data type"; + element->description = _("Data type"); for (len=0,n=0 ; n < nlist; n++) len += strlen (list[n].alias)+1; element->options = G_malloc(len); @@ -74,9 +74,16 @@ full = G_define_flag(); full->key = 'f'; - full->description = _("Verbose listing (also list map titles)"); + full->label = _("Verbose listing (also list map titles)"); + full->description = _("Prints one element per line"); #define FULL full->answer + shell = G_define_flag(); + shell->key = 'g'; + shell->label = _("Print in shell script style"); + shell->description = _("Prints one element per line"); +#define SHELL shell->answer + if (G_parser(argc, argv)) { exit(EXIT_FAILURE); @@ -92,22 +99,40 @@ while (element -> answers[i]) { n = parse(element -> answers[i]); - - if (FULL) + + /* + if (FULL) { + G_warning (_("Parameter '%s' is ignored for verbose listing"), + "1"); char lister[300]; sprintf (lister, "%s/etc/lister/%s", G_gisbase(), list[n].element[0]); G_debug(3,"lister CMD: %s",lister); - if (access (lister, 1) == 0) /* execute permission? */ + if (access (lister, 1) == 0) G_spawn (lister, lister, MAPSET, NULL); else do_list (n, MAPSET); } + else + { + */ + + /* + * if no specific mapset is requested, list the mapsets + * from the mapset search list + * otherwise just list the specified mapset + */ + if (strcmp (MAPSET, "") == 0) + { + char *mapset; + int i; + for (i = 0; (mapset = G__mapset_name (i)); i++) + do_list2 (n, mapset, SHELL ? 1 : 0, FULL ? 1 : 0); + } else { - do_list (n, MAPSET); + do_list2(n, MAPSET, SHELL ? 1 : 0, FULL ? 1: 0); } - i++; } Index: general/manage/lib/do_list.c =================================================================== RCS file: /home/grass/grassrepository/grass6/general/manage/lib/do_list.c,v retrieving revision 1.1 diff -u -r1.1 do_list.c --- general/manage/lib/do_list.c 23 Jan 2003 15:40:55 -0000 1.1 +++ general/manage/lib/do_list.c 13 Sep 2007 08:27:41 -0000 @@ -1,8 +1,87 @@ +#include #include "list.h" + +#define SEP "----------------------------------------------" + int do_list (int n, char *mapset) { G_list_element (list[n].element[0], list[n].desc[0], mapset, (int(*)())0); return 0; +} + +int do_list2 (int n, char *mapset, int shell, int full) +{ + char **elements; + int nitems; + + if (!shell) + G_message (SEP); + + /* list elements */ + elements = G_list (n+1, G_gisdbase(), G_location(), mapset); + /* deteremine number of elements */ + nitems = 0; + while (elements[nitems++]) + ; + nitems--; + + /* if shell script style print map@mapset */ + if (shell) { + int i; + char *title; + for (i = 0; i < nitems; i++) { + if (full) { + title = G_get_cell_title(elements[i], mapset); + elements[i] = (char *) G_realloc (elements[i], + strlen(elements[i]) + strlen(mapset) + + + strlen(title) + 3); + } + else { + elements[i] = (char *) G_realloc (elements[i], + strlen(elements[i]) + strlen(mapset) + 2); + } + + G_strcat ( elements[i], "@" ); + G_strcat ( elements[i], mapset); + if (full) { + G_strcat ( elements[i], ":"); + G_strcat ( elements[i], title); + G_free (title); + } + } + } + else if (full) { /* print titles */ + int i; + char * title; + for (i = 0; i < nitems; i++) { + title = G_get_cell_title(elements[i], mapset); + elements[i] = (char *) G_realloc (elements[i], + strlen(elements[i]) + strlen(title) + 3); + G_strcat ( elements[i], ": "); + G_strcat ( elements[i], title); + G_free (title); + } + } + + if (nitems > 0) { + if (!shell) + G_important_message (_("%s files available in mapset <%s>:"), + list[n].desc[0], mapset); + /* print elements */ + G_ls_format ((const char**) elements, nitems, + (shell || full) ? 1 : 0, /* one item per line */ + stdout); + } + else { + if (!shell) + G_important_message (_("no %s files available in mapset <%s>:"), + list[n].desc[0], mapset); + } + + /* free list of elements */ + G_free_list (elements); + + return nitems - 1; } Index: lib/gis/list.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/list.c,v retrieving revision 2.24 diff -u -r2.24 list.c --- lib/gis/list.c 4 Sep 2007 08:34:38 -0000 2.24 +++ lib/gis/list.c 13 Sep 2007 08:27:42 -0000 @@ -238,24 +238,56 @@ switch ( element ) { - case G_ELEMENT_RASTER: - el = "cell"; - break; - - case G_ELEMENT_GROUP: - el = "group"; - break; - - case G_ELEMENT_VECTOR: - el = "vector"; - break; - - case G_ELEMENT_REGION: - el = "windows"; - break; + case G_ELEMENT_RASTER: + el = "cell"; + break; + + case G_ELEMENT_RASTER3D: + el = "grid3"; + break; + + case G_ELEMENT_VECTOR: + el = "vector"; + break; - default: - G_fatal_error (_("G_list: Unknown element type")); + case G_ELEMENT_OLDVECTOR: + el = "dig"; + break; + + case G_ELEMENT_ASCIIVECTOR: + el = "dig_ascii"; + break; + + case G_ELEMENT_ICON: + el = "icons"; + break; + + case G_ELEMENT_LABEL: + el = "paint/labels"; + break; + + case G_ELEMENT_SITE: + el = "site_lists"; + break; + + case G_ELEMENT_REGION: + el = "windows"; + break; + + case G_ELEMENT_REGION3D: + el = "windows3d"; + break; + + case G_ELEMENT_GROUP: + el = "group"; + break; + + case G_ELEMENT_3DVIEW: + el = "3d.view"; + break; + + default: + G_fatal_error (_("G_list: Unknown element type")); } buf = (char *) G_malloc ( strlen(gisbase) + strlen(location) Index: lib/gis/ls.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/ls.c,v retrieving revision 1.8 diff -u -r1.8 ls.c --- lib/gis/ls.c 4 Sep 2007 08:34:38 -0000 1.8 +++ lib/gis/ls.c 13 Sep 2007 08:27:42 -0000 @@ -142,6 +142,9 @@ } #endif + /* Sort list of filenames alphabetically */ + qsort(list, num_items, sizeof(char *), cmp_names); + if (perline == 0) { int max_len = 0; From neteler at itc.it Thu Sep 13 10:36:15 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 13 10:36:17 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: Message-ID: <12650945.post@talk.nabble.com> Excellent! Could we have a script to launch it from command line, too, to replace "xganim" in C? Then, if all functionality is covered, we could deprecate the C version. Markus Michael Barton wrote: > > I finished updating the new TclTk animation module and committed it to the > cvs. It does pretty much what xganim did, but with somewhat nicer > interface. > It also has several important improvements over xganim. > > Enter up to 4 animation series "views", following same format used by > xganim > > rast[1-n],rast2[1-n],... > > where rast[1-n] refers to raster maps rast1,rast2,rast3,...,rastn > > You can also enter maps in the format, not supported by xganim > > rast1,rast2,rast3,...,rastn > > An important improvement is that xganim currently will only actually work > with a series of 10 maps, rast[0-9]. Because it seek only individual > characters at the end of each map in the series, it cannot recognize > numbers > higher than the numerals 0-9. That is 11 is simply two ones. The TclTk > animator WILL recognize these as numbers, so that you can animate a series > of maps limited only by system capabilities. > > As with xganim, single animation series will be displayed to fill the > TclTk > canvas window; a multi-view animation (up to 4 views) will divide the > canvas > into 4 subwindows with an animation series in each subwindow. Up to 4 > simultaneous animations can be run. > > Another improvement over xganim is that you can animate series with > different numbers of frames simutaneously (e.g., a multi-view animation > with > a 100 frame animation in one subwindow and a 20 frame animation in another > subwindow). > > I'm not sure if the labels are working properly yet, but everything else > seems to be. Give it a try and let me know if you run into any snags. > > 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 > -- View this message in context: http://www.nabble.com/TclTk-animator-finished---replaces-xganim-tf4434005.html#a12650945 Sent from the Grass - Dev mailing list archive at Nabble.com. From hamish_nospam at yahoo.com Thu Sep 13 11:02:55 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Sep 13 11:02:59 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18152.46448.816172.298686@cerise.gclements.plus.com> Message-ID: <647978.62353.qm@web52708.mail.re2.yahoo.com> > Hamish wrote: > > I will have a look at merging Martin, Markus and Glynn's suggestions for > > a flat output g.list flag. As the feature is needed for parsing, I'd > > rather do it as a flag vs. a ncols= option which retains the text and > > fancy format mapset underlines. I've never really known what the "g" > > stands for, but as we use it a lot for parsable output, the flag will > > be '-g' here too. > > > > so it would look like: ... > > G63> g.list -gf rast > > map1@user1: > > map2@user1:This map has a title > > map3@user1: > > map_a@PERMANENT:Raw x,y,z data binned into a raster grid by cell min > > map_b@PERMANENT:Land Use > > map_c@PERMANENT: > > According to G_legal_filename(), ":" is legal in map names (that won't > work on Windows): > > if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || > *s == '@' || *s == ',' || *s == '=' || *s == '*' || *s > 0176) { > fprintf(stderr, _("Illegal filename. Character <%c> not allowed.\n"), *s); > > I'd suggest using a comma for the field separator. I'm not crazy about commas as field separators as there's a good chance that the map title has some in it and a poorly written script would easily do something like "cut -d, -f2" and chop it in half. Same goes for using a single ' ' space. My two preferred choices would be : or |. ":" mimics what we use for deg:min:sec separators and makes some contextual sense as a sep. "|" mimics what we use for vector attribute column separators. (trying to reuse ideas wherever possible for consistency's sake) We could add : and | to the G_legal_filename() blacklist, even though that could hurt backwards compatibility if the fn is used to test ,,old_map names. Esp. that, as you point out, calling a map "C:" is problematic on Windows. (my vote it is to do it after making sure that g.rename doesn't call G_legal_filename() for the old map name) Using "=" for the sep seems inappropriate as - it looks funny in this context, and - "map@mapset=Some Title" wouldn't be reasonably used as eval `shell variable`. If all options are deemed too ugly I guess we could use the old \t standby. Having now looked at the g.list code all I can say is yuk. There's about 7 convoluted layers of abstraction and G_spawn()ing to executables with MINGW32 #ifdefs and pipe checking and "more" paging thrown in when AFAICT there really only needs to be 2 or 3 layers of clean C functions. general/manage/cmd/list.c general/manage/lister/{cell|vector} -> $GISBASE/etc/lister/*.exe general/manage/lib/do_list.c lib/gis/list.c lib/gis/ls.c seem like they could all be combined into just general/manage/cmd/list.c + lib/gis/ls.c My idea was to do a new simple G_list_element_flat() fn in lib/gis/list.c which just creates a G__ls() list then loops through and fprintf(out,)s the name, optionally the mapset, and optionally the sep+map title*, then closing '\n'. [*] title only makes sense if element is cell or vector, silently set to "" otherwise. I'm not really sure, Martin's patch is fine but I don't see any way to extent it to append "@mapset" and "[sep]Map Title" as G_ls_format() goes right to the stream. My idea above kind of suffers from the same problem- It seems a bit wrong to have the same function be so low level that it calls {G_}ls and so high level that it evals the result to query the map title with. It's nice to have a deep lib fn do the list but the dump to stdout has to happen after the title query and appending. I would like to avoid having the new fn rely on any of the lister stuff or pagers if at all possible. Just send result to FILE*out. (maybe I'm just not good enough in C to write my own custom function to use for the lister arg and the solution really isn't that hard, just follow the 'g.list -f' example?) So perhaps we could use this opportunity to simplify this part of the code? (about here's where I cry oceanographer not software engineer ;) Implementing 'g.list -g' SHOULD just be a 5 minute job..... but it ain't. Hamish ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From hamish_nospam at yahoo.com Thu Sep 13 11:12:32 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Sep 13 11:12:34 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: Message-ID: <235516.65369.qm@web52708.mail.re2.yahoo.com> Martin Landa wrote: > Hi, > > I modified my previous patch, now with -g flag... .. > $ g.list rast map=overlay -g > r1@overlay > r@overlay > > $ g.list rast map=overlay -gf > r1@overlay:test > r@overlay: great, thanks! > BTW the patch is really not nice, maybe it would be better to modify > G_list() to add mapset to the element name automatically and lister() > fn for titles... Agreed, see my last post. I tried to say the same thing, but was less clear. (we need to be careful about modifying very old lib fn interfaces, probably better to write a new G_list_full() or something as a wrapper so we don't break old/3rd party code) And lets dump lister/*.exe if we can- just unneeded complication IMO. Hamish ____________________________________________________________________________________ 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 hamish_nospam at yahoo.com Thu Sep 13 11:21:43 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Sep 13 11:21:46 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <12650945.post@talk.nabble.com> Message-ID: <160184.7287.qm@web52701.mail.re2.yahoo.com> Markus Neteler wrote: > Could we have a script to launch it from command line, too, to > replace "xganim" in C? Then, if all functionality is covered, we > could deprecate the C version. anyone know what "xganim" stands for? X for X11 + g for GRASS + animate? Why not call the new script d.animate rather than hold onto the old "x"? It's not like xganim is a scriptable module and we need to preserve the executable name. (ok r.game_of_life scripts it) For rigid brains we could add a symlink to the name xganim for the rest of GRASS 6, or just leave xganim alone and remove for GRASS 7. anyhow, the new version needs to be as fast, featureful, and stable as the old before we kill xganim, IMO. 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 neteler at itc.it Thu Sep 13 11:24:10 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 13 11:24:12 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <160184.7287.qm@web52701.mail.re2.yahoo.com> References: <12650945.post@talk.nabble.com> <160184.7287.qm@web52701.mail.re2.yahoo.com> Message-ID: <20070913092409.GM17093@bartok.itc.it> On Thu, Sep 13, 2007 at 02:21:43AM -0700, Hamish wrote: > Markus Neteler wrote: > > Could we have a script to launch it from command line, too, to > > replace "xganim" in C? Then, if all functionality is covered, we > > could deprecate the C version. > > anyone know what "xganim" stands for? X for X11 + g for GRASS + animate? > > Why not call the new script d.animate rather than hold onto the old "x"? excellent idea...! > It's not like xganim is a scriptable module and we need to preserve the > executable name. (ok r.game_of_life scripts it) For rigid brains we could add a > symlink to the name xganim for the rest of GRASS 6, or just leave xganim alone > and remove for GRASS 7. right. > anyhow, the new version needs to be as fast, featureful, and stable as the old > before we kill xganim, IMO. Of course. But I am so much CLI oriented that I would like to test from CLI (hopefully it is not impossible to wrap gui/tcltk/gis.m/animate.tcl into d.animate). Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From woklist at kyngchaos.com Thu Sep 13 16:15:41 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Sep 13 16:16:02 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: Message-ID: Cool! You forgot to mention that it also remove the last dependence on motif/lesstif, something non-linux systems probably don't have or need. On Sep 13, 2007, at 2:03 AM, Michael Barton wrote: > I finished updating the new TclTk animation module and committed it > to the cvs. It does pretty much what xganim did, but with somewhat > nicer interface. It also has several important improvements over > xganim. > ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From michael.barton at asu.edu Thu Sep 13 17:16:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Sep 13 17:17:23 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <12650945.post@talk.nabble.com> Message-ID: As it currently is written, animate.tcl is not a stand-alone or scriptable module. However, it could be. Glynn's original code closely mirrored xganim and so could launch an animation display from a command-line implementation with arguments of view=rast[1-n]... I needed to take some of this code out in order to make this work with the GUI and to make the functionality improvements and fixes I added. However, I'm pretty sure that it would not be difficult to make it scriptable for someone who understood better than I do BASH/TclTk interaction. The main thing that needs to be done is to start GmAnim::main (main display window and controls) and pass a list of view parameters to GmAnim::parse_viewmaps. The latter accepts a TclTk list in which each element is the series of maps for an animation view. For example {"rast[1-5]" "rast1,rast2,rast3" "rastB[1-10],rastC[1-4]"} for a 3 view animation. This is a somewhat different format than the original view1=... view2=... but gets to the same place. Michael On 9/13/07 1:36 AM, "Markus Neteler" wrote: > > Excellent! > > Could we have a script to launch it from command line, too, to > replace "xganim" in C? Then, if all functionality is covered, we > could deprecate the C version. > > Markus > > > Michael Barton wrote: >> >> I finished updating the new TclTk animation module and committed it to the >> cvs. It does pretty much what xganim did, but with somewhat nicer >> interface. >> It also has several important improvements over xganim. >> >> Enter up to 4 animation series "views", following same format used by >> xganim >> >> rast[1-n],rast2[1-n],... >> >> where rast[1-n] refers to raster maps rast1,rast2,rast3,...,rastn >> >> You can also enter maps in the format, not supported by xganim >> >> rast1,rast2,rast3,...,rastn >> >> An important improvement is that xganim currently will only actually work >> with a series of 10 maps, rast[0-9]. Because it seek only individual >> characters at the end of each map in the series, it cannot recognize >> numbers >> higher than the numerals 0-9. That is 11 is simply two ones. The TclTk >> animator WILL recognize these as numbers, so that you can animate a series >> of maps limited only by system capabilities. >> >> As with xganim, single animation series will be displayed to fill the >> TclTk >> canvas window; a multi-view animation (up to 4 views) will divide the >> canvas >> into 4 subwindows with an animation series in each subwindow. Up to 4 >> simultaneous animations can be run. >> >> Another improvement over xganim is that you can animate series with >> different numbers of frames simutaneously (e.g., a multi-view animation >> with >> a 100 frame animation in one subwindow and a 20 frame animation in another >> subwindow). >> >> I'm not sure if the labels are working properly yet, but everything else >> seems to be. Give it a try and let me know if you run into any snags. >> >> 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 >> __________________________________________ 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 Thu Sep 13 17:17:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Sep 13 17:17:54 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <235516.65369.qm@web52708.mail.re2.yahoo.com> Message-ID: As soon as this goes into the cvs, I'll modify the wxPython GIS element selection control to use the new g.list. Michael On 9/13/07 2:12 AM, "Hamish" wrote: > Martin Landa wrote: > >> Hi, >> >> I modified my previous patch, now with -g flag... > .. >> $ g.list rast map=overlay -g >> r1@overlay >> r@overlay >> >> $ g.list rast map=overlay -gf >> r1@overlay:test >> r@overlay: > > great, thanks! > >> BTW the patch is really not nice, maybe it would be better to modify >> G_list() to add mapset to the element name automatically and lister() >> fn for titles... > > Agreed, see my last post. I tried to say the same thing, but was less clear. > > (we need to be careful about modifying very old lib fn interfaces, probably > better to write a new G_list_full() or something as a wrapper so we don't > break > old/3rd party code) And lets dump lister/*.exe if we can- just unneeded > complication IMO. > > > Hamish > > > > > ______________________________________________________________________________ > ______ > 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 > > __________________________________________ 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 Thu Sep 13 17:19:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 13 17:19:35 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <46E55E20.7030602@itc.it> <20070911114601.9465b7c5.hamish_nospam@yahoo.com> <18149.64351.26767.344460@cerise.gclements.plus.com> <46E6C3F9.9050008@o2.pl> <20070912224758.07be097d.hamish_nospam@yahoo.com> <46E7CDC0.3040607@itc.it> Message-ID: <18153.21761.844936.589924@cerise.gclements.plus.com> Martin Landa wrote: > BTW the patch is really not nice, maybe it would be better to modify > G_list() to add mapset to the element name automatically and lister() > fn for titles... What (if anything) actually uses G_list()? And what's with the G_ELEMENT_* constants rather than just using the element name? -- Glynn Clements From glynn at gclements.plus.com Thu Sep 13 17:23:21 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 13 17:23:26 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <2b3d8c1c0709122309j5579a21bmf9b684d44c7a7986@mail.gmail.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <18149.35846.508751.103954@cerise.gclements.plus.com> <46E7CD1B.1080905@itc.it> <18151.61324.6182.934042@cerise.gclements.plus.com> <20070913152413.b1111594.hamish_nospam@yahoo.com> <18152.46448.816172.298686@cerise.gclements.plus.com> <2b3d8c1c0709122309j5579a21bmf9b684d44c7a7986@mail.gmail.com> Message-ID: <18153.21993.736224.21205@cerise.gclements.plus.com> Maris Nartiss wrote: > back to old discussions? > http://grass.itc.it/pipermail/grass-dev/2007-January/028510.html > > Just a idea - would it be possible to #IFDEF OS specific illegal chars > for this function? Only problem for such approach could be tar'ing > location/gisdbase and moving to other system (move *nix files with ":" > to windows). It would make more sense to prohibit the characters which are illegal on Windows for all platforms. > Or - for GRASS 7 - get rid of map_name==file_name at all. Assign some > random file name (gr_0982193) and store map name in it's header > (my!@*&^*!#(*^!*@&raster). Such approach could eliminate illegal map > name problem at all. Drawback - no easy way how to tell which map is > stored in which file w/o GRASS (it can be solved by providing some > "table of contents" file). I don't think that it's worth going that far. If we were going to do that, we would have done it for vectors, which are limited to alphanumerics and underscore due to SQL. -- Glynn Clements From glynn at gclements.plus.com Thu Sep 13 17:48:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 13 17:48:52 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <647978.62353.qm@web52708.mail.re2.yahoo.com> References: <18152.46448.816172.298686@cerise.gclements.plus.com> <647978.62353.qm@web52708.mail.re2.yahoo.com> Message-ID: <18153.23520.265561.620026@cerise.gclements.plus.com> Hamish wrote: > > > I will have a look at merging Martin, Markus and Glynn's suggestions for > > > a flat output g.list flag. As the feature is needed for parsing, I'd > > > rather do it as a flag vs. a ncols= option which retains the text and > > > fancy format mapset underlines. I've never really known what the "g" > > > stands for, but as we use it a lot for parsable output, the flag will > > > be '-g' here too. > > > > > > so it would look like: > ... > > > G63> g.list -gf rast > > > map1@user1: > > > map2@user1:This map has a title > > > map3@user1: > > > map_a@PERMANENT:Raw x,y,z data binned into a raster grid by cell min > > > map_b@PERMANENT:Land Use > > > map_c@PERMANENT: > > > > According to G_legal_filename(), ":" is legal in map names (that won't > > work on Windows): > > > > if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || > > *s == '@' || *s == ',' || *s == '=' || *s == '*' || *s > 0176) { > > fprintf(stderr, _("Illegal filename. Character <%c> not allowed.\n"), *s); > > > > I'd suggest using a comma for the field separator. > > I'm not crazy about commas as field separators as there's a good chance that > the map title has some in it and a poorly written script would easily do > something like "cut -d, -f2" and chop it in half. Same goes for using a single > ' ' space. Anything can appear in the map title. Scripts which process "full" output will have to be written correctly (i.e. break at the first occurrence) whichever separator is used. > My two preferred choices would be : or |. > ":" mimics what we use for deg:min:sec separators and makes some contextual > > sense as a sep. > "|" mimics what we use for vector attribute column separators. > > (trying to reuse ideas wherever possible for consistency's sake) Of those two, | is less likely to appear in titles. Personally, I'd choose the most common character (probably comma) as a separator so that bugs in scripts show up sooner rather than later. > We could add : and | to the G_legal_filename() blacklist, even though that > could hurt backwards compatibility if the fn is used to test ,,old_map names. > Esp. that, as you point out, calling a map "C:" is problematic on Windows. > (my vote it is to do it after making sure that g.rename doesn't call > G_legal_filename() for the old map name) I suggest only using G_legal_filename for new files/mapsets/etc. For existing files, just try to find the named object; if the name was never legal, then it won't exist. Also, : isn't valid anywhere in a filename on Windows (or on Windows filesystems generally; Linux can use FAT and SMB filesystems). > Using "=" for the sep seems inappropriate as > - it looks funny in this context, and > - "map@mapset=Some Title" wouldn't be reasonably used as eval `shell variable`. > > If all options are deemed too ugly I guess we could use the old \t standby. Again, \t is valid in titles. Actually, I'll change my preference for using a comma as the separator to a preference for using a space. That's almost certain to occur in titles (but cannot occur in names), so that will almost guarantee that any scripts handle the separator correctly. > Having now looked at the g.list code all I can say is yuk. There's about 7 > convoluted layers of abstraction and G_spawn()ing to executables with MINGW32 > #ifdefs and pipe checking and "more" paging thrown in when AFAICT there really > only needs to be 2 or 3 layers of clean C functions. > > general/manage/cmd/list.c > general/manage/lister/{cell|vector} -> $GISBASE/etc/lister/*.exe > general/manage/lib/do_list.c > lib/gis/list.c > lib/gis/ls.c > > seem like they could all be combined into just > general/manage/cmd/list.c + lib/gis/ls.c AFAICT, the "lister" idea is meant to ensure that neither g.list nor libgis needs to be updated if a new type is added to etc/element_list. IOW, the set of possible element types isn't hard-coded anywhere. But, yes, the whole setup generally is a mess. > My idea was to do a new simple G_list_element_flat() fn in lib/gis/list.c > which just creates a G__ls() list then loops through and fprintf(out,)s the > name, optionally the mapset, and optionally the sep+map title*, then closing > '\n'. > > [*] title only makes sense if element is cell or vector, silently set to "" > otherwise. libgis doesn't (and cannot) depend upon the vector libraries, so a libgis function can't get the title for a vector map. > I'm not really sure, Martin's patch is fine but I don't see any way to extent > it to append "@mapset" and "[sep]Map Title" as G_ls_format() goes right to the > stream. My idea above kind of suffers from the same problem- It seems a bit > wrong to have the same function be so low level that it calls {G_}ls and so > high level that it evals the result to query the map title with. It's nice to > have a deep lib fn do the list but the dump to stdout has to happen after the > title query and appending. > > > I would like to avoid having the new fn rely on any of the lister stuff or > pagers if at all possible. Just send result to FILE*out. (maybe I'm just not > good enough in C to write my own custom function to use for the lister arg and > the solution really isn't that hard, just follow the 'g.list -f' example?) I'd be inclined to suggest that most of G_list_element belongs in g.list rather than in libgis. However, a number of modules actually use it, so we're probably stuck with keeping it in libgis until 7.x. > So perhaps we could use this opportunity to simplify this part of the code? > (about here's where I cry oceanographer not software engineer ;) > > Implementing 'g.list -g' SHOULD just be a 5 minute job..... but it ain't. "g.list -g" probably is a 5-minute job. "g.list -gf" is likely to be rather more work, due to the need to accomodate new types in etc/element_list without re-compilation. -- Glynn Clements From glynn at gclements.plus.com Thu Sep 13 18:00:41 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 13 18:00:48 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: Message-ID: <18153.24233.346892.515653@cerise.gclements.plus.com> Michael Barton wrote: > I finished updating the new TclTk animation module and committed it to the > cvs. It does pretty much what xganim did, but with somewhat nicer interface. > It also has several important improvements over xganim. > > Enter up to 4 animation series "views", following same format used by xganim > > rast[1-n],rast2[1-n],... > > where rast[1-n] refers to raster maps rast1,rast2,rast3,...,rastn > > You can also enter maps in the format, not supported by xganim > > rast1,rast2,rast3,...,rastn This is supported by xganim; all of the view= options have ->multiple=YES. > An important improvement is that xganim currently will only actually work > with a series of 10 maps, rast[0-9]. Because it seek only individual > characters at the end of each map in the series, it cannot recognize numbers > higher than the numerals 0-9. That is 11 is simply two ones. It understands whatever the shell understands (it invokes "ls" via the shell to expand wildcards). E.g. you can use "rast[0-9][0-9]" to match rast00 through rast99 inclusive. If your maps have varying numbers of digits, you can use multiple patterns, e.g.: view1=rast[0-9],rast[1-9][0-9] to match rast0 through rast99 inclusive. -- Glynn Clements From michael.barton at asu.edu Thu Sep 13 18:04:12 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Sep 13 18:04:56 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <18153.24233.346892.515653@cerise.gclements.plus.com> Message-ID: Thanks for clarifying this. It isn't described anywhere in the xganim docs, so I was unable to get it to animate more than a few maps. The parsing in the new TclTk module is still simpler. It will correctly recognize rast[1-100]. Also, no leading 0's are needed to make the series animate in the proper order. Michael On 9/13/07 9:00 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I finished updating the new TclTk animation module and committed it to the >> cvs. It does pretty much what xganim did, but with somewhat nicer interface. >> It also has several important improvements over xganim. >> >> Enter up to 4 animation series "views", following same format used by xganim >> >> rast[1-n],rast2[1-n],... >> >> where rast[1-n] refers to raster maps rast1,rast2,rast3,...,rastn >> >> You can also enter maps in the format, not supported by xganim >> >> rast1,rast2,rast3,...,rastn > > This is supported by xganim; all of the view= options have ->multiple=YES. > >> An important improvement is that xganim currently will only actually work >> with a series of 10 maps, rast[0-9]. Because it seek only individual >> characters at the end of each map in the series, it cannot recognize numbers >> higher than the numerals 0-9. That is 11 is simply two ones. > > It understands whatever the shell understands (it invokes "ls" via the > shell to expand wildcards). E.g. you can use "rast[0-9][0-9]" to match > rast00 through rast99 inclusive. If your maps have varying numbers of > digits, you can use multiple patterns, e.g.: > > view1=rast[0-9],rast[1-9][0-9] > > to match rast0 through rast99 inclusive. __________________________________________ 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 tutey at o2.pl Thu Sep 13 22:27:46 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Sep 13 22:27:51 2007 Subject: [GRASS-dev] db.describe on non exiting table yields strange chars Message-ID: <46E99D42.4060903@o2.pl> Hi In current 6.3 CVS, running db.describe on a non exiting table yields a couple of strange chars. I was not able to paste them into the email - please see the attached screendump. Should I report this to the tracker? Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: db.describe_notable.png Type: image/png Size: 2354 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070913/43ca3268/db.describe_notable.png From neteler at itc.it Thu Sep 13 23:04:29 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 13 23:04:31 2007 Subject: [GRASS-dev] db.describe on non exiting table yields strange chars In-Reply-To: <46E99D42.4060903@o2.pl> References: <46E99D42.4060903@o2.pl> Message-ID: <12663413.post@talk.nabble.com> Maciej Sieczka wrote: > > Hi > > In current 6.3 CVS, running db.describe on a non exiting table yields a > couple of strange chars. I was not able to paste them into the email - > please see the attached screendump. Should I report this to the tracker? > No need, fixed in CVS. Markus -- View this message in context: http://www.nabble.com/db.describe-on-non-exiting-table-yields-strange-chars-tf4438252.html#a12663413 Sent from the Grass - Dev mailing list archive at Nabble.com. From neteler at itc.it Thu Sep 13 23:36:20 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Sep 13 23:36:24 2007 Subject: [GRASS-dev] db.in.ogr In-Reply-To: <46A49400.2030409@itc.it> References: <20070723215457.713ac966.hamish_nospam@yahoo.com> <46A49400.2030409@itc.it> Message-ID: <12664084.post@talk.nabble.com> I have extended db.in.ogr to also import tables from SQLite, PostgreSQL etc. See GRASS 6.3-CVS. Markus -- View this message in context: http://www.nabble.com/Re%3A--GRASS-user--db.in.ogr--was-dbf-File-not-being-Created-with-v.in.ascii--tf4128718.html#a12664084 Sent from the Grass - Dev mailing list archive at Nabble.com. From luis.parada at gmail.com Fri Sep 14 01:31:24 2007 From: luis.parada at gmail.com (k4mik4ze) Date: Fri Sep 14 01:31:28 2007 Subject: [GRASS-dev] Migracion de data de arcgis a grass Message-ID: <2a0fb2290709131631o6f3ee2b7u8e4936b483390f3d@mail.gmail.com> Que tal, quisiera saber que posiblidades de recibir informacion sobre un a migracion de data de arcGIS a grass, hay problemas de compatibilidad? hay algun proyecto que haya trabajado con eso? quiero crear una interfaz web para que usuarios en un departamento puedan consultar toda la informacion por esa via. Gracias -- !!!***k4mik4ze***!!! Linux user #383955 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070913/2aebf0e4/attachment.html From glynn at gclements.plus.com Fri Sep 14 04:13:25 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 14 04:13:32 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: <18153.24233.346892.515653@cerise.gclements.plus.com> Message-ID: <18153.60997.193330.190778@cerise.gclements.plus.com> Michael Barton wrote: > Thanks for clarifying this. It isn't described anywhere in the xganim docs, > so I was unable to get it to animate more than a few maps. > > The parsing in the new TclTk module is still simpler. It will correctly > recognize rast[1-100]. That's an odd definition of "correct". Users are likely to expect [...] to follow glob/regexp semantics (match a single character from the set), so "rast[1-100]" should be equivalent to "rast[01]". I suggest that this is fixed sooner rather than later. > Also, no leading 0's are needed to make the series > animate in the proper order. Whether or not leading zeros are required depends upon how the maps are named. A set which ends at rast99 could start at either rast0 or rast00; also, it's possible for the user to have two distinct sets named e.g. rast0 to rast9 and rast00 to rast99. -- Glynn Clements From hamish_nospam at yahoo.com Fri Sep 14 06:04:03 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 14 06:04:11 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: <12650945.post@talk.nabble.com> Message-ID: <20070914160403.8c43fd33.hamish_nospam@yahoo.com> Hi, testing out animate.tcl, ran across a couple of issues, Maps for Animation popup window: - when adding a map the map name(s) always get ", " before them for the first map. - why is there an Apply button? - when I hit Ok I get this error: ERROR: ** invalid input ** ERROR: ** invalid input ** while executing "exec g.region res=$pnmres" (procedure "GmAnim::switch_res" line 29) invoked from within "GmAnim::switch_res 1" (procedure "GmAnim::load_files" line 47) invoked from within "GmAnim::load_files" (procedure "GmAnim::do_run" line 29) invoked from within "GmAnim::do_run" (procedure "GmAnim::parse_viewmaps" line 68) invoked from within "GmAnim::parse_viewmaps $viewlist" (procedure "GmAnim::create_viewlist" line 33) invoked from within "GmAnim::create_viewlist 1" ("uplevel" body line 1) invoked from within "uplevel \#0 $cmd" (procedure "Button::_release" line 18) invoked from within "Button::_release .animmaps_win.buttons.a" (command bound to event) Main window- when I hit exit I get this error over and over and have to use xkill to get rid of it (taking down gis.m too): ERROR: ** invalid input ** ERROR: ** invalid input ** while executing "exec g.region nsres=$oldres1 ewres=$oldres2" (procedure "GmAnim::cmd_exit" line 19) invoked from within "GmAnim::cmd_exit" (command bound to event) ? Hamish From hamish_nospam at yahoo.com Fri Sep 14 06:13:35 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 14 06:13:41 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: Message-ID: <20070914161335.1226407c.hamish_nospam@yahoo.com> Michael Barton wrote: > > I finished updating the new TclTk animation module and committed it to > the cvs. It does pretty much what xganim did, but with somewhat nicer > interface. It also has several important improvements over xganim. One thing I have wanted in a GRASS animation tool is the ability to take a 3D raster block and animate through the z-layers without having to do run r3.to.rast first then remove all the sections after. Especially if the z-axis represents a time-series. A more advanced version could slide through the x or y axis, or, if you want to get really tricky, normal to an arbitrary plane. Maybe the fancy stuff is better left for nviz cutting planes and just try for the z-layers. Hamish From hamish_nospam at yahoo.com Fri Sep 14 06:17:53 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 14 06:18:00 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <2b3d8c1c0709122309j5579a21bmf9b684d44c7a7986@mail.gmail.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <18149.35846.508751.103954@cerise.gclements.plus.com> <46E7CD1B.1080905@itc.it> <18151.61324.6182.934042@cerise.gclements.plus.com> <20070913152413.b1111594.hamish_nospam@yahoo.com> <18152.46448.816172.298686@cerise.gclements.plus.com> <2b3d8c1c0709122309j5579a21bmf9b684d44c7a7986@mail.gmail.com> Message-ID: <20070914161753.215d87e1.hamish_nospam@yahoo.com> Maris Nartiss wrote: > Just a idea - would it be possible to #IFDEF OS specific illegal chars > for this function? Only problem for such approach could be tar'ing > location/gisdbase and moving to other system (move *nix files with ":" > to windows). > Or - for GRASS 7 - get rid of map_name==file_name at all. Assign some > random file name (gr_0982193) and store map name in it's header > (my!@*&^*!#(*^!*@&raster). Such approach could eliminate illegal map > name problem at all. Drawback - no easy way how to tell which map is > stored in which file w/o GRASS (it can be solved by providing some > "table of contents" file). For me, I use "locate" and "find" all the time to find what mapset I put something in. To have to use find+grep would be a pain. 2c Hamish From hamish_nospam at yahoo.com Fri Sep 14 06:24:09 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 14 06:24:27 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18153.23520.265561.620026@cerise.gclements.plus.com> References: <18152.46448.816172.298686@cerise.gclements.plus.com> <647978.62353.qm@web52708.mail.re2.yahoo.com> <18153.23520.265561.620026@cerise.gclements.plus.com> Message-ID: <20070914162409.73b26ba3.hamish_nospam@yahoo.com> Glynn Clements wrote: > > We could add : and | to the G_legal_filename() blacklist, even though > > that could hurt backwards compatibility if the fn is used to > > test ,,old_map names. Esp. that, as you point out, calling a map "C:" > > is problematic on Windows. (my vote it is to do it after making sure > > that g.rename doesn't call G_legal_filename() for the old map name) > > I suggest only using G_legal_filename for new files/mapsets/etc. For > existing files, just try to find the named object; if the name was > never legal, then it won't exist. FWIW I just tested this by renaming a vector/ map dir in the file system to put a space in the name, g.list shows it but g.rename gives an error: G:vector > g.rename vect="map 1","map:1" Illegal filename. Character < > not allowed. WARNING: vector not found [g.list -gf] Hamish: > > > map2@user1:This map has a title > My two preferred choices would be : or |. > ":" mimics what we use for deg:min:sec separators and makes some > contextual sense as a sep. > "|" mimics what we use for vector attribute column separators. > > (trying to reuse ideas wherever possible for consistency's sake) Glynn: > Actually, I'll change my preference for using a comma as the separator > to a preference for using a space. That's almost certain to occur in > titles (but cannot occur in names), so that will almost guarantee that > any scripts handle the separator correctly. a space is fine with me... Hamish From hmitaso at unity.ncsu.edu Fri Sep 14 06:39:01 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Sep 14 06:39:05 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <20070914161335.1226407c.hamish_nospam@yahoo.com> References: <20070914161335.1226407c.hamish_nospam@yahoo.com> Message-ID: <9C1E0A84-5F5A-4152-9C46-38A5B8B1F027@unity.ncsu.edu> On Sep 14, 2007, at 12:13 AM, Hamish wrote: > Michael Barton wrote: >> >> I finished updating the new TclTk animation module and committed >> it to >> the cvs. It does pretty much what xganim did, but with somewhat nicer >> interface. It also has several important improvements over xganim. > > > One thing I have wanted in a GRASS animation tool is the ability to > take > a 3D raster block and animate through the z-layers without having > to do > run r3.to.rast first then remove all the sections after. we have included few examples of such use of xganim in the new GRASS book - I have found it very useful for pre-viewing the volume data in a quick and efficient way before going into nviz - probably a script could be written to automate the procedure. I have also used d.slide.show along with xganim. So a script - volume slicer? - that will either slice through the volume using xganim or display the slices as a series of still slides would be really useful Helena one of the (very simple) examples from the book using the nc_spm data # create a volume g.region rural_1m res3=3 t=132 b=102 tbres=2 -ap3 r.to.rast3elev -l soils_Kfactor elev=elev_lid792_1m out=soils_Kvol r3.info soils_Kvol # convert to horiz. slices and display r3.to.rast soils_Kvol out=soils_Kvolslice d.slide.show soils_Kvolslice xganim view1="soils_Kvolslice*" > Especially if the > z-axis represents a time-series. A more advanced version could slide > through the x or y axis, or, if you want to get really tricky, > normal to > an arbitrary plane. Maybe the fancy stuff is better left for nviz > cutting > planes and just try for the z-layers. > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From michael.barton at asu.edu Fri Sep 14 07:32:40 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 14 07:33:17 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <20070914160403.8c43fd33.hamish_nospam@yahoo.com> Message-ID: Hamish, Thanks for testing. Responses (sort of) below. On 9/13/07 9:04 PM, "Hamish" wrote: > Hi, > > testing out animate.tcl, ran across a couple of issues, > > Maps for Animation popup window: > - when adding a map the map name(s) always get ", " before them for the > first map. This is only supposed to happen if you already have a map in the entry box, so you can add multiple maps. I'll see why it is doing this with the first map. > > - why is there an Apply button? So you can set and change files to animate without closing the map select window. > > - when I hit Ok I get this error: > > ERROR: ** invalid input ** > ERROR: ** invalid input ** I don't know. Are you per chance working in a latlong region? Michael > while executing > "exec g.region res=$pnmres" > (procedure "GmAnim::switch_res" line 29) > invoked from within > "GmAnim::switch_res 1" > (procedure "GmAnim::load_files" line 47) > invoked from within > "GmAnim::load_files" > (procedure "GmAnim::do_run" line 29) > invoked from within > "GmAnim::do_run" > (procedure "GmAnim::parse_viewmaps" line 68) > invoked from within > "GmAnim::parse_viewmaps $viewlist" > (procedure "GmAnim::create_viewlist" line 33) > invoked from within > "GmAnim::create_viewlist 1" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 18) > invoked from within > "Button::_release .animmaps_win.buttons.a" > (command bound to event) > > > Main window- when I hit exit I get this error over and over and have to > use xkill to get rid of it (taking down gis.m too): > > ERROR: ** invalid input ** > ERROR: ** invalid input ** > while executing > "exec g.region nsres=$oldres1 ewres=$oldres2" > (procedure "GmAnim::cmd_exit" line 19) > invoked from within > "GmAnim::cmd_exit" > (command bound to event) > > > > ? > 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 michael.barton at asu.edu Fri Sep 14 07:33:44 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 14 07:34:12 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <20070914161335.1226407c.hamish_nospam@yahoo.com> Message-ID: This would be really nice, but would require some very different kind of programming. Michael On 9/13/07 9:13 PM, "Hamish" wrote: > Michael Barton wrote: >> >> I finished updating the new TclTk animation module and committed it to >> the cvs. It does pretty much what xganim did, but with somewhat nicer >> interface. It also has several important improvements over xganim. > > > One thing I have wanted in a GRASS animation tool is the ability to take > a 3D raster block and animate through the z-layers without having to do > run r3.to.rast first then remove all the sections after. Especially if the > z-axis represents a time-series. A more advanced version could slide > through the x or y axis, or, if you want to get really tricky, normal to > an arbitrary plane. Maybe the fancy stuff is better left for nviz cutting > planes and just try for the z-layers. > > > 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 michael.barton at asu.edu Fri Sep 14 07:58:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 14 07:59:18 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <18153.60997.193330.190778@cerise.gclements.plus.com> Message-ID: On 9/13/07 7:13 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> Thanks for clarifying this. It isn't described anywhere in the xganim docs, >> so I was unable to get it to animate more than a few maps. >> >> The parsing in the new TclTk module is still simpler. It will correctly >> recognize rast[1-100]. > > That's an odd definition of "correct". Users are likely to expect > [...] to follow glob/regexp semantics (match a single character from > the set), so "rast[1-100]" should be equivalent to "rast[01]". Command line Linux users and programmers who use glob/regexp semantics might well expect this. Non-programmer users, especially of non-Linux platforms probably will understand [1-100] as meaning from 1 to 100. In either case, it needs to go into the docs so that a user will know how to specify maps that end in 1 to 100 [1-100] or [1-9][0-9][0] The latter is harder to explain in docs than the former to someone not familiar with regexp--and even some of us familiar with it. > > I suggest that this is fixed sooner rather than later. The way it was, it had BASH commands (i.e., grep) to parse the output of g.list, followed by a TclTk string match to find the maps that matched the [n-n] pattern. I tried to use the matches as a validation routine, using pure TclTk parsing, but was unable to get reliable matches and decided that I probably didn't need to validate at that point because an invalid map would be caught later. I'm not convinced that a regexp syntax is easier for users to deal with. But maybe it would be potentially less confusing to programmers if parentheses instead of brackets were used. rast(1-100) instead of rast[1-100]? Will the regexp pattern match syntax permit the use of * and correctly handle maps whose number suffixes are padded with leading 0's? Or does it just handle the bracketed character ranges? Michael > >> Also, no leading 0's are needed to make the series >> animate in the proper order. > > Whether or not leading zeros are required depends upon how the maps > are named. A set which ends at rast99 could start at either rast0 or > rast00; also, it's possible for the user to have two distinct sets > named e.g. rast0 to rast9 and rast00 to rast99. __________________________________________ 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 neteler at itc.it Fri Sep 14 10:12:34 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Sep 14 10:12:35 2007 Subject: [GRASS-dev] g.mlist as C implementation? In-Reply-To: <18151.61324.6182.934042@cerise.gclements.plus.com> References: <20070909190455.GB8769@bartok.itc.it> <18148.35529.597752.912149@cerise.gclements.plus.com> <20070910155200.35f8eb18.hamish_nospam@yahoo.com> <18149.35846.508751.103954@cerise.gclements.plus.com> <46E7CD1B.1080905@itc.it> <18151.61324.6182.934042@cerise.gclements.plus.com> Message-ID: <46EA4272.5040502@itc.it> Glynn Clements wrote on 09/12/2007 03:54 PM: > Markus Neteler wrote: > >> It appears that Hamish's implementation based on Glynn's former notes >> is much faster: >> time sh g.mlist_glynn type=rast map=neteler pat="map*" >> real 0m1.200s >> user 0m0.749s >> sys 0m0.464s >> >> time sh g.mlist_hamish type=rast map=neteler pat="map*" >> real 0m0.338s >> user 0m0.190s >> sys 0m0.052s >> >> Is that the contribution to portability? :) >> > > ... > > I've committed an update which has no loops other than the top-level > "for mapset in $mapsets" loop. > I can report a significant speed-up up (CVS version from Glynn): real 0m0.305s user 0m0.164s sys 0m0.062s So "latest Glynn" now corresponds to "Hamish" version. Thanks, Markus PS: Any objections to backport to 6.2 (for 6.2.3)? ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Fri Sep 14 11:24:10 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Sep 14 11:24:13 2007 Subject: [GRASS-dev] wxgrass fails with white space in grass data path Message-ID: <46EA533A.30904@itc.it> Hi, to test if and when GRASS fails with white space in the data path, I have changed (on my Linux box) "$HOME/grassdata/" to $HOME/grass data/". Besides a failure in command line startup: grass63 "$HOME/grass data/spearfish60/user1" Cleaning up temporary files..... Starting GRASS ... The LOCATION "neteler" does not exist. Please create first BUT: ls -la "$HOME/grass data/spearfish60/user1" total 112 drwxr-xr-x 16 neteler ssi 4096 Aug 17 18:36 . drwx------ 10 neteler ssi 4096 Aug 6 13:54 .. -rw------- 1 neteler ssi 28956 Aug 17 18:36 .bash_history ... I found that "wxgrass" fails, too. This could be of interest for the MS-Windows portability: GRASS 6.3.cvs (nc_spm_06):~/grassaddons/gui > Sorry is not a valid option Sorry is not a valid option Sorry is not a valid option Could not run g.pnmcomp GRASS 6.3.cvs (nc_spm_06):~/grassaddons/gui > g.gisenv GISDBASE=/nfsmnt/ssi0/ssi/neteler/grass data DEBUG=0 MAPSET=neteler LOCATION_NAME=nc_spm_06 GRASS_GUI=text I recommend that (wxgrass) developers also put a white space into their grassdata/ path to easily trap problems like above. Most problems will be trivial quoting issues. 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 Sep 14 12:10:32 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Fri Sep 14 12:03:12 2007 Subject: [GRASS-dev] [grass-code I][483] tcl/tk GUI windows exit with status 1 instead of 0 Message-ID: <20070914101032.63B2740282@pyrosoma.intevation.org> code I item #483, was opened at 2007-09-14 12:10 Status: Open Priority: 5 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: tcl/tk GUI windows exit with status 1 instead of 0 Issue type: library bug Issue status: None GRASS version: CVS HEAD GRASS component: tcl/tk GUI Operating system: None Operating system version: Ubuntu Dapper GNU/Linux GRASS CVS checkout date, if applies (YYMMDD): 070914 Initial Comment: tcl/tk GUI windows exit with status 1 even if no error took place. To reproduce: 1. v.info [Enter] (or any other command) 2. press "Close" 3. echo $? The result is "1" like if there was an error. There wasn't, so it should be "0". I can reproduce this in 6.2 CVS and older 6.3 instalations (dating back to April 2007), so it seems not a newly introduced bug. Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=483&group_id=21 From hamish_nospam at yahoo.com Fri Sep 14 12:28:18 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Sep 14 12:28:21 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: Message-ID: <597841.99111.qm@web52708.mail.re2.yahoo.com> HB: > > - why is there an Apply button? MB: > So you can set and change files to animate without closing the map select > window. Would you ever really do that in practice (selectively add/remove frames)? To me 99% of the time Apply buttons seem like unneeded clutter & confusing. But then I don't like to work with a half dozen windows open at the same time for a single app., so maybe just a reflection of my preference. The "GPSMan" software was aweful for this, and I've got similar issues with the tcl gis.m-- but no better ideas about how to do it so I try to keep quiet about it. (Old version of star|open office was annoying in the other extreme of everything in 1 window) > > - when I hit Ok I get this error: > > > > ERROR: ** invalid input ** > > ERROR: ** invalid input ** > > I don't know. Are you per chance working in a latlong region? simple XY (255 frames from r.game_of_life script) | Projection: x,y | N: 90 S: -90 Res: 0.01666512 | E: 180 W: -180 Res: 0.0166659 | Range of data: min = 0 max = 255 I tried another: | Projection: x,y | N: 90 S: -90 Res: 0.17578125 | E: 180 W: -180 Res: 0.28125 | Range of data: min = 0 max = 255 same thing. then I tried an orthophoto with a res of 1m, and it loaded the image ok. So resolutions less than 1 are being truncated/recast to 0?? Hamish ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From neteler at itc.it Fri Sep 14 13:47:23 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Sep 14 13:47:25 2007 Subject: [GRASS-dev] GRASS 7 Migration from CVS to SVN Message-ID: <20070914114723.GD14995@bartok.itc.it> 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 ------------------ From michael.barton at asu.edu Fri Sep 14 17:11:51 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 14 17:12:16 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <597841.99111.qm@web52708.mail.re2.yahoo.com> Message-ID: Sounds like you found the problem. Somewhere I need to make a variable float. I'll try to track it down. Thanks much. Michael On 9/14/07 3:28 AM, "Hamish" wrote: > simple XY (255 frames from r.game_of_life script) > > | Projection: x,y > | N: 90 S: -90 Res: 0.01666512 > | E: 180 W: -180 Res: 0.0166659 > | Range of data: min = 0 max = 255 > > I tried another: > > | Projection: x,y > | N: 90 S: -90 Res: 0.17578125 > | E: 180 W: -180 Res: 0.28125 > | Range of data: min = 0 max = 255 > > same thing. > > > then I tried an orthophoto with a res of 1m, and it loaded the image ok. > > So resolutions less than 1 are being truncated/recast to 0?? > __________________________________________ 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 Fri Sep 14 17:24:00 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 14 17:25:00 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: Message-ID: On 9/13/07 10:58 PM, "Michael Barton" wrote: > > > > On 9/13/07 7:13 PM, "Glynn Clements" wrote: > >> >> Michael Barton wrote: >> >>> Thanks for clarifying this. It isn't described anywhere in the xganim docs, >>> so I was unable to get it to animate more than a few maps. >>> >>> The parsing in the new TclTk module is still simpler. It will correctly >>> recognize rast[1-100]. >> >> That's an odd definition of "correct". Users are likely to expect >> [...] to follow glob/regexp semantics (match a single character from >> the set), so "rast[1-100]" should be equivalent to "rast[01]". > > Command line Linux users and programmers who use glob/regexp semantics might > well expect this. Non-programmer users, especially of non-Linux platforms > probably will understand [1-100] as meaning from 1 to 100. In either case, it > needs to go into the docs so that a user will know how to specify maps that > end in 1 to 100 > > [1-100] or [1-9][0-9][0] > > The latter is harder to explain in docs than the former to someone not > familiar with regexp--and even some of us familiar with it. > After sleeping on this, I think the best solution is (as often the case) to have both kinds of syntax--a conceptually simpler kind rast(1-100) and still allow the more complex but more flexible glob/regexp syntax for those who understand and love it. Are parens OK for this? I don't think we would normally expect them in map names. If we go back to the pattern match routine you originally used (with TclTk string match) and combine it with my parsing of rast[1-n], this should be doable. The main problem I think I was having with a pure TclTk implementation of this was not parsing the multicolumn format of g.list correctly. I can switch to g.mlist for the moment and switch back to g.list when flat output becomes available. The latter is preferable because it doesn't risk hitting bashisms that won't run on Windows (i.e., in the g.mlist script). I'll see what I can do over the weekend. 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 michael.barton at asu.edu Fri Sep 14 17:33:40 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 14 17:34:06 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <597841.99111.qm@web52708.mail.re2.yahoo.com> Message-ID: On 9/14/07 3:28 AM, "Hamish" wrote: > HB: >>> - why is there an Apply button? > MB: >> So you can set and change files to animate without closing the map select >> window. > > Would you ever really do that in practice (selectively add/remove frames)? > To me 99% of the time Apply buttons seem like unneeded clutter & confusing. > But > then I don't like to work with a half dozen windows open at the same time for > a > single app., so maybe just a reflection of my preference. The "GPSMan" > software > was aweful for this, and I've got similar issues with the tcl gis.m-- but no > better ideas about how to do it so I try to keep quiet about it. (Old version > of star|open office was annoying in the other extreme of everything in 1 > window) > Of course I've only tested this with hypothetical data so far--though I'll be using real simulation output in the next few days. But it was actually testing and resting to make me think of a possible workflow where "apply" is useful. For example... Start animator Look at rast1 - rast99 series output How does that compare with the oldrast series? Add oldrast1 - oldrast99 into view 2 and hit apply Hmmm. Comparison looks interesting. But what is actually happening in oldrast50 - oldrast75. It's too small in the multiview window to see. Clear out the prior entries and just put oldrast[50-75] into view 1. Hit apply. OK. Now I see. Is the same thing happening in rast50 - rast75? replace oldrast in view1 with rast[50-75]. Hit apply. Without apply, you hit OK and the map selection window closes. Then you have to reopen it and enter from scratch when you want to change something. I could rename apply to OK and have a close button. However, the OK button is like a combination of OK and close, and is a default that is activated when you hit the return key, which is also handy sometimes. 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 dylan.beaudette at gmail.com Fri Sep 14 19:27:41 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Sep 14 19:27:48 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <20070914114723.GD14995@bartok.itc.it> References: <20070914114723.GD14995@bartok.itc.it> Message-ID: <200709141027.41170.dylan.beaudette@gmail.com> On Friday 14 September 2007, 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. Good point Markus. I have been wondering about new development, and migration to SVN- looks like they are connected. > 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 This contains a good summary. > 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. I vote +1 (?) for moving to SVN as hosted by OSGeo.org. After spending some time with Trac on my own projects I have really come to like it. Furthermore, integration with the rest of OSGeo would be a good thing. Having the source code next to projects like GDAL, Mapserver, etc. might even entice some new developers into the GRASS community. > Please visit the Wiki page and come up with > comments. I cc to the grass-dev list to reach > all interested people. > > Markus Thanks Markus. Cheers, Dylan > 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-psc mailing list > grass-psc@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-psc -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From warmerdam at pobox.com Fri Sep 14 19:48:39 2007 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Sep 14 19:41:55 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <200709141027.41170.dylan.beaudette@gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <200709141027.41170.dylan.beaudette@gmail.com> Message-ID: <46EAC977.6060501@pobox.com> Dylan Beaudette wrote: > I vote +1 (?) for moving to SVN as hosted by OSGeo.org. After spending some > time with Trac on my own projects I have really come to like it. Furthermore, > integration with the rest of OSGeo would be a good thing. Having the source > code next to projects like GDAL, Mapserver, etc. might even entice some new > developers into the GRASS community. Dylan, I'll second the benefits of Trac coupled with Subversion! I was a bit of a sceptic a year ago, figure it would be just another bug system, and just another source control system but they have individually improved the GDAL project, and the integration between them has been the icing on the cake. For instance, the ease with which tickets (bugs) can refer to source control changesets and the "timeline" page showing commits, ticket updates (and wiki changes). All that aside, I think there are social and shared support benefits to a common infrastructure, and I'd love to see GRASS at OSGeo but those are softer points, and I'm obviously biased. :-) 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 massimiliano.cannata at supsi.ch Fri Sep 14 19:47:44 2007 From: massimiliano.cannata at supsi.ch (Massimiliano Cannata) Date: Fri Sep 14 19:48:54 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <46EAC977.6060501@pobox.com> References: <20070914114723.GD14995@bartok.itc.it> <200709141027.41170.dylan.beaudette@gmail.com> <46EAC977.6060501@pobox.com> Message-ID: <46EAC940.6070302@supsi.ch> HI all, I'm not an expert of those system. But looking at the Markus resume, I suppose that OSGeo can offer a lot of advantages. Moreover I also like the idea to be on the side of other OSGeo project. Maxi Frank Warmerdam wrote: > Dylan Beaudette wrote: >> I vote +1 (?) for moving to SVN as hosted by OSGeo.org. After >> spending some time with Trac on my own projects I have really come to >> like it. Furthermore, integration with the rest of OSGeo would be a >> good thing. Having the source code next to projects like GDAL, >> Mapserver, etc. might even entice some new developers into the GRASS >> community. > > Dylan, > > I'll second the benefits of Trac coupled with Subversion! I was a bit of > a sceptic a year ago, figure it would be just another bug system, and > just another source control system but they have individually improved > the GDAL project, and the integration between them has been the icing on > the cake. For instance, the ease with which tickets (bugs) can refer to > source control changesets and the "timeline" page showing commits, ticket > updates (and wiki changes). > > All that aside, I think there are social and shared support benefits to > a common infrastructure, and I'd love to see GRASS at OSGeo but those are > softer points, and I'm obviously biased. :-) > > Best regards, -------------- next part -------------- A non-text attachment was scrubbed... Name: massimiliano.cannata.vcf Type: text/x-vcard Size: 411 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070914/dd2a6bda/massimiliano.cannata.vcf From glynn at gclements.plus.com Fri Sep 14 19:52:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 14 19:52:12 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <20070914160403.8c43fd33.hamish_nospam@yahoo.com> References: <12650945.post@talk.nabble.com> <20070914160403.8c43fd33.hamish_nospam@yahoo.com> Message-ID: <18154.51784.321093.208790@cerise.gclements.plus.com> Hamish wrote: > Main window- when I hit exit I get this error over and over and have to > use xkill to get rid of it (taking down gis.m too): > > ERROR: ** invalid input ** > ERROR: ** invalid input ** > while executing > "exec g.region nsres=$oldres1 ewres=$oldres2" > (procedure "GmAnim::cmd_exit" line 19) > invoked from within > "GmAnim::cmd_exit" > (command bound to event) It should be using $WIND_OVERRIDE or $GRASS_REGION, *not* modifying the WIND file. -- Glynn Clements From glynn at gclements.plus.com Fri Sep 14 20:08:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 14 20:08:51 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: <18153.60997.193330.190778@cerise.gclements.plus.com> Message-ID: <18154.52781.998022.949469@cerise.gclements.plus.com> Michael Barton wrote: > >> Thanks for clarifying this. It isn't described anywhere in the xganim docs, > >> so I was unable to get it to animate more than a few maps. > >> > >> The parsing in the new TclTk module is still simpler. It will correctly > >> recognize rast[1-100]. > > > > That's an odd definition of "correct". Users are likely to expect > > [...] to follow glob/regexp semantics (match a single character from > > the set), so "rast[1-100]" should be equivalent to "rast[01]". > > Command line Linux users and programmers who use glob/regexp semantics might > well expect this. As will anyone familiar with xganim. > Non-programmer users, especially of non-Linux platforms > probably will understand [1-100] as meaning from 1 to 100. They won't be expecting [...] to mean anything. > In either case, > it needs to go into the docs so that a user will know how to specify maps > that end in 1 to 100 > > [1-100] or [1-9][0-9][0] > > The latter is harder to explain in docs than the former to someone not > familiar with regexp--and even some of us familiar with it. If you want to provide a convenient mechanism for numbered sequences, use a different syntax; don't use glob/regexp/xganim syntax then interpret it differently. > > I suggest that this is fixed sooner rather than later. > > The way it was, it had BASH commands (i.e., grep) to parse the output of > g.list, followed by a TclTk string match to find the maps that matched the > [n-n] pattern. I tried to use the matches as a validation routine, using > pure TclTk parsing, but was unable to get reliable matches and decided that > I probably didn't need to validate at that point because an invalid map > would be caught later. > > I'm not convinced that a regexp syntax is easier for users to deal with. Users will need to know either regexp or glob syntax to make use of e.g. "g.mlist ... pat=..." (and thus g.mremove, maybe others). And you can't get very far on Linux without learning to use either or both of glob and regexp syntax. > But > maybe it would be potentially less confusing to programmers if parentheses > instead of brackets were used. rast(1-100) instead of rast[1-100]? Yes. Also, any "sequence" patterns need to handle names with or without leading zeros (i.e. both rast(001-100) and rast(1-100)). If you have a choice, you're probably going to prefer to use leading zeros so that map names sort correctly. > Will the regexp pattern match syntax permit the use of * and correctly > handle maps whose number suffixes are padded with leading 0's? Or does it > just handle the bracketed character ranges? Both regexp and glob syntax treat [...] as meaning a single character from the specified set. With regexps, you can then apply operators (i.e. *, +, ?, {n,m}) if you want to match a variable number of those characters. glob patterns are "flat", i.e. there are no operators which can be applied to existing expressions to construct more complex expressions. E.g. if you want to match a three-digit number, you need to use [0-9][0-9][0-9]. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Fri Sep 14 20:40:59 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Sep 14 20:41:06 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <20070914114723.GD14995@bartok.itc.it> References: <20070914114723.GD14995@bartok.itc.it> Message-ID: Hello Markus On Fri, 14 Sep 2007, 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. I would say not necessarily - a release branch could be created for the next stable release and then the major changes for 7 made in the CVS HEAD. But I think what we more or less decided in the last discussion was that we would use the move to SVN as a "crutch" to aid the 6.x/7.x development split. So in that sense you're right. As long as we all understand the implications of that (especially with regard to where to make bug fixes and where to add new development) then I think it will actually be a good help. > 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 (out of interest - where is the OSGeo SVN server physically located and who is the sysadmin for it?) I think (as Helena initially suggested in the last discussion) we should move to the OSGeo infrastructure, primarily for the social/shared support benefits Frank outlines. I just think we have to be clear that we're not proposing leaving Intevation because of any deficiencies with the infrastructure there - I can only say it's been amazingly reliable for years with almost no downtime at all and to my knowledge never a bug or an issue to report. Bernhard has always been there when needed to sort out any queries with access to the CVS server. He's been about for a while now and as far as I can make out from the mailing list archives was one of the major influences in actually having GRASS released under the GPL, and I think we owe him a lot of thanks for all his support of GRASS. I wonder is it reasonable to expect Intevation to continue to support our old CVS repositories (grass, grass6, web, libgrass - are there any others) when we move the latest developments to a new infrastructure - perhaps we should simply move the whole thing to SVN? I don't know if they have any other projects using their CVS server - they might wish to close it down once we leave, to reduce the maintenance/support effort of maintaining it. This is where I have slight reservations about the idea of using the move to SVN as a split-point in 6.x/7.x development: are we going to simply copy the grass7 repository in its entirety and rename it something like grass7? Or are we going to subtly modify the files and then reimport them into grass7. I'm not quite sure what's the plan and this certainly needs to be ironed out. As to the other benefits of the OSGeo infrastructure (apart from community/social integration with the other projects), if the bug tracker / repository integration works out well then that would be a nice added bonus. I have to say the way you couldn't Cc e-mail discussions into the Gforge bug tracker like you could with the old RT one was a big downside to using it more for me - I wonder does Trac have that capability? Paul From neteler.osgeo at gmail.com Fri Sep 14 21:01:29 2007 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Fri Sep 14 21:01:36 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: References: <20070914114723.GD14995@bartok.itc.it> Message-ID: <86782b610709141201i2db71c81wf8464b2639f334f6@mail.gmail.com> Hello Paul, On 9/14/07, Paul Kelly wrote: > Hello Markus > > On Fri, 14 Sep 2007, 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. > > I would say not necessarily - a release branch could be created for the > next stable release and then the major changes for 7 made in the CVS HEAD. Well, the expected (heavy) moving around of files is rather a pain in CVS while easy in SVN. The risk of messing everything up in SVN is low (while no guarantee in CVS, we already have some odd files there which Martin discovered in his attempts to convert to SVN). > But I think what we more or less decided in the last discussion was that > we would use the move to SVN as a "crutch" to aid the 6.x/7.x development > split. So in that sense you're right. As long as we all understand the > implications of that (especially with regard to where to make bug fixes > and where to add new development) then I think it will actually be a good > help. Additionally, the user management is way easier. We could grant restricted "translator" access and so forth while there is only global access for CVS. Just check our previous discussions about CVS vs SVN. > > 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 > (out of interest - where is the OSGeo SVN server physically located and > who is the sysadmin for it?) > > I think (as Helena initially suggested in the last discussion) we should > move to the OSGeo infrastructure, primarily for the social/shared support > benefits Frank outlines. I just think we have to be clear that we're not > proposing leaving Intevation because of any deficiencies with the > infrastructure there - I can only say it's been amazingly reliable for > years with almost no downtime at all and to my knowledge never a bug or an > issue to report. Bernhard has always been there when needed to sort out > any queries with access to the CVS server. He's been about for a while > now and as far as I can make out from the mailing list archives was one > of the major influences in actually having GRASS released under the GPL, > and I think we owe him a lot of thanks for all his support of GRASS. Absolutely no doubts about that! Intevation - Bernhard - Jan - the team there have greatly supported GRASS and luckily much influenced the decision to go for GPL and CVS! We are all most grateful to them. > I wonder is it reasonable to expect Intevation to continue to support our > old CVS repositories (grass, grass6, web, libgrass - are there any others) > when we move the latest developments to a new infrastructure - perhaps we > should simply move the whole thing to SVN? That is not so easy once it comes to branches. With Martin I discussed what about moving only HEAD to SVN and keeping all other in CVS (hoping that Intevation is keeping support for us). The GRASS 6.x would then continue there (basically bug fix releases which we'll have for longer time). Concering Web, we'll have to see if to change (since I am doing most of it alone and did not manage to get much folks involved over the years). But that's a different discussion. > I don't know if they have any > other projects using their CVS server - they might wish to close it down > once we leave, to reduce the maintenance/support effort of maintaining it. I only know about - grass (which is GRASS 5) - grass6 (which wil hopefully GRASS 7 one day) - web (us again) - libgrass (Frank, but dead since there is the plugin) - newsletter/ (meanwhile OSGeo Journal, hosted there) - grass_doc/ (dead, don't even remembered that is was there) - progmangrass50/ (all doxygen now) That's all (see http://freegis.org/cgi-bin/viewcvs.cgi/ ). Migration candidate is only grass6/ there, and probably only for HEAD. It would be important to keep all other repositories alive there. (There is another Wiki document discussing the technical issues of CVS -> SVN migration). > This is where I have slight reservations about the idea of using the move > to SVN as a split-point in 6.x/7.x development: are we going to simply > copy the grass7 repository in its entirety and rename it something like > grass7? Or are we going to subtly modify the files and then reimport them > into grass7. I'm not quite sure what's the plan and this certainly needs > to be ironed out. There was some discussion on it recently: See last paragraphs of: http://grass.itc.it/pipermail/grass-dev/2007-August/032599.html http://grass.itc.it/pipermail/grass-dev/2007-August/032612.html > As to the other benefits of the OSGeo infrastructure (apart from > community/social integration with the other projects), if the bug tracker > / repository integration works out well then that would be a nice added > bonus. I have to say the way you couldn't Cc e-mail discussions into the > Gforge bug tracker like you could with the old RT one was a big downside > to using it more for me - I wonder does Trac have that capability? No idea. But GForge has some more limitations (see Wiki page and GForge reports itself) - we observe that the old RT was way more used by developers than GForge. There must be reasons for that. Markus From warmerdam at pobox.com Fri Sep 14 22:08:48 2007 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Sep 14 21:55:49 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <86782b610709141201i2db71c81wf8464b2639f334f6@mail.gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <86782b610709141201i2db71c81wf8464b2639f334f6@mail.gmail.com> Message-ID: <46EAEA50.5030208@pobox.com> Paul wrote: >> (out of interest - where is the OSGeo SVN server physically located and >> who is the sysadmin for it?) Paul, The main servers are at a Peer1 colocation site, I think in Atlanta. They are adminstered by the OSGeo System Administration Committee. Primary responsibility falling on Howard Butler, Shawn Barnes, Tyler Mitchell, Martin Spott and myself. The main servers provide subversion, Trac, Mailman and the various Drupal based web sites (www.osgeo.org, mapguide.osgeo.org, etc). A bunch of additional services such as buildbot.osgeo.org, and download.osgeo.org are hosted on Telascience systems primarily administered by John Graham but with various SAC and other folks having root access as needed. These systems are in San Diego. 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 michael.barton at asu.edu Fri Sep 14 22:45:40 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Sep 14 22:46:02 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <18154.51784.321093.208790@cerise.gclements.plus.com> Message-ID: On 9/14/07 10:52 AM, "Glynn Clements" wrote: > > Hamish wrote: > >> Main window- when I hit exit I get this error over and over and have to >> use xkill to get rid of it (taking down gis.m too): >> >> ERROR: ** invalid input ** >> ERROR: ** invalid input ** >> while executing >> "exec g.region nsres=$oldres1 ewres=$oldres2" >> (procedure "GmAnim::cmd_exit" line 19) >> invoked from within >> "GmAnim::cmd_exit" >> (command bound to event) > > It should be using $WIND_OVERRIDE or $GRASS_REGION, *not* modifying > the WIND file. Yes, you're probably right even though this involves computational regions rather than display regions. I've already thought of this, but wanted to get the whole concept working before I tackled the tricky problem of trying to code one of these approaches (tricky because of different formats between latlon and non-latlon regions). Do you have a recommendation for which would be better in this case? I assume that in either case, I'll have to replicate the entire region information even though I only need to temporarily change the resolution while r.out.ppm is running. 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 brush at tryonfarm.org Sat Sep 15 03:39:13 2007 From: brush at tryonfarm.org (brush) Date: Sat Sep 15 03:39:56 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. Message-ID: <20070915013913.GC7455@refresco.dreamhost.com> dear allies, i'm a relative newcomer to GRASS, so i appreciate your indulgence of any mistakes i make. i've searched the web pretty extensively, and come to the conclusion (though it's a bit opaque), based on documents dating from between 2003 and 2005, that this is the status of importing DWG data into GRASS: 1. v.in.dwg is the only module available 2. it can only be used by compiling from source 3. one has to use the old OpenDWG Toolkit, rather than the actively maintained DWGDirect, either of which require becoming an associate member of OpenDesign Alliance by faxing a contract (no $$) 4. the approach is to unarchive the Toolkit into a folder, and then to run ./configure like so: ./configure \ ... \ --with-opendwg \ --with-opendwg-includes=/home/usr1/opendwg27 \ --with-opendwg-libs=/home/usr1/opendwg27 5. and then to compile GRASS from scratch is this correct? will this process work with 6.2.2? is there any movement on using DWGDirect, which is the only way to be compatible with more recent versions of AutoCAD? thanks so much! .brush From glynn at gclements.plus.com Sat Sep 15 04:19:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 15 04:19:14 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: <18154.51784.321093.208790@cerise.gclements.plus.com> Message-ID: <18155.16668.512318.680827@cerise.gclements.plus.com> Michael Barton wrote: > >> Main window- when I hit exit I get this error over and over and have to > >> use xkill to get rid of it (taking down gis.m too): > >> > >> ERROR: ** invalid input ** > >> ERROR: ** invalid input ** > >> while executing > >> "exec g.region nsres=$oldres1 ewres=$oldres2" > >> (procedure "GmAnim::cmd_exit" line 19) > >> invoked from within > >> "GmAnim::cmd_exit" > >> (command bound to event) > > > > It should be using $WIND_OVERRIDE or $GRASS_REGION, *not* modifying > > the WIND file. > > Yes, you're probably right even though this involves computational regions > rather than display regions. I've already thought of this, but wanted to get > the whole concept working before I tackled the tricky problem of trying to > code one of these approaches (tricky because of different formats between > latlon and non-latlon regions). > > Do you have a recommendation for which would be better in this case? I > assume that in either case, I'll have to replicate the entire region > information even though I only need to temporarily change the resolution > while r.out.ppm is running. $WIND_OVERRIDE is easier, because you can still use g.region to set the resolution. g.region save=$tmpregion set env(WIND_OVERRIDE) $tmpregion g.region nsres=... ewres=... # r.out.ppm commands go here unset env(WIND_OVERRIDE) g.remove region=$tmpregion $GRASS_REGION is more robust, as you don't have to create a unique name for the temporary region, and there's no risk of the temporary region being left behind if the program terminates prematurely. -- Glynn Clements From glynn at gclements.plus.com Sat Sep 15 04:37:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 15 04:37:29 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <20070915013913.GC7455@refresco.dreamhost.com> References: <20070915013913.GC7455@refresco.dreamhost.com> Message-ID: <18155.17766.813674.885403@cerise.gclements.plus.com> brush wrote: > i'm a relative newcomer to GRASS, so i appreciate your indulgence of any > mistakes i make. i've searched the web pretty extensively, and come to > the conclusion (though it's a bit opaque), based on documents dating > from between 2003 and 2005, that this is the status of importing DWG > data into GRASS: > > 1. v.in.dwg is the only module available Correct. > 2. it can only be used by compiling from source Correct. The licences for GRASS and the OpenDWG library are incompatible, so it's impossible to distribute a binary which satisfies both licences. > 3. one has to use the old OpenDWG Toolkit, rather than the actively > maintained DWGDirect, either of which require becoming an associate > member of OpenDesign Alliance by faxing a contract (no $$) AFAICT, yes. > 4. the approach is to unarchive the Toolkit into a folder, and then to > run ./configure like so: > > ./configure \ > ... \ > --with-opendwg \ > --with-opendwg-includes=/home/usr1/opendwg27 \ > --with-opendwg-libs=/home/usr1/opendwg27 You need to build the OpenDWG library first. > 5. and then to compile GRASS from scratch If you already have a precompiled version of GRASS 6.3, you can probably build just v.in.dwg with e.g.: make -C vector/v.in.dwg MODULE_TOPDIR=/usr/local/grass-6.3.cvs 6.2.2 doesn't include the Makefile fragments (include/Make/*.make), so you can't easily build individual modules outside of the source tree. > is this correct? will this process work with 6.2.2? is there any > movement on using DWGDirect, which is the only way to be compatible with > more recent versions of AutoCAD? Someone who has the DWGDirect library will need to provide the code. I'm not sure whether any of the active developers have either of the DWG libraries (the original author of v.in.dwg, Radim Blazek, is no longer an active developer). The licensing conditions for the various DWG libraries (and the fact that AutoDesk goes to significant lengths to inhibit compatibility) tend to suppress interest. -- Glynn Clements From hamish_nospam at yahoo.com Sat Sep 15 06:55:22 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Sep 15 06:55:32 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: <597841.99111.qm@web52708.mail.re2.yahoo.com> Message-ID: <20070915165522.eb81701d.hamish_nospam@yahoo.com> Michael Barton wrote: > > Without apply, you hit OK and the map selection window closes. Then you > have to reopen it and enter from scratch when you want to change > something. I could rename apply to OK and have a close button. However, > the OK button is like a combination of OK and close, and is a default > that is activated when you hit the return key, which is also handy > sometimes. but what if you make it so when you reopen the map selection window the old choices are still there? (within the same session) Then you don't start from scratch. Highlighting and deleting a long list of map names is easy enough. [minor issue, I assume this is a tcl limitation] I notice I can use ctrl-click to pick a number of maps at once, but only left-click to reset and start from scratch. ie no way to unselect a map without full reset. and shift-click to flood- select a bunch of maps doesn't work. Expand "Names" button to "Show names" or "Display map names" or something? At present it's a bit unclear what that button is supposed to do, and there is lots of real-estate available in the toolbar for a longer button name. Hamish From hamish_nospam at yahoo.com Sat Sep 15 07:41:39 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Sep 15 07:41:53 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: Message-ID: <20070915174139.ecbc1452.hamish_nospam@yahoo.com> Michael Barton wrote: > >>> The parsing in the new TclTk module is still simpler. It will > >>> correctly recognize rast[1-100]. > >> > >> That's an odd definition of "correct". Users are likely to expect > >> [...] to follow glob/regexp semantics (match a single character from > >> the set), so "rast[1-100]" should be equivalent to "rast[01]". > > > > Command line Linux users and programmers who use glob/regexp > > semantics might well expect this. Non-programmer users, especially of > > non-Linux platforms probably will understand [1-100] as meaning from > > 1 to 100. In either case, it needs to go into the docs so that a user > > will know how to specify maps that end in 1 to 100 > > > > [1-100] or [1-9][0-9][0] > > > > The latter is harder to explain in docs than the former to someone not > > familiar with regexp--and even some of us familiar with it. Hi, just a general comment-- whenever possible we should not try to reinvent the wheel, and then expect our solution to be better than 20-30 years of UNIX gurus hashing it out. It's the old saying- "Those who don't understand UNIX are doomed to reimplement it. Poorly." Not that UNIX is perfect, but I don't expect to be able to do a better job myself. For me learning GRASS and Linux was not always intuitive, but because both reused a lot of UNIX concepts, I didn't mind spending the time on it as it became quickly apparent that the knowledge was reusable and transferable. I don't want to sink a lot of learning time into one software's way of doing things. I'd rather learn something once and then have it magically work in lots of places. (eg I had lots of "oh yeah, Matlab does that the same way..." moments) Same concept as r.mapcalc reusing C's expression precedence etc. rather than using some custom construct specific to GRASS. Or as "%03d" zero- padded output strings in Tcl/awk/C/.../.../..... Hamish From hamish_nospam at yahoo.com Sat Sep 15 07:58:09 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Sep 15 07:58:18 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <86782b610709141201i2db71c81wf8464b2639f334f6@mail.gmail.com> References: <20070914114723.GD14995@bartok.itc.it> <86782b610709141201i2db71c81wf8464b2639f334f6@mail.gmail.com> Message-ID: <20070915175809.64d961a0.hamish_nospam@yahoo.com> I think both hosts would do a fine job, so no strong opinion as to where the other end of the wire physically ends up. Very important to me though is that we get a ViewCVS 0.9.3 interface on par with what we have now. There are a number of different flavours of SCM-web interfaces around, but I've not met one as nice and usable as our ViewCVS yet. (mostly I quite like ours and find all others I've tried to be no where close) I depend on it heavily for diffs and exploring the source tree + code history. (with the support of the server admin there is no reason we can't run multiple SCM-web interfaces on the same repo if diff't folks have diff't preferences as to a particular web interface) I think it is a very good idea to keep the active web page and source code repos in the same place. How to best archive the "grass" 5 repo without losing the change history? If SCM moves away from intevation.de, we must expect that one day they will want to turn the historical CVS server off. Hamish From neteler at itc.it Sat Sep 15 08:10:34 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Sep 15 08:10:36 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <20070915175809.64d961a0.hamish_nospam@yahoo.com> References: <20070914114723.GD14995@bartok.itc.it> <86782b610709141201i2db71c81wf8464b2639f334f6@mail.gmail.com> <20070915175809.64d961a0.hamish_nospam@yahoo.com> Message-ID: <20070915061034.GA6401@bartok.itc.it> On Sat, Sep 15, 2007 at 05:58:09PM +1200, Hamish wrote: > I think both hosts would do a fine job, so no strong opinion as to > where the other end of the wire physically ends up. > > Very important to me though is that we get a ViewCVS 0.9.3 interface on > par with what we have now. There are a number of different flavours of > SCM-web interfaces around, but I've not met one as nice and usable as our > ViewCVS yet. (mostly I quite like ours and find all others I've tried to > be no where close) I depend on it heavily for diffs and exploring the > source tree + code history. That's technically possible, see Martin's Test-SVN: http://josef.fsv.cvut.cz/cgi-bin/viewcvs.cgi/?root=grass7svn > (with the support of the server admin there is no reason we can't run > multiple SCM-web interfaces on the same repo if diff't folks have diff't > preferences as to a particular web interface) > > > I think it is a very good idea to keep the active web page and source > code repos in the same place. > > How to best archive the "grass" 5 repo without losing the change history? > If SCM moves away from intevation.de, we must expect that one day they > will want to turn the historical CVS server off. Sure - but this can always happen everywhere. We could focus on GRASS 7 repo now and spend more time later to do a full conversion of grass/ (GRASS 5) with all branches which is causing some problems right now. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From michael.barton at asu.edu Sat Sep 15 17:18:18 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Sep 15 17:18:32 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <20070915165522.eb81701d.hamish_nospam@yahoo.com> Message-ID: On 9/14/07 9:55 PM, "Hamish" wrote: > Michael Barton wrote: >> >> Without apply, you hit OK and the map selection window closes. Then you >> have to reopen it and enter from scratch when you want to change >> something. I could rename apply to OK and have a close button. However, >> the OK button is like a combination of OK and close, and is a default >> that is activated when you hit the return key, which is also handy >> sometimes. > > but what if you make it so when you reopen the map selection window the > old choices are still there? (within the same session) Then you don't > start from scratch. Highlighting and deleting a long list of map names is > easy enough. This is a good idea and I think I can do this. Still, is there any problem with a button that lets you apply changes and not close the map selection window. > > [minor issue, I assume this is a tcl limitation] > I notice I can use ctrl-click to pick a number of maps at once, but only > left-click to reset and start from scratch. ie no way to unselect a map > without full reset. and shift-click to flood- select a bunch of maps > doesn't work. This is part of the mysteries of select.tcl, an ancient but useful TclTk module that is one of the few remaining pieces inherited from tcltkgrass. I found the select multiple option buried in it and turned it on, but haven't tested it extensively. So I'm not sure how it really works. > > Expand "Names" button to "Show names" or "Display map names" or something? > At present it's a bit unclear what that button is supposed to do, and > there is lots of real-estate available in the toolbar for a longer button > name. Easily done. There IS mouseover help on all buttons that explain what they do. 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 Sat Sep 15 17:42:45 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Sep 15 17:42:51 2007 Subject: [GRASS-dev] [GRASS-user] problems with v.report In-Reply-To: <46E44E97.50704@o2.pl> References: <46E3FB85.7070403@o2.pl> <12581423.post@talk.nabble.com> <46E44E97.50704@o2.pl> Message-ID: <46EBFD75.4050701@o2.pl> Maciej Sieczka wrote: >> Maciej Sieczka wrote: >>> I'd like to backport it to 6.2 if nobody minds. Done. Maciek From brush at tryonfarm.org Sat Sep 15 18:40:07 2007 From: brush at tryonfarm.org (brush) Date: Sat Sep 15 18:40:31 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <18155.17766.813674.885403@cerise.gclements.plus.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> Message-ID: <20070915164007.GA1020@refresco.dreamhost.com> thanks, glynn, for the quick response. some more comments and questions inline: On Sat, Sep 15, 2007 at 03:37:26AM +0100, Glynn Clements wrote: > > 1. v.in.dwg is the only module available > > Correct. > > > 2. it can only be used by compiling from source > > Correct. > > The licences for GRASS and the OpenDWG library are incompatible, so > it's impossible to distribute a binary which satisfies both licences. understood. the ideal scenario in this situation, of course, would be some kind of "one step" integrability in which, once a user has obtained the library source from the opendesign alliance, v.in.dwg would be compiled and integrated automatically with GRASS. > > 4. the approach is to unarchive the Toolkit into a folder, and then to > > run ./configure like so: > > > > ./configure \ > > ... \ > > --with-opendwg \ > > --with-opendwg-includes=/home/usr1/opendwg27 \ > > --with-opendwg-libs=/home/usr1/opendwg27 > > You need to build the OpenDWG library first. really? both some (original?) versions of the v.in.dwg instructions, and the opendwg toolkit manuals, seem to imply that the .h and .a libraries (really just 4 files) are already built, and just need to be linked into v.in.dwg's compilation. am i missing something? > > 5. and then to compile GRASS from scratch > > If you already have a precompiled version of GRASS 6.3, you can > probably build just v.in.dwg with e.g.: > > make -C vector/v.in.dwg MODULE_TOPDIR=/usr/local/grass-6.3.cvs > > 6.2.2 doesn't include the Makefile fragments (include/Make/*.make), so > you can't easily build individual modules outside of the source tree. ok. i actually currently only have a precompiled version of 6.2.1. so here's my questions: how stable is 6.3? is it appropriate for enduser use? the major installation hassle with GRASS seems to be getting all the dependencies worked out. so if i install a precompiled 6.2.2 on (say) xubuntu, and then recompile just GRASS with the new libraries, will that avoid most of the hassles? goodness, it would be nice to have a script to do this! > > is this correct? will this process work with 6.2.2? is there any > > movement on using DWGDirect, which is the only way to be compatible with > > more recent versions of AutoCAD? > > Someone who has the DWGDirect library will need to provide the code. > > I'm not sure whether any of the active developers have either of the > DWG libraries (the original author of v.in.dwg, Radim Blazek, is no > longer an active developer). i'd be happy to provide the library code to developer(s) to update v.in.dwg; it would be a collaborative partnership with our organization, thus within the legal constraints of the license. if this is a real possibility, whom would i contact? > The licensing conditions for the various DWG libraries (and the fact > that AutoDesk goes to significant lengths to inhibit compatibility) > tend to suppress interest. i certainly understand that. at the same time, an enormous amount of GIS-related information is stored in DWG files. are there other ways to convert such information to more easily GRASS-readable data? thanks, .b From neteler at itc.it Sat Sep 15 19:57:46 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Sep 15 19:57:48 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <20070915164007.GA1020@refresco.dreamhost.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> Message-ID: <12692350.post@talk.nabble.com> brush wrote: > > thanks, glynn, for the quick response. some more comments and questions > inline: > > On Sat, Sep 15, 2007 at 03:37:26AM +0100, Glynn Clements wrote: >> > 1. v.in.dwg is the only module available >> >> Correct. >> >> > 2. it can only be used by compiling from source >> >> Correct. >> >> The licences for GRASS and the OpenDWG library are incompatible, so >> it's impossible to distribute a binary which satisfies both licences. > > understood. the ideal scenario in this situation, of course, would be > some kind of "one step" integrability in which, once a user has obtained > the library source from the opendesign alliance, v.in.dwg would be > compiled and integrated automatically with GRASS. > >> > 4. the approach is to unarchive the Toolkit into a folder, and then to >> > run ./configure like so: >> > >> > ./configure \ >> > ... \ >> > --with-opendwg \ >> > --with-opendwg-includes=/home/usr1/opendwg27 \ >> > --with-opendwg-libs=/home/usr1/opendwg27 >> >> You need to build the OpenDWG library first. > > really? both some (original?) versions of the v.in.dwg instructions, > and the opendwg toolkit manuals, seem to imply that the .h and .a > libraries (really just 4 files) are already built, and just need to be > linked into v.in.dwg's compilation. am i missing something? > Yes: these files you have to obtain from the OpenDesign Alliance. AFAIK we could distribute binaries of v.in.dwg if there were dynamic DWGDirect libraries available, but they aren't (at least not some months ago). Since they only provide static libraries (.a instead of .so), they get compiled into GRASS and hence fall under the "no distribution" restriction. Maybe you can convince the OpenDesign Alliance to also make dynamic libraries available? Markus -- View this message in context: http://www.nabble.com/v.in.dwg%3A-status-in-GRASS-6.2.2%2C-DWGdirect%2C-etc.-tf4446146.html#a12692350 Sent from the Grass - Dev mailing list archive at Nabble.com. From glynn at gclements.plus.com Sat Sep 15 21:51:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 15 21:52:04 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: References: <20070915165522.eb81701d.hamish_nospam@yahoo.com> Message-ID: <18156.14301.551128.943833@cerise.gclements.plus.com> Michael Barton wrote: > > [minor issue, I assume this is a tcl limitation] > > I notice I can use ctrl-click to pick a number of maps at once, but only > > left-click to reset and start from scratch. ie no way to unselect a map > > without full reset. and shift-click to flood- select a bunch of maps > > doesn't work. > > This is part of the mysteries of select.tcl, an ancient but useful TclTk > module that is one of the few remaining pieces inherited from tcltkgrass. I > found the select multiple option buried in it and turned it on, but haven't > tested it extensively. So I'm not sure how it really works. The list is based on a BWidget Tree control. The "selection" command supports the operations: set, add, remove, clear, get. select.tcl effectively maps to "set" and to "add". Changing the behaviour to toggle shouldn't be particularly hard to implement, e.g. (untested): if {[lsearch -exact [$tree selection get] $node] >= 0} { $tree selection remove $node } else { $tree selection add $node } Supporting "extension" (typical Shift-click behaviour) would be more work, requiring keeping track of the most recent selection and manually enumerating the nodes in between. -- Glynn Clements From glynn at gclements.plus.com Sat Sep 15 22:10:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 15 22:10:30 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <20070915164007.GA1020@refresco.dreamhost.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> Message-ID: <18156.15411.228921.585488@cerise.gclements.plus.com> brush wrote: > > > 4. the approach is to unarchive the Toolkit into a folder, and then to > > > run ./configure like so: > > > > > > ./configure \ > > > ... \ > > > --with-opendwg \ > > > --with-opendwg-includes=/home/usr1/opendwg27 \ > > > --with-opendwg-libs=/home/usr1/opendwg27 > > > > You need to build the OpenDWG library first. > > really? both some (original?) versions of the v.in.dwg instructions, > and the opendwg toolkit manuals, seem to imply that the .h and .a > libraries (really just 4 files) are already built, and just need to be > linked into v.in.dwg's compilation. am i missing something? Ah; my mistake. I had assumed that they were providing source. > > > 5. and then to compile GRASS from scratch > > > > If you already have a precompiled version of GRASS 6.3, you can > > probably build just v.in.dwg with e.g.: > > > > make -C vector/v.in.dwg MODULE_TOPDIR=/usr/local/grass-6.3.cvs > > > > 6.2.2 doesn't include the Makefile fragments (include/Make/*.make), so > > you can't easily build individual modules outside of the source tree. > > ok. i actually currently only have a precompiled version of 6.2.1. so > here's my questions: > > how stable is 6.3? is it appropriate for enduser use? For a single user, 6.3 is probably preferable to 6.2. The occasional user-visible change is probably outweighed by additional functionality. The main reason to stick with 6.2 is if you are investing significant time and effort in creating scripts (or course material), where any incompatible change would be a major inconvenience. > the major installation hassle with GRASS seems to be getting all the > dependencies worked out. so if i install a precompiled 6.2.2 on (say) > xubuntu, and then recompile just GRASS with the new libraries, will that > avoid most of the hassles? When compiling from source, one thing to bear in mind is that you also need the development packages (with the headers and .so symlinks) for each dependency. > goodness, it would be nice to have a script to do this! Installing dependencies is highly platform-specific. Once you have all of the dependencies, "configure ; make ; make install" will often suffice if you don't need some of the less common features. -- Glynn Clements From glynn at gclements.plus.com Sat Sep 15 22:20:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Sep 15 22:20:31 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <12692350.post@talk.nabble.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> <12692350.post@talk.nabble.com> Message-ID: <18156.16013.439301.132777@cerise.gclements.plus.com> Markus Neteler wrote: > Yes: these files you have to obtain from the OpenDesign Alliance. > AFAIK we could distribute binaries of v.in.dwg if there were dynamic > DWGDirect libraries available, but they aren't (at least not some months > ago). Since they only provide static libraries (.a instead of .so), they get > compiled into GRASS and hence fall under the "no distribution" restriction. It doesn't make any difference whether the libraries are static or dynamic. Unless you can supply the OpenDWG/DWGDirect source code under a GPL-compatible licence, you cannot distribute a binary which is linked (statically or dynamically) against both the GRASS libraries and the DWG libraries. -- Glynn Clements From brush at tryonfarm.org Sat Sep 15 22:31:53 2007 From: brush at tryonfarm.org (brush) Date: Sat Sep 15 22:32:09 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <18156.16013.439301.132777@cerise.gclements.plus.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> <12692350.post@talk.nabble.com> <18156.16013.439301.132777@cerise.gclements.plus.com> Message-ID: <20070915203153.GB16540@refresco.dreamhost.com> On Sat, Sep 15, 2007 at 09:20:29PM +0100, Glynn Clements wrote: > > Markus Neteler wrote: > > > Yes: these files you have to obtain from the OpenDesign Alliance. > > AFAIK we could distribute binaries of v.in.dwg if there were dynamic > > DWGDirect libraries available, but they aren't (at least not some months > > ago). Since they only provide static libraries (.a instead of .so), they get > > compiled into GRASS and hence fall under the "no distribution" restriction. > > It doesn't make any difference whether the libraries are static or > dynamic. > > Unless you can supply the OpenDWG/DWGDirect source code under a > GPL-compatible licence, you cannot distribute a binary which is linked > (statically or dynamically) against both the GRASS libraries and the > DWG libraries. would it be possible to create a standalone binary that converts from DWG into GRASS-internal data structures, which could be accessed if it exists from inside GRASS? then this binary could have a licensing structure separate from GPL. this would make it a lot easier to separately maintain and compile that code in a one-click fashion, reducing the barrier to use. does this make sense? .b From brush at tryonfarm.org Sat Sep 15 22:35:33 2007 From: brush at tryonfarm.org (brush) Date: Sat Sep 15 22:35:50 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <18156.15411.228921.585488@cerise.gclements.plus.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> <18156.15411.228921.585488@cerise.gclements.plus.com> Message-ID: <20070915203533.GC16540@refresco.dreamhost.com> question at end... On Sat, Sep 15, 2007 at 09:10:27PM +0100, Glynn Clements wrote: > > > If you already have a precompiled version of GRASS 6.3, you can > > > probably build just v.in.dwg with e.g.: > > > > > > make -C vector/v.in.dwg MODULE_TOPDIR=/usr/local/grass-6.3.cvs > > > > > > 6.2.2 doesn't include the Makefile fragments (include/Make/*.make), so > > > you can't easily build individual modules outside of the source tree. > > > > ok. i actually currently only have a precompiled version of 6.2.1. so > > here's my questions: > > > > how stable is 6.3? is it appropriate for enduser use? > > For a single user, 6.3 is probably preferable to 6.2. The occasional > user-visible change is probably outweighed by additional > functionality. > > The main reason to stick with 6.2 is if you are investing significant > time and effort in creating scripts (or course material), where any > incompatible change would be a major inconvenience. > > > the major installation hassle with GRASS seems to be getting all the > > dependencies worked out. so if i install a precompiled 6.2.2 on (say) > > xubuntu, and then recompile just GRASS with the new libraries, will that > > avoid most of the hassles? > > When compiling from source, one thing to bear in mind is that you also > need the development packages (with the headers and .so symlinks) for > each dependency. > > > goodness, it would be nice to have a script to do this! > > Installing dependencies is highly platform-specific. Once you have all > of the dependencies, "configure ; make ; make install" will often > suffice if you don't need some of the less common features. ok: then it seems to me i should install a precompiled version of 6.3, and then build v.in.dwg alone using the Makefile fragments. is that correct? this will avoid having to have development pkgs for dependencies... if i get this working, i'll try and write up instructions; where could they be posted? thanks, .b From neteler at itc.it Sat Sep 15 23:16:36 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Sep 15 23:16:39 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <18156.16013.439301.132777@cerise.gclements.plus.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> <12692350.post@talk.nabble.com> <18156.16013.439301.132777@cerise.gclements.plus.com> Message-ID: <12693948.post@talk.nabble.com> Glynn Clements wrote: > > It doesn't make any difference whether the libraries are static or > dynamic. > > Unless you can supply the OpenDWG/DWGDirect source code under a > GPL-compatible licence, you cannot distribute a binary which is linked > (statically or dynamically) against both the GRASS libraries and the > DWG libraries. > > -- > Glynn Clements > Right. Maybe it is worth to look at how gvSIG solves this http://www.gvsig.gva.es/index.php?id=faq-preguntas-tec&K=1&L=2 ? Take out their lib/driver and use that also for us? Seems to be here http://sourceforge.net/project/showfiles.php?group_id=151469 Their CVS: http://gdbms-plugins.cvs.sourceforge.net/gdbms-plugins/gdbms%20drivers/src/main/java/com/hardcode/gdbms/driver/dwg/ but the real code seems to be elsewhere. Markus -- View this message in context: http://www.nabble.com/v.in.dwg%3A-status-in-GRASS-6.2.2%2C-DWGdirect%2C-etc.-tf4446146.html#a12693948 Sent from the Grass - Dev mailing list archive at Nabble.com. From hmitaso at unity.ncsu.edu Sun Sep 16 05:33:32 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sun Sep 16 05:33:38 2007 Subject: [GRASS-dev] GRASS 7 Migration from CVS to SVN In-Reply-To: <20070914114723.GD14995@bartok.itc.it> References: <20070914114723.GD14995@bartok.itc.it> Message-ID: <332C716A-CA67-41B4-8625-48517170AA5F@unity.ncsu.edu> 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 From michael.barton at asu.edu Sun Sep 16 05:53:42 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 16 05:53:49 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <20070914114723.GD14995@bartok.itc.it> Message-ID: Markus and PCS, I don't have real strong feelings either way. But I've been following the various comments and I'm swayed by social values of better integration with OSGEO (though it would be a better argument if GRASS could get through the incubation). It would make OSGEO a stronger organization and give GRASS potentially better links with other developer communities if it was hosted as an OSGEO SVN project. I've been very pleased using the existing SVN while developing the wxPython GUI. I don't use Gforge much, but do use it some. It seems OK to the extent that I've used it, except for email issues. The current web interface of the SVN seems rather limited compared with our current CVS web interface. With the CVS, Intevation and Bernard have been great, very responsive, and very helpful. They have a long history with GRASS as GPL. OSGEO is a great organization and I'd like to see it grow. It is very new and so without much of a track record. But they seem to be doing things right. I haven't used Trac, but it sounds very nice. I took a quick look at the links for OSGEO Trac and GDAL Trac and it looked very promising. So my slight inclination is for OSGEO, but I'm also happy to stay with Intevation. Has anyone asked Bernard for input from Intevation's side? Michael On 9/14/07 4: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-psc mailing list > grass-psc@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-psc __________________________________________ 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 Sun Sep 16 09:27:27 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 16 09:27:34 2007 Subject: [GRASS-dev] updates to TclTk animator Message-ID: I just committed a number of updates to the TclTk animation module. Maps can now be specified as a numbered series using the format rast(1-n) OR can be specified using glob/regexp patterns like rast* or rast[1-9][0-9]. You can mix different formats in the same view as well as in different views. When an entry is selected by browsing a list of maps, it does not have a preceding comma if it is the first map entered. If you close the map selection window and reopen it, it will still show any maps previously selected. WIND_OVERRIDE is used for changing region resolution so that the computational region is not affected. Some cosmetic fixes. Thanks for the input and suggestions from Hamish and Glynn. 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/20070916/4a1e6631/attachment.html From michael.barton at asu.edu Sun Sep 16 09:29:39 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Sep 16 09:29:44 2007 Subject: [GRASS-dev] TclTk animator finished - replaces xganim In-Reply-To: <20070914160403.8c43fd33.hamish_nospam@yahoo.com> Message-ID: On 9/13/07 9:04 PM, "Hamish" wrote: Hamish, I still don't understand you got the error listed below. I checked and it looks like I'd already made sure that the resolution setting is float and not integer. I changed one other line. Maybe it makes a difference. I hope so but am skeptical. Michael > > - when I hit Ok I get this error: > > ERROR: ** invalid input ** > ERROR: ** invalid input ** > while executing > "exec g.region res=$pnmres" > (procedure "GmAnim::switch_res" line 29) > invoked from within > "GmAnim::switch_res 1" > (procedure "GmAnim::load_files" line 47) > invoked from within > "GmAnim::load_files" > (procedure "GmAnim::do_run" line 29) > invoked from within > "GmAnim::do_run" > (procedure "GmAnim::parse_viewmaps" line 68) > invoked from within > "GmAnim::parse_viewmaps $viewlist" > (procedure "GmAnim::create_viewlist" line 33) > invoked from within > "GmAnim::create_viewlist 1" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 18) > invoked from within > "Button::_release .animmaps_win.buttons.a" > (command bound to event) > __________________________________________ 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 Sun Sep 16 14:49:02 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Sep 16 14:49:09 2007 Subject: [GRASS-dev] frequent segfaults of tcl/tk windows on a 64bit box Message-ID: <46ED263E.4060005@o2.pl> Hi Does anyone experience frequent segfaults of the autogenerated tcl/tk windows on 64bit GNU/Linux machines like me? On several 32bit machines it never happens, but on the 64bit one it happens very often, both in GRASS 6.3 and 6.2, built and running against tcl/tk 8.4.12 on Ubuntu Dapper. It's been so for few months now. No matter what command. The crash has random nature. Sometimes the same command works few times in a row, sometimes it crashes right after I press the "Run" button. For example, the following command run from tcl/tk GUI inside gdb: v.overlay ainput="lulc_obszar_mestichblatt@lulc_dhdn" atype="area" alayer=1 binput="lulc_obszar_utm25k@lulc_utm25k" btype="area" blayer=1 output="union" operator="and" olayer=1,0,0 crashed like this: $ gdb v.overlay (gdb) run Starting program: /usr/local/grass-6.3.cvs/bin/v.overlay [Thread debugging using libthread_db enabled] [New Thread 46912562427840 (LWP 18035)] warning: Lowest section in /usr/lib/libicudata.so.34 is .hash at 00000000000000e8 Program exited with code 01. (gdb) bt No stack. Core was dumped, so I run: $ gdb -c core.16726 This GDB was configured as "x86_64-linux-gnu". Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `wish'. Program terminated with signal 11, Segmentation fault. #0 0x00002aaaaac11768 in ?? () (gdb) bt #0 0x00002aaaaac11768 in ?? () (gdb) Not much information here I guess. The output vector is broken: $ v.info union ERROR: Cannot open existing vector on level [2] $ v.build union WARNING: coor files of vector 'union@oir' is larger than it should be (36730 bytes excess). Building topology ... 0 primitives registered 0 areas built 0 isles built Attaching islands: Attaching centroids: Topology was built. Number of nodes : 0 Number of primitives: 0 Number of points : 0 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 So it's empty. There should be one area instead. Moreover, the v.build run takes surprisingly long I guess - about 5 seconds, on an Intel Core Duo E6600 2,4 GHz running 2.6.15-29-amd64-xeon. Does anybody know how to solve the problem? Is it a matter of tlc/tk or GRASS? Maciek From mlennert at club.worldonline.be Sun Sep 16 17:26:55 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sun Sep 16 17:28:14 2007 Subject: [GRASS-dev] native WinGRASS and attribute data deadlock, next try In-Reply-To: <2903.128.40.195.179.1188985093.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> Message-ID: <1601.85.10.69.36.1189956415.squirrel@geog-pc40.ulb.ac.be> Hello, I have tried to get some more debug output for the wingrass db deadlock problem. I started from Benjamin's work, and tried to apply Glynn's suggestions. I have to admit, though, that I still do not completely understand xdr, so I'm not sure if what I did makes sense. In order to not have different debug outputs mingle, I had to create 8 log files, one for each function and for each stream. See xdr_logs.zip. I also attached the original xdr_stdio.c and a diff with everything I added. When I now run our test v.out.ogr line: GRASS 6.3.cvs (qgis-test):C:\GRASSSRC\grass6\bin.i686-pc-mingw32 >v.out.ogr points type=point dsn=c:\test I get the message: Exporting 2898 points/lines... And then nothing else. The percentage counter never appears. Please tell me if these logs are in any way helpful and, if not, what I could do to improve them. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: xdr_logs.zip Type: application/zip Size: 12451 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070916/3d9405d7/xdr_logs-0001.zip -------------- next part -------------- A non-text attachment was scrubbed... Name: xdr_stdio.zip Type: application/zip Size: 3625 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070916/3d9405d7/xdr_stdio-0001.zip From hamish_nospam at yahoo.com Mon Sep 17 03:17:38 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Sep 17 03:17:49 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <20070915164007.GA1020@refresco.dreamhost.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> Message-ID: <20070917131738.41ed097a.hamish_nospam@yahoo.com> brush: > > > 2. it can only be used by compiling from source Glynn: > > Correct. > > > > The licences for GRASS and the OpenDWG library are incompatible, so > > it's impossible to distribute a binary which satisfies both licences. > > understood. the ideal scenario in this situation, of course, would be > some kind of "one step" integrability in which, once a user has obtained > the library source from the opendesign alliance, v.in.dwg would be > compiled and integrated automatically with GRASS. This is a job for the GRASS Extensions Manager (GEM), see gem/README in the GRASS 6.2.2 or 6.3 source code, and one of the reasons it was written. Note that some developers may not be terribly interested in devoting their own volunteer development time into coding a "tivo" solution that makes it easy to sidestep the spirit of the GPL. The more that happens, the less chance of a true "Open" DWG library ever gets written for OGR/GDAL. This is not anti-user elitism, it is supporting long term user interests over short term band-aids. > i'd be happy to provide the library code to developer(s) to update > v.in.dwg; it would be a collaborative partnership with our organization, > thus within the legal constraints of the license. if this is a real > possibility, whom would i contact? Contact this mailing list (grass-dev). Patches can go into the GRASS patch tracker, and are most welcome. It helps if you can convince a member of the development team to become interested in it. (presumably someone with a need for it) Patch tracker: http://wald.intevation.org/tracker/?group_id=21 Glynn: > > The licensing conditions for the various DWG libraries (and the fact > > that AutoDesk goes to significant lengths to inhibit compatibility) > > tend to suppress interest. brush: > i certainly understand that. at the same time, an enormous amount of > GIS-related information is stored in DWG files. are there other ways to > convert such information to more easily GRASS-readable data? v.in.dxf seems to work pretty well for DXF, if you can save it in that format. I don't know how it deals with the latest versions of DXF, but have heard no complaints. brush: > if i get this working, i'll try and write up instructions; where could > they be posted? On the wiki site: http://grass.gdf-hannover.de/wiki/Main_Page good luck, Hamish From neteler at itc.it Mon Sep 17 10:26:08 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Sep 17 10:26:10 2007 Subject: [GRASS-dev] frequent segfaults of tcl/tk windows on a 64bit box In-Reply-To: <46ED263E.4060005@o2.pl> References: <46ED263E.4060005@o2.pl> Message-ID: <46EE3A20.5060102@itc.it> Maciej Sieczka wrote on 09/16/2007 02:49 PM: > Hi > > Does anyone experience frequent segfaults of the autogenerated tcl/tk > windows on 64bit GNU/Linux machines like me? > Hi Maciej, I am working on two different 64bit GNU/Linux machines (RHEL4 and Mandriva 2007.1) and never had such problems. I just tried v.overlay and it finished with "complete". The file doc/debugging.txt contains some hints for TclTk debugging. ... > Does anybody know how to solve the problem? Is it a matter of tlc/tk or > GRASS? > Or your system installation? Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From jachym.cepicky at gmail.com Mon Sep 17 12:39:37 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Mon Sep 17 12:39:44 2007 Subject: [GRASS-dev] status of g-ps.map Message-ID: <1190025577.16457.28.camel@mellon> Hi, some people were asking, if I could make old G-PS.map (GUI to ps.map) available. It is still available on the server (just hidden), the most "fresh" source code can be downloaded and used from [1], feel free to continue in it's development. However, g-ps.map was only proof-of-the-concept. I was experimenting with various programming languages (python) and graphical toolkits (tk,gtk,wxwidgets) to find out, which one would be suitable for GRASS. G-ps.map was written in python, using PyGTK bindings. Currently wxGRASS is written using WxWidgets. You should take g-ps.map code only for inspiration (or better not, I had no clue about GUI programming that time), do not expect too much from it. The best, what you, who wants to continue in the development, can do is to help with wxGRASS development and to add this GUI for map creation. BTW, what surprises me most is, that it is still working [2]. Jachym [1] http://les-ejk.cz/files/programs/grass/gpsmap-0.1.2.tgz [2] http://les-ejk.cz/tmp/gpsmap.png -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070917/e5d2edc4/attachment.bin From glynn at gclements.plus.com Mon Sep 17 22:05:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 17 22:05:55 2007 Subject: [GRASS-dev] Re: [GRASS-user] frequent segfaults of tcl/tk windows on a 64bit box In-Reply-To: <46ED263E.4060005@o2.pl> References: <46ED263E.4060005@o2.pl> Message-ID: <18158.56864.157538.907262@cerise.gclements.plus.com> Maciej Sieczka wrote: > Does anyone experience frequent segfaults of the autogenerated tcl/tk > windows on 64bit GNU/Linux machines like me? > Core was dumped, so I run: > > $ gdb -c core.16726 > This GDB was configured as "x86_64-linux-gnu". > Using host libthread_db library "/lib/libthread_db.so.1". > Core was generated by `wish'. > Program terminated with signal 11, Segmentation fault. > Does anybody know how to solve the problem? Is it a matter of tlc/tk or > GRASS? It's "wish" that's crashing, which suggests a problem with your Tcl/Tk installation. Nothing that GRASS does should be able to make wish segfault. -- Glynn Clements From glynn at gclements.plus.com Mon Sep 17 22:23:23 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 17 22:23:28 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <20070915203153.GB16540@refresco.dreamhost.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> <12692350.post@talk.nabble.com> <18156.16013.439301.132777@cerise.gclements.plus.com> <20070915203153.GB16540@refresco.dreamhost.com> Message-ID: <18158.57915.113978.492220@cerise.gclements.plus.com> brush wrote: > > > Yes: these files you have to obtain from the OpenDesign Alliance. > > > AFAIK we could distribute binaries of v.in.dwg if there were dynamic > > > DWGDirect libraries available, but they aren't (at least not some months > > > ago). Since they only provide static libraries (.a instead of .so), they get > > > compiled into GRASS and hence fall under the "no distribution" restriction. > > > > It doesn't make any difference whether the libraries are static or > > dynamic. > > > > Unless you can supply the OpenDWG/DWGDirect source code under a > > GPL-compatible licence, you cannot distribute a binary which is linked > > (statically or dynamically) against both the GRASS libraries and the > > DWG libraries. > > would it be possible to create a standalone binary that converts from > DWG into GRASS-internal data structures, Not without re-writing a large portion of the vector library yourself. And re-writing it if the GRASS vector format ever changes. > which could be accessed if it > exists from inside GRASS? then this binary could have a licensing > structure separate from GPL. > > this would make it a lot easier to separately maintain and compile that > code in a one-click fashion, reducing the barrier to use. A simpler solution would be to write something which converts DWG to a published format, preferably one which GDAL/OGR can import. -- Glynn Clements From glynn at gclements.plus.com Mon Sep 17 22:30:24 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Sep 17 22:30:26 2007 Subject: [GRASS-dev] v.in.dwg: status in GRASS 6.2.2, DWGdirect, etc. In-Reply-To: <20070915203533.GC16540@refresco.dreamhost.com> References: <20070915013913.GC7455@refresco.dreamhost.com> <18155.17766.813674.885403@cerise.gclements.plus.com> <20070915164007.GA1020@refresco.dreamhost.com> <18156.15411.228921.585488@cerise.gclements.plus.com> <20070915203533.GC16540@refresco.dreamhost.com> Message-ID: <18158.58336.327662.959634@cerise.gclements.plus.com> brush wrote: > > When compiling from source, one thing to bear in mind is that you also > > need the development packages (with the headers and .so symlinks) for > > each dependency. > > > > > goodness, it would be nice to have a script to do this! > > > > Installing dependencies is highly platform-specific. Once you have all > > of the dependencies, "configure ; make ; make install" will often > > suffice if you don't need some of the less common features. > > ok: then it seems to me i should install a precompiled version of 6.3, > and then build v.in.dwg alone using the Makefile fragments. is that > correct? this will avoid having to have development pkgs for > dependencies... You may still need development packages for some of the dependencies; PROJ and GDAL/OGR are the most likely candidates. -- Glynn Clements From hamish_nospam at yahoo.com Tue Sep 18 05:41:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Sep 18 05:41:37 2007 Subject: [GRASS-dev] Re: [GRASS-PSC] GRASS 7 Migration from CVS to SVN In-Reply-To: <20070915061034.GA6401@bartok.itc.it> References: <20070914114723.GD14995@bartok.itc.it> <86782b610709141201i2db71c81wf8464b2639f334f6@mail.gmail.com> <20070915175809.64d961a0.hamish_nospam@yahoo.com> <20070915061034.GA6401@bartok.itc.it> Message-ID: <20070918154116.d97920e6.hamish_nospam@yahoo.com> Markus Neteler wrote: > Hamish wrote: > > Very important to me though is that we get a ViewCVS 0.9.3 interface > > on par with what we have now. There are a number of different > > flavours of SCM-web interfaces around, but I've not met one as nice > > and usable as our ViewCVS yet. (mostly I quite like ours and find all > > others I've tried to be no where close) I depend on it heavily for > > diffs and exploring the source tree + code history. > > That's technically possible, see Martin's Test-SVN: > http://josef.fsv.cvut.cz/cgi-bin/viewcvs.cgi/?root=grass7svn Very nice. Only minor loss is that you can't instantly see the number of revisions an individual file has had. e.g. http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gis/?sortby=rev shows that parser.c is the most edited at rev 1.130. (it should be split into several files) But as the versioning is a SVN thing, I don't think we can help that, so just a comment. H: > > How to best archive the "grass" 5 repo without losing the change > > history? If SCM moves away from intevation.de, we must expect that > > one day they will want to turn the historical CVS server off. M: > Sure - but this can always happen everywhere. > We could focus on GRASS 7 repo now and spend more time later to do > a full conversion of grass/ (GRASS 5) with all branches which is > causing some problems right now. I wasn't thinking of migrating the old CVSs to a new live SVN repo, just archiving them somewhere so if someone wants it they can set it up. Hamish From michael.barton at asu.edu Tue Sep 18 07:45:21 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 18 07:48:38 2007 Subject: [GRASS-dev] Multi-selection fixed Message-ID: I managed to fix the multiple selection function of the select.tcl module and also got it to toggle the selection on/off in multiselection mode using Ctrl-click. It was more complicated that it appeared, especially because it turned out that multi-selection had been broken with other code changes some time in the past. Thanks to Glynn for getting me started with the toggle code. The result is that now you can select multiple maps, where appropriate, by ctrl-clicking on the list of maps in the selection window. 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/20070917/cdd7988b/attachment.html From wolf+grass at bergenheim.net Tue Sep 18 08:39:37 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Sep 18 08:40:12 2007 Subject: [GRASS-dev] Fontcap Message-ID: <46EF72A9.9030106@bergenheim.net> Good morning people. I just committed a change to the v.label.sa module which adds support for using fonts in the fontcap. I would have wanted to use standard GRASS functions for parsing the fontcap, but since it is placed in the display driver library it means to do that I'd require an open monitor. This seems a bit silly to me. I mean other things might want to use the fontcap without needing the overhead of a display. I wonder would it be possible to move the fontcap stuff to gislib? --Wolf PS. Next up will be support for colors in v.label.sa. ;) -- <:3 )---- Wolf Bergenheim ----( 8:> From michael.barton at asu.edu Tue Sep 18 08:56:02 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 18 08:56:07 2007 Subject: [GRASS-dev] g.mlist problem Message-ID: I just updated from the cvs and compiled. I tried the new fast g.mlist and got very weird results. Running g.mlist rast returned mapnames like... elevation.10mnrstrct.areasn ... instead of elevation.10m Anyone have an idea what's going on? I'm on a MacBook Pro OS X. 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/20070917/577ac9bc/attachment-0001.html From wolf+grass at bergenheim.net Tue Sep 18 09:01:21 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Sep 18 09:02:11 2007 Subject: [GRASS-dev] g.mlist problem In-Reply-To: References: Message-ID: <46EF77C1.8080601@bergenheim.net> On 18.09.2007 09:56, Michael Barton wrote: > I tried the new fast g.mlist and got very weird results. Running g.mlist > rast returned mapnames like... > > elevation.10mnrstrct.areasn > > ... instead of > > elevation.10m > It seems there is a missing \ before the n somewhere in the code, since \ + n => \n = new line. Or then your compiler doesn't handle "\n" properly. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From michael.barton at asu.edu Tue Sep 18 09:06:25 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 18 09:06:31 2007 Subject: [GRASS-dev] g.mlist problem - followup In-Reply-To: Message-ID: There is a cascade from the g.mlist problem reported below. With g.mlist broken, the new TcTk animation module AND the selection control for wxPython GRASS GUI are also broken. Both are using g.mlist until g.list can be updated to optionally provide a flat list of GIS elements. It looks like g.mlist is returning parts of g.list's multicolumn format, separated by "n" instead of "\n" (new line). Michael On 9/17/07 11:56 PM, "Michael Barton" wrote: > I just updated from the cvs and compiled. > > I tried the new fast g.mlist and got very weird results. Running g.mlist rast > returned mapnames like... > > elevation.10mnrstrct.areasn > > ... instead of > > elevation.10m > > > Anyone have an idea what's going on? > > I'm on a MacBook Pro OS X. > > 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 > > __________________________________________ 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/20070918/9460837f/attachment.html From michael.barton at asu.edu Tue Sep 18 09:07:34 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 18 09:07:45 2007 Subject: [GRASS-dev] g.mlist problem In-Reply-To: <46EF77C1.8080601@bergenheim.net> Message-ID: I've compiled GRASS numerous times without issue (including g.mlist), so I don't understand what is going on here. Michael On 9/18/07 12:01 AM, "Wolf Bergenheim" wrote: > On 18.09.2007 09:56, Michael Barton wrote: >> I tried the new fast g.mlist and got very weird results. Running g.mlist >> rast returned mapnames like... >> >> elevation.10mnrstrct.areasn >> >> ... instead of >> >> elevation.10m >> > > It seems there is a missing \ before the n somewhere in the code, since > \ + n => \n = new line. Or then your compiler doesn't handle "\n" properly. > > --Wolf __________________________________________ 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 Sep 18 09:08:37 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 18 09:08:43 2007 Subject: [GRASS-dev] g.mlist problem - followup In-Reply-To: Message-ID: There is a cascade from the g.mlist problem reported below. With g.mlist broken, the new TcTk animation module AND the selection control for wxPython GRASS GUI are also broken. Both are using g.mlist until g.list can be updated to optionally provide a flat list of GIS elements. It looks like g.mlist is returning parts of g.list's multicolumn format, separated by "n" instead of "\n" (new line). Michael On 9/17/07 11:56 PM, "Michael Barton" wrote: > I just updated from the cvs and compiled. > > I tried the new fast g.mlist and got very weird results. Running g.mlist rast > returned mapnames like... > > elevation.10mnrstrct.areasn > > ... instead of > > elevation.10m > > > Anyone have an idea what's going on? > > I'm on a MacBook Pro OS X. > > 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 > > __________________________________________ 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/20070918/359511a1/attachment.html From michael.barton at asu.edu Tue Sep 18 09:15:18 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Sep 18 09:15:45 2007 Subject: [GRASS-dev] g.mlist problem In-Reply-To: <46EF77C1.8080601@bergenheim.net> Message-ID: Wolf, I just checked the 'binary' version against the source version of g.mlist. Both are identical. There must be something problematic in the new code. Has anyone else had this problem? Has this been tried on a Mac? I don't know what difference that would make, but maybe something... I do know there there are some differences in Mac OS X awk and Linux awk. I don't know about sed and bash. Michael On 9/18/07 12:01 AM, "Wolf Bergenheim" wrote: > On 18.09.2007 09:56, Michael Barton wrote: >> I tried the new fast g.mlist and got very weird results. Running g.mlist >> rast returned mapnames like... >> >> elevation.10mnrstrct.areasn >> >> ... instead of >> >> elevation.10m >> > > It seems there is a missing \ before the n somewhere in the code, since > \ + n => \n = new line. Or then your compiler doesn't handle "\n" properly. > > --Wolf __________________________________________ 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 neteler at itc.it Tue Sep 18 09:36:29 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Sep 18 09:36:31 2007 Subject: [GRASS-dev] g.mlist problem In-Reply-To: References: Message-ID: <20070918073628.GB24138@bartok.itc.it> On Mon, Sep 17, 2007 at 11:56:02PM -0700, Michael Barton wrote: > I just updated from the cvs and compiled. > > I tried the new fast g.mlist and got very weird results. Running g.mlist > rast returned mapnames like... > > elevation.10mnrstrct.areasn > > ... instead of > > elevation.10m > > Anyone have an idea what's going on? > > I'm on a MacBook Pro OS X. Please post you command (note that g.mlist is a script, nothing to compile): GRASS 6.3.cvs (spearfish60):~ > g.mlist type=rast myfields aspect bugsites density elevation.10m elevation.dem ... ... works just fine. What do you exactly do? Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Tue Sep 18 09:38:26 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Sep 18 09:38:28 2007 Subject: [GRASS-dev] g.mlist problem In-Reply-To: References: <46EF77C1.8080601@bergenheim.net> Message-ID: <20070918073826.GC24138@bartok.itc.it> On Tue, Sep 18, 2007 at 12:15:18AM -0700, Michael Barton wrote: > Wolf, > > I just checked the 'binary' version against the source version of g.mlist. > Both are identical. > > There must be something problematic in the new code. Has anyone else had > this problem? > > Has this been tried on a Mac? I don't know what difference that would make, > but maybe something... I do know there there are some differences in Mac OS > X awk and Linux awk. I don't know about sed and bash. Could you put unset LC_ALL LC_NUMERIC=C export LC_NUMERIC somewhe