From glynn at gclements.plus.com Thu Nov 1 02:09:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 1 02:10:01 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <4728B54E.7060402@ufg.uni-kiel.de> References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be> <4721F27F.1030903@club.worldonline.be> <4721F454.9000303@ufg.uni-kiel.de> <472209EC.8040006@ufg.uni-kiel.de> <472212DC.1060503@club.worldonline.be> <4725A9E2.50807@ufg.uni-kiel.de> <4725AD25.3040607@club.worldonline.be> <4725D789.6070305@ufg.uni-kiel.de> <4725DD23.6050209@club.worldonline.be> <4725E2C6.9000408@ufg.uni-kiel.de> <18214.30000.228315.147756@cerise.gclements.plus.com> <4726E54B.7040508@ufg.uni-kiel.de> <18215.6250.408112.551042@cerise.gclements.plus.com> <47272DDF.4010203@ufg.uni-kiel.de> <20071031224813.11476432.hamish_nospam@yahoo.com> <47285231.10209@club.worldonline.be> <47285906.5080602@ufg.uni-kiel.de> <47285F44.6040006@club.worldonline.be> <18216.30530.150409.427150@cerise.gclements.plus.com> <47287C11.9080302@ufg.uni-kiel.de> <18216.33961.162827.605322@cerise.gclements.plus.com> <47288697.6080709@ufg.uni-kiel.de> <18216.41195.707277.398453@cerise.gclements.plus.com> <4728B54E.7060402@ufg.uni-kiel.de> Message-ID: <18217.10085.697186.84391@cerise.gclements.plus.com> Benjamin Ducke wrote: > >>> The scripts use a lot of common Unix utilities; have you included > >>> those? If they need to read any data files, are they looking for them > >>> in the WinGRASS directory or in the already-installed version of > >>> MSys/MinGW? > >> Yes, I made a complete install of MSYS + tools and just copied > >> everything over. I was going to look through it later to check > >> what can be thrown out and bit by bit make a list of what needs > >> to go in. > >> > >> The wingrass.bat script I posted early starts up cmd.exe in the user's > >> Windows home directory. Sh.exe also respects that. Thus, scripts look > >> for files in the user home dir first. > >> Which I think is OK. > > > > I'm talking about cases where the executable needs to open files in > > /etc, /usr/lib, /usr/share, etc. I'm guessing that the executable > > isn't going to be expecting "/" to be wherever you put GRASS. > > Do you have specific examples that I could test? Try running "strings" on the executables and looking for occurrences of /etc, /share etc. If you have "file", that will want /etc/magic. An interactive shell will try to read /etc/profile. Look for MSys files which aren't binaries or DLLs (which will be found using the path). They will be used by something, and that something will need to know where to find them. -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Thu Nov 1 09:41:13 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Nov 1 09:23:12 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: References: Message-ID: <47299129.7070103@ufg.uni-kiel.de> Michael Barton wrote: > I'd argue for something between these positions. > > I'd stick to just a GRASS installation to keep it simple and relatively > small. But, I'd really recommend that there is the option of a SINGLE > installation package for users. Most of the Windows users I deal with are > intimidated by a package that they download and then find out that they have > to go somewhere else and install something different just to use the first > package. > > So can we include TclTk and Mysys, if needed, in a single package that > allows all of GRASS to run? Yes, we can. I will put together such a "complete" package including these and other useful things for GRASS that are currently in the add-on repository. That would also include my own GRASS extensions and r.cva (which finally seems to run OK on Windows). We will then have an all-in-one package for novice users and Moritz can still provide a bare-bones version for people that need or want it lean. I think this should make everyone happy. Benjamin > > Michael > > > On 10/31/07 8:25 AM, "Moritz Lennert" wrote: > >> On 31/10/07 13:58, Benjamin Ducke wrote: >>> Glynn Clements wrote: >>>> Moritz Lennert wrote: >>>> >>>>> So, I still believe that: >>>>> >>>>> rem Path to the shell command >>>>> rem set GRASS_SH=c:\msys\1.0\bin\sh.exe >>>>> >>>>> is a better solution (since allowing the user to install what they want >>>>> where they want) than >>> Yes, but often (especially my type of user), they don't know enough >>> to want anything (see below). >>> Anyway, a knowledgeable user can always adjust those vars by hand! >>> >>>> Agreed. The above is the only location where a Bourne shell is likely >>>> to be found. If it's anywhere else, the user will have to set it >>>> manually. >>> Or we supply it as part of the WinGRASS binary distribution! (see below) >>> >>>> The relative path will only work if grass63.bat is installed in >>>> c:\msys\1.0, so there's no benefit to using it. >>> Not quite. With the setup above, GRASS can be installed _anywhere_ on >>> the file system. The only prerequisite is that grass63.bat sits >>> in the same folder as the GRASS install dir. >>> E.g. on my harddisk I have grass63.bat in c:\WinGRASS\ >>> and the GRASS dir (grass-6.3.cvs) in the same folder. >>> >>> I then copied C:\msys\1.0\bin, dll and share >>> (at least the parts that I needed for using the shell) into >>> c:\WinGRASS. >>> >>> This way, I have a completely self-contained GRASS distribution. >>> I can add more bits an pieces (such as R) easily as needed and >>> at the end, put everything into on ZIP for distribution. >>> >>> I don't know what could be easier. Especially since this approach >>> does not interfere with an MSYS already installed on the user's >>> system. >> But it might install the same programs twice on the machine and probably >> bloat the grass distribution by quite a lot (don't forget that most >> people do not have broadband) ... >> >> IMO, we should stick to a basic wingrass distribution to which people >> can add what they want in terms of other programs. If they want access >> to R, they can add R's bin + lib directories to the path and that's it. >> >> If you have a particular audience that needs a series of add-ons and >> tweaks than you can provide a special package for them, but I prefer to >> distribute a simple package without any unnecessary additions (and I >> consider msys an unnecessary addition in this context as there is hardly >> anything you cannot do without scripts - it just might not be as >> convienient). Don't assume that everyone has the same needs as you. >> >> And up to now feedback has been that installation of the wingrass >> package is very easy... >> >> However, I agree that we could maybe provide more detailled >> documentation on how to integrate different packages (at least msys). >> >> Moritz >> >>> The benefit for the user is that only one .bat is visible in >>> the top dir: it's clear what to click on and there is no >>> searching in bin grass-6.3.cvs/bin or wherever to find >>> a startup-script. >> If the instructions in the readme are not clear enough, please provide >> suggestions for improvement. Up to now I have not received any feedback >> from users not being able to find how to launch grass. >> >>> Please keep in mind, that my Windows target users will often not >>> have the ability (or patience) to install MSYS by themselves and set >>> the appropriate vars in some obscure batch script -- they just >>> want to click and run GRASS! >> And so they _can_ with the current distribution, except for the fact >> that they have to install ActiveTcl if they want the gui (and the fact >> that the instructions need a reference to how to start grass in text >> mode). This should be solved by giving the option of downloading a grass >> package including a free tcl/tk installation. >> >> My point above concerning msys being unnecessary is obviously arguable >> and if there is a general opinion that we should include it, we can (but >> without any need to change the grass63.bat except for uncommenting the >> line about where to find sh.exe and another to set the necessary PATH). >> >> Moritz >> >> > > __________________________________________ > 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 > > > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From benjamin.ducke at ufg.uni-kiel.de Thu Nov 1 09:44:26 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Nov 1 09:26:22 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <194309.10140.qm@web52708.mail.re2.yahoo.com> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> Message-ID: <472991EA.1020002@ufg.uni-kiel.de> > > we should make a list of the minimal set of needed commands, eg > awk > cat > cut > expr > grep > head > ls > paste > rm > sed > sort > tac > tail > tr > uniq > wc > which > Yes, that's definitely a good idea. Maybe I could just make a minimal MSYS install from scratch, check that the tools you listed (additions, anyone?) are in there and then try and remove more "bloat" until we are left with the minimum of what's needed. That should severely cut down on the size of the MSYS package we'd need to provide. Let's just all try and put together a complete list of what's needed first, then I'll have a go at it. Benjamin > > Hamish > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From benjamin.ducke at ufg.uni-kiel.de Thu Nov 1 09:29:41 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Nov 1 09:30:42 2007 Subject: [GRASS-dev] WinGRASS curses issue In-Reply-To: <658480.99626.qm@web52704.mail.re2.yahoo.com> References: <658480.99626.qm@web52704.mail.re2.yahoo.com> Message-ID: <47298E75.7070902@ufg.uni-kiel.de> I think this whole tab completion thing on Win is just too friggin' complicated and time-consuming for the moment. Better to get down to resolving the more serious issues first for the 6.3.0 release. Benjamin Hamish wrote: > Benjamin: >>> I made another ugly discovery: cmd.exe's tab completion is >>> _turned off_ by default on Win >=2000 (unbelievable!). >>> It could be done by writing a registry value (sic!) into >>> the user's registry tree. >>> Should I add that to grass63.bat? > Moritz: >> Please don't. If people want tab completion, they can set it themselves. >> This is not related to GRASS. > > I agree with Moritz, maybe the user set it that way for a reason. > > But if you have a quick way of turning it on (ISTR that either the TweakUI > PowerTool or cmd.exe's context menu Properties gave you the option to turn it > on) You could leave it commented out in the .bat file, and/or add a note to the > WinGRASS help page* about how to turn it on and link to the page that talks > about enabling it for map names**. > > * http://grass.ibiblio.org/platforms/wingrass > or is there something newer on the wiki? > > ** http://grass.ibiblio.org/download/addons.php > but that needs an update for GRASS 6? anyone using this? > > > Hamish > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From rez at touchofmadness.com Thu Nov 1 09:44:37 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Nov 1 09:44:41 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <472991EA.1020002@ufg.uni-kiel.de> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> Message-ID: <1193906678.2980.140.camel@dev64.localdomain> On Thu, 2007-11-01 at 09:44 +0100, Benjamin Ducke wrote: > > > > we should make a list of the minimal set of needed commands, eg > > awk > > cat > > cut > > expr > > grep > > head > > ls > > paste > > rm > > sed > > sort > > tac > > tail > > tr > > uniq > > wc > > which > > > > Yes, that's definitely a good idea. > Maybe I could just make a minimal MSYS install from scratch, > check that the tools you listed (additions, anyone?) are in > there and then try and remove more "bloat" until we are left > with the minimum of what's needed. > > That should severely cut down on the size of the MSYS package > we'd need to provide. > > Let's just all try and put together a complete list of what's > needed first, then I'll have a go at it. I haven't been following the thread, but caught something interesting in this message. It may be overkill, but I'd like to add configure checks for the final listing. What we have has served us well, but adding more checks takes little time and would help catch portability issues. Please cc: me on the final list unless someone decides this would be more clutter than solution. -- 73, de Brad KB8UYR/6 From glynn at gclements.plus.com Thu Nov 1 11:01:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 1 11:01:19 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <472991EA.1020002@ufg.uni-kiel.de> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> Message-ID: <18217.41963.573310.753044@cerise.gclements.plus.com> Benjamin Ducke wrote: > > we should make a list of the minimal set of needed commands, eg > > awk > > cat > > cut > > expr > > grep > > head > > ls > > paste > > rm > > sed > > sort > > tac > > tail > > tr > > uniq > > wc > > which > > > > Yes, that's definitely a good idea. > Maybe I could just make a minimal MSYS install from scratch, > check that the tools you listed (additions, anyone?) are in > there and then try and remove more "bloat" until we are left > with the minimum of what's needed. > > That should severely cut down on the size of the MSYS package > we'd need to provide. > > Let's just all try and put together a complete list of what's > needed first, then I'll have a go at it. I see the following: 1. Standard utilities from coreutils: [ basename cat cp cut date dirname echo expr head ls mkdir mv paste pwd rm rmdir sleep sort tac tail tee tr uniq wc Of those, [, echo and pwd exist both as bash built-ins and external utilities. 2. Standard utilities not part of coreutils: awk bc diff file find grep sed which [Note that "file" needs to locate /etc/magic.] 3. Additional utilities: avcimport v.in.e00 cs2cs m.proj, r.tileset, v.in.garmin, v.in.gpsbabel curl r.in.wms e00conv v.in.e00 fc-list mkftcap gardump v.in.garmin gdal_translate d.out.file, r.out.gdal.sh gdalinfo i.in.spotvgt, r.out.gdal.sh gdalwarp r.in.aster, r.in.wms gnuplot i.spectral gpsbabel v.in.gpsbabel gpstrans v.in.garmin ldd v.in.wfs lynx v.in.wfs man g.manual ogrinfo v.in.wfs perl d.monsize pngtopnm d.out.gpsdrive pnmtojpeg d.out.gpsdrive sqlite3 v.db.join sync d.out.gpsdrive unzip r.in.srtm wget r.in.wms wms.download r.in.wms wms.request r.in.wms xgraph d.polar xml2 r.in.wms BTW, the use of "ldd" by v.in.wfs is entirely bogus: # xerces support compiled in? OGRINFO=`which ogrinfo` if [ -z "`ldd $OGRINFO | grep xerces`" ] ; then g.message -e "OGR needs to be compiled with xerces-c support" exit 1 fi This needs to be changed to something which will work on other platforms. Does "gdalinfo --formats" suffice? Also, we don't really need all three of lynx, wget and curl; any one of those would suffice. -- Glynn Clements From glynn at gclements.plus.com Thu Nov 1 11:30:23 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 1 11:30:25 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <1193906678.2980.140.camel@dev64.localdomain> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <1193906678.2980.140.camel@dev64.localdomain> Message-ID: <18217.43711.32560.445575@cerise.gclements.plus.com> Brad Douglas wrote: > > Let's just all try and put together a complete list of what's > > needed first, then I'll have a go at it. > > I haven't been following the thread, but caught something interesting in > this message. > > It may be overkill, but I'd like to add configure checks for the final > listing. What we have has served us well, but adding more checks takes > little time and would help catch portability issues. > > Please cc: me on the final list unless someone decides this would be > more clutter than solution. configure is meant for compile-time checks. You can still build GRASS without the utilities which are used in scripts. Conversely, just because the utilities are present on the host, it doesn't mean that they will be present on the target. -- Glynn Clements From hamish_nospam at yahoo.com Thu Nov 1 13:02:03 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 1 13:02:07 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <18217.41963.573310.753044@cerise.gclements.plus.com> Message-ID: <740033.3782.qm@web52703.mail.re2.yahoo.com> Hamish: > > > we should make a list of the minimal set of needed commands, eg .. Benjamin: > > Yes, that's definitely a good idea. > > Maybe I could just make a minimal MSYS install from scratch, > > check that the tools you listed (additions, anyone?) are in > > there and then try and remove more "bloat" until we are left > > with the minimum of what's needed. > > > > That should severely cut down on the size of the MSYS package > > we'd need to provide. > > > > Let's just all try and put together a complete list of what's > > needed first, then I'll have a go at it. Glynn: > I see the following: > > 1. Standard utilities from coreutils: > > [ > basename > cat > cp > cut > date > dirname > echo > expr > head > ls > mkdir > mv > paste > pwd > rm > rmdir > sleep > sort > tac > tail > tee > tr > uniq > wc > > Of those, [, echo and pwd exist both as bash built-ins and external > utilities. > > 2. Standard utilities not part of coreutils: > > awk > bc > diff > file > find > grep > sed > which > > [Note that "file" needs to locate /etc/magic.] > > 3. Additional utilities: > > avcimport v.in.e00 > cs2cs m.proj, r.tileset, v.in.garmin, v.in.gpsbabel > curl r.in.wms > e00conv v.in.e00 > fc-list mkftcap > gardump v.in.garmin > gdal_translate d.out.file, r.out.gdal.sh > gdalinfo i.in.spotvgt, r.out.gdal.sh > gdalwarp r.in.aster, r.in.wms > gnuplot i.spectral > gpsbabel v.in.gpsbabel > gpstrans v.in.garmin > ldd v.in.wfs > lynx v.in.wfs > man g.manual > ogrinfo v.in.wfs > perl d.monsize > pngtopnm d.out.gpsdrive > pnmtojpeg d.out.gpsdrive > sqlite3 v.db.join > sync d.out.gpsdrive > unzip r.in.srtm > wget r.in.wms > wms.download r.in.wms > wms.request r.in.wms > xgraph d.polar > xml2 r.in.wms wms.download and wms.request are internal from scripts/r.in.wms/ missing: mpeg_encode or ppmtompeg for r.out.mpeg some of the above are optional (d.polar will work without xgraph, r.in.wms will work without xml2) curl & wget are either/or gardump & gpstrans are either/or and probably UNIX,Linux specific, respectively GpsDrive is not ported to MS Windows so d.out.gpsdrive deps are low priority All the C system() calls need to be searched too I guess. > BTW, the use of "ldd" by v.in.wfs is entirely bogus: > > # xerces support compiled in? > OGRINFO=`which ogrinfo` > if [ -z "`ldd $OGRINFO | grep xerces`" ] ; then > g.message -e "OGR needs to be compiled with xerces-c support" > exit 1 > fi > > This needs to be changed to something which will work on other > platforms. Does "gdalinfo --formats" suffice? Nope. $ ogrinfo --formats | grep -ic xer 0 $ ldd `which ogrinfo` | grep xer libxerces-c.so.27 => /usr/lib/libxerces-c.so.27 (0xb76c0000) as Xerces is apparently a XML parser not a vector format :) You could try $ gdal-config --dep-libs | tr ' ' '\n' | grep -ci xerces 1 but then gdal-config isn't always around. e.g. on Debian gdal-config comes with the libgdal1-dev package and not the gdal-bin package. (and the libgdal1-dev package depends on 18 other dev packages, which in turn depend on enough stuff to make it a 20-50mb download just to run gdal-config. :-/ ) > Also, we don't really need all three of lynx, wget and curl; any one > of those would suffice. IIRC lynx is used to strip off HTML tags, ie to convert .html to .txt. r.in.wms (wms.download) checks for wget. If it can't find it it then looks for curl. (Apparently curl comes with MacOSX but wget doesn't) So we wouldn't want to supply both. Hamish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From hamish_nospam at yahoo.com Thu Nov 1 13:05:18 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 1 13:05:21 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <18217.41963.573310.753044@cerise.gclements.plus.com> Message-ID: <218620.22089.qm@web52710.mail.re2.yahoo.com> oh, and whatever uses "bc" could be rewritten to use awk for FP math. In most places it already has been. Hamish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From benjamin.ducke at ufg.uni-kiel.de Thu Nov 1 13:14:07 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Nov 1 13:15:07 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <740033.3782.qm@web52703.mail.re2.yahoo.com> References: <740033.3782.qm@web52703.mail.re2.yahoo.com> Message-ID: <4729C30F.60107@ufg.uni-kiel.de> > > wms.download and wms.request are internal from scripts/r.in.wms/ > > missing: > mpeg_encode or ppmtompeg for r.out.mpeg There are several mpeg encoders with a binary called mpeg_encode around. Which one is the one we need, specifically? Is ppmtompeg the one that comes with the NetPBM tools? > > some of the above are optional > (d.polar will work without xgraph, r.in.wms will work without xml2) > > curl & wget are either/or > gardump & gpstrans are either/or and probably UNIX,Linux specific, respectively > GpsDrive is not ported to MS Windows so d.out.gpsdrive deps are low priority > > All the C system() calls need to be searched too I guess. > > > >> BTW, the use of "ldd" by v.in.wfs is entirely bogus: >> >> # xerces support compiled in? >> OGRINFO=`which ogrinfo` >> if [ -z "`ldd $OGRINFO | grep xerces`" ] ; then >> g.message -e "OGR needs to be compiled with xerces-c support" >> exit 1 >> fi >> >> This needs to be changed to something which will work on other >> platforms. Does "gdalinfo --formats" suffice? As far as the Win binaries are concerned: why not just ship them with Xerces support in GDAL? > > >> Also, we don't really need all three of lynx, wget and curl; any one >> of those would suffice. > > IIRC lynx is used to strip off HTML tags, ie to convert .html to .txt. > > r.in.wms (wms.download) checks for wget. If it can't find it it then looks for > curl. (Apparently curl comes with MacOSX but wget doesn't) That's correct (at least for Mac OS 10.4 as far as I can tell). Both are tiny little things, though, so how much harm would it do to pack them both? > So we wouldn't want to supply both. > > > Hamish > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From mlennert at club.worldonline.be Thu Nov 1 13:28:41 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Nov 1 13:33:21 2007 Subject: [GRASS-dev] WinGRASS curses issue In-Reply-To: <18216.40712.310855.30515@cerise.gclements.plus.com> References: <47288243.3080604@ufg.uni-kiel.de> <18216.40712.310855.30515@cerise.gclements.plus.com> Message-ID: <1571.85.10.71.105.1193920121.squirrel@geog-pc40.ulb.ac.be> On Wed, October 31, 2007 16:28, Glynn Clements wrote: > > Benjamin Ducke wrote: > >> I just noticed another, more severe problem on Windows: >> >> I can only use ESC key sequences in the first interactive text input >> window. When I progress to the next one, they don't work >> anymore. This means that I cannot create a new location >> from scratch under WinGRASS, because I can exit the >> first screen (the one asking for names) with ESC+ENTER, >> but the next one (the one for setting the default region) >> does not interpret EST+ENTER correctly anymore, meaning >> I can only quit it with CTRL+C! >> >> This happens with my GRASS binaries and Moritz' > > That would appear to be a problem with the curses implementation. > > The Esc-Enter behaviour is part of the vask library (V_call(), in > lib/vask/V_call.c). If it works in some cases and not others, I'm not > sure what can be done. I've just had a look at lib/init/set_data.c and don't really see what the problem is. A clue we have is that ESC-ENTER works in the first screen, but not in the region definition screen. In terms of code, the only immediate difference between the two I see is that the first is constructed directly in set_data.c, including the V_call(), whereas the second is called with E_edit_cellhd(&window, -1), so the actual screen construction and V_call() are in lib/edit/edit_cellhd.c. Could that make any difference ? I'll try to add some debug code, but first have to understand how to best do that in the vask environment. Moritz From mlennert at club.worldonline.be Thu Nov 1 13:41:04 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Nov 1 13:45:44 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <47299129.7070103@ufg.uni-kiel.de> References: <47299129.7070103@ufg.uni-kiel.de> Message-ID: <1612.85.10.71.105.1193920864.squirrel@geog-pc40.ulb.ac.be> On Thu, November 1, 2007 09:41, Benjamin Ducke wrote: > Michael Barton wrote: >> So can we include TclTk and Mysys, if needed, in a single package that >> allows all of GRASS to run? > > Yes, we can. > I will put together such a "complete" package including these and other > useful things for GRASS that are currently in the add-on repository. > That would also include my own GRASS extensions and r.cva (which finally > seems to run OK on Windows). > > We will then have an all-in-one package for novice users and Moritz can > still provide a bare-bones version for people that need or want it lean. > > I think this should make everyone happy. I agree. Let's go for two packages (like many others do): one without dependencies included, one with. I would, however, limit the first to basic dependencies (sh.exe and other utils for scripts, tcltk) and not include things such as R, PostgreSQL, etc. We do however have to keep in mind the issue of licensing and distribution of source code: On Sat, October 27, 2007 05:34, Glynn Clements wrote: > Apart from including a copy of the GPL, the other main requirement is > that the source code is available "from the same place" as the > binaries. It is *not* sufficient to refer the user to a different > site. > > Alternatively, we could include a written offer to provide the source > code on demand, but then we have to keep a copy of the source code > around for at least three years in case anyone ever takes us up on it > (don't assume that the source code for the specific version which we > include will still be available elsewhere in three years' time). Thus, if we include more packages, we will have to keep more copies of the used source code around... So this means tcltk and msys. Would it be an envisageable option to build an installer which installs the basic grass distribution and optionally downloads and installs other packages from their respective websites if the user so choses ? Moritz From mlennert at club.worldonline.be Thu Nov 1 14:01:59 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Nov 1 14:06:38 2007 Subject: [GRASS-dev] WinGRASS curses issue In-Reply-To: <1571.85.10.71.105.1193920121.squirrel@geog-pc40.ulb.ac.be> References: <47288243.3080604@ufg.uni-kiel.de> <18216.40712.310855.30515@cerise.gclements.plus.com> <1571.85.10.71.105.1193920121.squirrel@geog-pc40.ulb.ac.be> Message-ID: <1690.85.10.71.105.1193922119.squirrel@geog-pc40.ulb.ac.be> On Thu, November 1, 2007 13:28, Moritz Lennert wrote: > On Wed, October 31, 2007 16:28, Glynn Clements wrote: >> >> Benjamin Ducke wrote: >> >>> I just noticed another, more severe problem on Windows: >>> >>> I can only use ESC key sequences in the first interactive text input >>> window. When I progress to the next one, they don't work >>> anymore. This means that I cannot create a new location >>> from scratch under WinGRASS, because I can exit the >>> first screen (the one asking for names) with ESC+ENTER, >>> but the next one (the one for setting the default region) >>> does not interpret EST+ENTER correctly anymore, meaning >>> I can only quit it with CTRL+C! >>> >>> This happens with my GRASS binaries and Moritz' >> >> That would appear to be a problem with the curses implementation. >> >> The Esc-Enter behaviour is part of the vask library (V_call(), in >> lib/vask/V_call.c). If it works in some cases and not others, I'm not >> sure what can be done. > > I've just had a look at lib/init/set_data.c and don't really see what the > problem is. A clue we have is that ESC-ENTER works in the first screen, > but not in the region definition screen. In terms of code, the only > immediate difference between the two I see is that the first is > constructed directly in set_data.c, including the V_call(), whereas the > second is called with E_edit_cellhd(&window, -1), so the actual screen > construction and V_call() are in lib/edit/edit_cellhd.c. Could that make > any difference ? > > I'll try to add some debug code, but first have to understand how to best > do that in the vask environment. A little more info: When I leave the region definition screen using Ctrl-C, I get back to the very first screen where you set location, mapset, etc. And this second time, I cannot use ESC-ENTER either. The first time on that screen (when I launch grass) it works... Is there something that remains in memory and which confuses V_call ? Moritz From glynn at gclements.plus.com Thu Nov 1 14:46:06 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 1 14:46:09 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <740033.3782.qm@web52703.mail.re2.yahoo.com> References: <18217.41963.573310.753044@cerise.gclements.plus.com> <740033.3782.qm@web52703.mail.re2.yahoo.com> Message-ID: <18217.55454.636779.708749@cerise.gclements.plus.com> Hamish wrote: > All the C system() calls need to be searched too I guess. And popen(), and G_{system,popen,spawn,spawn_ex}. > > BTW, the use of "ldd" by v.in.wfs is entirely bogus: > > > > # xerces support compiled in? > > OGRINFO=`which ogrinfo` > > if [ -z "`ldd $OGRINFO | grep xerces`" ] ; then > > g.message -e "OGR needs to be compiled with xerces-c support" > > exit 1 > > fi > > > > This needs to be changed to something which will work on other > > platforms. Does "gdalinfo --formats" suffice? > > Nope. > $ ogrinfo --formats | grep -ic xer > 0 > $ ldd `which ogrinfo` | grep xer > libxerces-c.so.27 => /usr/lib/libxerces-c.so.27 (0xb76c0000) > > as Xerces is apparently a XML parser not a vector format :) > > You could try > $ gdal-config --dep-libs | tr ' ' '\n' | grep -ci xerces > 1 > > but then gdal-config isn't always around. e.g. on Debian gdal-config comes with > the libgdal1-dev package and not the gdal-bin package. (and the libgdal1-dev > package depends on 18 other dev packages, which in turn depend on enough stuff > to make it a 20-50mb download just to run gdal-config. :-/ ) And it still won't show anything if xerces is linked statically into libgdal. I suspect that the only real solution is to simply try it. > > Also, we don't really need all three of lynx, wget and curl; any one > > of those would suffice. > > IIRC lynx is used to strip off HTML tags, ie to convert .html to .txt. But it's supposed to be saving an XML file: lynx -dump "$WFS_URL" > "$TMP.xml" -- Glynn Clements From glynn at gclements.plus.com Thu Nov 1 14:49:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 1 14:49:20 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <4729C30F.60107@ufg.uni-kiel.de> References: <740033.3782.qm@web52703.mail.re2.yahoo.com> <4729C30F.60107@ufg.uni-kiel.de> Message-ID: <18217.55646.282448.492177@cerise.gclements.plus.com> Benjamin Ducke wrote: > >> BTW, the use of "ldd" by v.in.wfs is entirely bogus: > >> > >> # xerces support compiled in? > >> OGRINFO=`which ogrinfo` > >> if [ -z "`ldd $OGRINFO | grep xerces`" ] ; then > >> g.message -e "OGR needs to be compiled with xerces-c support" > >> exit 1 > >> fi > >> > >> This needs to be changed to something which will work on other > >> platforms. Does "gdalinfo --formats" suffice? > > As far as the Win binaries are concerned: why not just ship them with > Xerces support in GDAL? The problem isn't that v.in.wfs requires that GDAL was built with xerces support, it's that the way that it checks for that support won't work on Windows (or anything other than Linux or Solaris). > >> Also, we don't really need all three of lynx, wget and curl; any one > >> of those would suffice. > > > > IIRC lynx is used to strip off HTML tags, ie to convert .html to .txt. > > > > r.in.wms (wms.download) checks for wget. If it can't find it it then looks for > > curl. (Apparently curl comes with MacOSX but wget doesn't) > > That's correct (at least for Mac OS 10.4 as far as I can tell). > Both are tiny little things, though, so how much harm > would it do to pack them both? If it only needs one, there's no point in including both. -- Glynn Clements From glynn at gclements.plus.com Thu Nov 1 14:51:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 1 14:51:10 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <218620.22089.qm@web52710.mail.re2.yahoo.com> References: <18217.41963.573310.753044@cerise.gclements.plus.com> <218620.22089.qm@web52710.mail.re2.yahoo.com> Message-ID: <18217.55756.517053.169120@cerise.gclements.plus.com> Hamish wrote: > oh, and whatever uses "bc" could be rewritten to use awk for FP math. r.in.wms and r.tileset use "bc". -- Glynn Clements From mlennert at club.worldonline.be Thu Nov 1 15:20:55 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Nov 1 15:25:35 2007 Subject: [GRASS-dev] WinGRASS curses issue In-Reply-To: <1690.85.10.71.105.1193922119.squirrel@geog-pc40.ulb.ac.be> References: <47288243.3080604@ufg.uni-kiel.de> <18216.40712.310855.30515@cerise.gclements.plus.com> <1571.85.10.71.105.1193920121.squirrel@geog-pc40.ulb.ac.be> <1690.85.10.71.105.1193922119.squirrel@geog-pc40.ulb.ac.be> Message-ID: <1991.85.10.71.105.1193926855.squirrel@geog-pc40.ulb.ac.be> I found the problem: I don't know why but pushing enter gives a CR (carriage return) the very first time, but from then on always gives NL (newline). But V_call only checked for the first. Fixed in cvs: Index: V_call.c =================================================================== RCS file: /grassrepository/grass6/lib/vask/V_call.c,v retrieving revision 2.3 retrieving revision 2.4 diff -u -d -r2.3 -r2.4 --- V_call.c 21 Apr 2007 05:33:01 -0000 2.3 +++ V_call.c 1 Nov 2007 14:23:02 -0000 2.4 @@ -307,7 +307,7 @@ case NL: new_answer = (at_answer+1) % num_answers ; ans_col = 0 ; - if (lastchar == ESC && newchar == CR) + if (lastchar == ESC && (newchar == CR || newchar == NL)) done = 1; break ; Moritz From glynn at gclements.plus.com Thu Nov 1 15:32:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Nov 1 15:32:32 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <18217.41963.573310.753044@cerise.gclements.plus.com> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <18217.41963.573310.753044@cerise.gclements.plus.com> Message-ID: <18217.58237.931274.556101@cerise.gclements.plus.com> Glynn Clements wrote: > 3. Additional utilities: > perl d.monsize BTW, this one is rather gratuitous: # STrip leading blanks st3=`echo $st2|perl -pne 's/^\s+//g'` sed should suffice here. -- Glynn Clements From mlennert at club.worldonline.be Thu Nov 1 15:56:01 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Nov 1 16:00:42 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <18217.58237.931274.556101@cerise.gclements.plus.com> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <18217.41963.573310.753044@cerise.gclements.plus.com> <18217.58237.931274.556101@cerise.gclements.plus.com> Message-ID: <2111.85.10.71.105.1193928961.squirrel@geog-pc40.ulb.ac.be> On Thu, November 1, 2007 15:32, Glynn Clements wrote: > > Glynn Clements wrote: > >> 3. Additional utilities: > >> perl d.monsize > > BTW, this one is rather gratuitous: I guess that if this is for a windows distribution, any of the d.* modules can be left aside, or ? Moritz From michael.barton at asu.edu Thu Nov 1 16:24:15 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 1 16:24:23 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <47299129.7070103@ufg.uni-kiel.de> Message-ID: This would be excellent. It is much easier for students in my upcoming class to install and possibly much easier for computer lab managers to get their heads around. Michael On 11/1/07 1:41 AM, "Benjamin Ducke" wrote: > Michael Barton wrote: >> I'd argue for something between these positions. >> >> I'd stick to just a GRASS installation to keep it simple and relatively >> small. But, I'd really recommend that there is the option of a SINGLE >> installation package for users. Most of the Windows users I deal with are >> intimidated by a package that they download and then find out that they have >> to go somewhere else and install something different just to use the first >> package. >> >> So can we include TclTk and Mysys, if needed, in a single package that >> allows all of GRASS to run? > > Yes, we can. > I will put together such a "complete" package including these and other > useful things for GRASS that are currently in the add-on repository. > That would also include my own GRASS extensions and r.cva (which finally > seems to run OK on Windows). > > We will then have an all-in-one package for novice users and Moritz can > still provide a bare-bones version for people that need or want it lean. > > I think this should make everyone happy. > > Benjamin __________________________________________ 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 benjamin.ducke at ufg.uni-kiel.de Thu Nov 1 17:11:42 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Nov 1 17:12:41 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: References: Message-ID: <4729FABE.5000101@ufg.uni-kiel.de> Michael Barton wrote: > This would be excellent. It is much easier for students in my upcoming class > to install and possibly much easier for computer lab managers to get their > heads around. Especially since it does not require any admin rights (or indeed a local install). You can run it from your usb pendrive and need not to work around the MS certified admins ... > > Michael > > > On 11/1/07 1:41 AM, "Benjamin Ducke" wrote: > >> Michael Barton wrote: >>> I'd argue for something between these positions. >>> >>> I'd stick to just a GRASS installation to keep it simple and relatively >>> small. But, I'd really recommend that there is the option of a SINGLE >>> installation package for users. Most of the Windows users I deal with are >>> intimidated by a package that they download and then find out that they have >>> to go somewhere else and install something different just to use the first >>> package. >>> >>> So can we include TclTk and Mysys, if needed, in a single package that >>> allows all of GRASS to run? >> Yes, we can. >> I will put together such a "complete" package including these and other >> useful things for GRASS that are currently in the add-on repository. >> That would also include my own GRASS extensions and r.cva (which finally >> seems to run OK on Windows). >> >> We will then have an all-in-one package for novice users and Moritz can >> still provide a bare-bones version for people that need or want it lean. >> >> I think this should make everyone happy. >> >> Benjamin > > __________________________________________ > 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 > > > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From mlennert at club.worldonline.be Thu Nov 1 17:37:47 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Nov 1 17:42:28 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: <47285906.5080602@ufg.uni-kiel.de> References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be> <4721CC87.5010609@club.worldonline.be> <4721E0E0.6080500@ufg.uni-kiel.de> <4721E80B.90606@ufg.uni-kiel.de> <4721EDB9.4090206@ufg.uni-kiel.de> <4721F27F.1030903@club.worldonline.be> <4721F454.9000303@ufg.uni-kiel.de> <472209EC.8040006@ufg.uni-kiel.de> <472212DC.1060503@club.worldonline.be> <4725A9E2.50807@ufg.uni-kiel.de> <4725AD25.3040607@club.worldonline.be> <4725D789.6070305@ufg.uni-kiel.de> <4725DD23.6050209@club.worldonline.be> <4725E2C6.9000408@ufg.uni-kiel.de> <18214.30000.228315.147756@cerise.gclements.plus.com> <4726E54B.7040508@ufg.uni-kiel.de> <18215.6250.408112.551042@cerise.gclements.plus.com> <47272DDF.4010203@ufg.uni-kiel.de> <20071031224813.11476432.hamish_nospam@yahoo.com> <47285231.10209@club.worldonline.be> <47285906.5080602@ufg.uni-kiel.de> Message-ID: <2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be> On Wed, October 31, 2007 11:29, Benjamin Ducke wrote: > The start command does actually work to put gis.m in the background. > I changed init.bat to read: I propose to do it in this (slightly modified) way: In init.bat: === rem Get LOCATION_NAME to use in prompt FOR /F "usebackq delims==" %%i IN (`g.gisenv "get=LOCATION_NAME"`) DO @set LOCATION_NAME=%%i cd %HOME% prompt GRASS %GRASS_VERSION% $C%LOCATION_NAME%$F:$P $G start "GRASS %GRASS_VERSION% Shell" cmd.exe /E:ON /F:ON /V:ON %WINGISBASE%\bin\gis.m.bat === where gis.m.bat simply contains: === @ start "GIS Manager" "%GRASS_WISH%" "%WINGISBASE%/etc/gm/gm.tcl" === This way we have a functioning gis.m.bat which one can also launch from the command line if grass was started with in text mode. Nice also to finally get rid of this empty and useless cmd.exe window we had before. Only thing which is a bit annoying: you have to close the two (cmd and gis.m) seperately (i.e. gis.m does not close when you type exit in cmd.exe). But that's minor in my eyes. One question I don't know how to solve, though: just as for other scripts a gis.m.bat is created during compilation, which contains: @"%GRASS_SH%" -c '"%GISBASE%/scripts/gis.m" %*' However, I think that gis.m should run independently of whether someone has installed a shell, so I'd rather replace this bat file by the one above. This would mean creating some form of exception for gis.m to the below entry in include/Make/Script.make: $(BIN)/$(PGM).bat: $(MODULE_TOPDIR)/scripts/windows_launch.bat^M sed -e "s#SCRIPT_NAME#$(PGM)#" $(MODULE_TOPDIR)/scripts/windows_launch.bat > $@ Is that possible ? Any other suggestions ? Moritz From mlennert at club.worldonline.be Thu Nov 1 17:58:08 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Nov 1 18:02:49 2007 Subject: [GRASS-dev] projshare path Message-ID: <2637.85.10.71.105.1193936288.squirrel@geog-pc40.ulb.ac.be> Another issue with paths: For configure I have to give the location of the proj share directory in *nix path form (/c/grass/share/proj/). However, this won't work at runtime. So we need to translate PROJSHARE from one to the other before putting it into init.bat. Moritz From hamish_nospam at yahoo.com Thu Nov 1 19:51:02 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Nov 1 19:51:05 2007 Subject: [GRASS-dev] Wingrass and TclTk (r.out.mpeg) In-Reply-To: <4729C30F.60107@ufg.uni-kiel.de> Message-ID: <552467.72184.qm@web52706.mail.re2.yahoo.com> Hamish: > > mpeg_encode or ppmtompeg for r.out.mpeg Benjamin: > There are several mpeg encoders with a binary called mpeg_encode around. > Which one is the one we need, specifically? from the r.out.mpeg help page:

NOTES

This program requires the program mpeg_encode (aka ppmtompeg):

MPEG-1 Video Software Encoder
(Version 1.3; March 14, 1994)

Lawrence A. Rowe, Kevin Gong, Ketan Patel, and Dan Wallach Computer Science Division-EECS,

Univ. of Calif. at Berkeley

Available from Berkeley: http://bmrc.berkeley.ed u/frame/research/mpeg/mpeg_encode.html
or as part of the netpbm package (ppmtompeg): http://netpbm.sourceforge.net > Is ppmtompeg the one that comes with the NetPBM tools? Yes. It is essentially the same code as from Berley, but the NetPBM version is still maintained so it is preferred. (and it's easier to get) Note that this is MPEG-1, and MPEG-1 is slow to encode and creates big files of poor quality. What it has going for it over more modern versions (ie MPEG-4) is widespread deployment of the codec and it is in the public domain. MPEG-4 is supposedly a patent mine field (in the USA). For access to other codecs you could rewrite r.out.mpeg to use the ffmpeg libraries or as a shell script that calls mplayer's mencoder or transcode. Hamish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From michael.barton at asu.edu Thu Nov 1 21:37:09 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Nov 1 21:38:25 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <18217.41963.573310.753044@cerise.gclements.plus.com> Message-ID: Most of these shell scripts are not in the menu system because they require external programs that are not GRASS dependencies. Unless you are planning for Windows users to run these from the command line, you can eliminate many of these. Michael On 11/1/07 3:01 AM, "Glynn Clements" wrote: > 3. Additional utilities: > > avcimport v.in.e00 > cs2cs m.proj, r.tileset, v.in.garmin, v.in.gpsbabel > curl r.in.wms > e00conv v.in.e00 > fc-list mkftcap > gardump v.in.garmin > gdal_translate d.out.file, r.out.gdal.sh > gdalinfo i.in.spotvgt, r.out.gdal.sh > gdalwarp r.in.aster, r.in.wms > gnuplot i.spectral > gpsbabel v.in.gpsbabel > gpstrans v.in.garmin > ldd v.in.wfs > lynx v.in.wfs > man g.manual > ogrinfo v.in.wfs > perl d.monsize > pngtopnm d.out.gpsdrive > pnmtojpeg d.out.gpsdrive > sqlite3 v.db.join > sync d.out.gpsdrive > unzip r.in.srtm > wget r.in.wms > wms.download r.in.wms > wms.request r.in.wms > xgraph d.polar > xml2 r.in.wms > > BTW, the use of "ldd" by v.in.wfs is entirely bogus: > > # xerces support compiled in? > OGRINFO=`which ogrinfo` > if [ -z "`ldd $OGRINFO | grep xerces`" ] ; then > g.message -e "OGR needs to be compiled with xerces-c support" > exit 1 > fi > > This needs to be changed to something which will work on other > platforms. Does "gdalinfo --formats" suffice? > > Also, we don't really need all three of lynx, wget and curl; any one > of those would suffice. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From grass-dev at grass.itc.it Thu Nov 1 21:55:41 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Thu Nov 1 21:55:45 2007 Subject: [GRASS-dev] [grass-code R][525] v.buffer: switch to disable tolerance WARNING Message-ID: <20071101205541.5E84640417@pyrosoma.intevation.org> code R item #525, was opened at 2007-11-01 21:55 Status: Open Priority: 3 Submitted By: Andras Fabian (alpilotx) Assigned to: Nobody (None) Summary: v.buffer: switch to disable tolerance WARNING Issue status: None GRASS component: None Operating system: None Operating system version: Initial Comment: Hi, I have just experienced, how expensive it can be, to write a WARNING out for every point, when buffering. I try to build simple buffers (only 8 points needed) around a lot of points - in one case 370.000 - and for the reason I choose a high tolerance value (to be sure, it will be reset to the max allowed one). THis works, but takes unbelievably long with all the warnings: "WARNING: The tolerance was reset to ..." Now I have commented out the warning in main.c of v.buffer, and suddenly it is running like mad (30 seconds instead of over 10 minutes). So maybe it would be nice to : - either add another switch to turn off this warning - or include it under the "--quiet" option (NO warning if "--quiet" set). Andras Fabian ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=188&aid=525&group_id=21 From paul-grass at stjohnspoint.co.uk Thu Nov 1 22:28:51 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Nov 1 22:28:53 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: <2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be> References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be> <4721CC87.5010609@club.worldonline.be> <4721E0E0.6080500@ufg.uni-kiel.de> <4721E80B.90606@ufg.uni-kiel.de> <4721EDB9.4090206@ufg.uni-kiel.de> <4721F27F.1030903@club.worldonline.be> <4721F454.9000303@ufg.uni-kiel.de> <472209EC.8040006@ufg.uni-kiel.de> <472212DC.1060503@club.worldonline.be> <4725A9E2.50807@ufg.uni-kiel.de> <4725AD25.3040607@club.worldonline.be> <4725D789.6070305@ufg.uni-kiel.de> <4725DD23.6050209@club.worldonline.be> <4725E2C6.9000408@ufg.uni-kiel.de> <18214.30000.228315.147756@cerise.gclements.plus.com> <4726E54B.7040508@ufg.uni-kiel.de> <18215.6250.408112.551042@cerise.gclements.plus.com> <47272DDF.4010203@ufg.uni-kiel.de> <20071031224813.11476432.hamish_nospam@yahoo.com> <47285231.10209@club.worldonline.be> <47285906.5080602@ufg.uni-kiel.de> <2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be> Message-ID: Hello everyone On Thu, 1 Nov 2007, Moritz Lennert wrote: > On Wed, October 31, 2007 11:29, Benjamin Ducke wrote: >> The start command does actually work to put gis.m in the background. >> I changed init.bat to read: > > I propose to do it in this (slightly modified) way: > > In init.bat: > > === > rem Get LOCATION_NAME to use in prompt > FOR /F "usebackq delims==" %%i IN (`g.gisenv "get=LOCATION_NAME"`) DO @set > LOCATION_NAME=%%i > > cd %HOME% > prompt GRASS %GRASS_VERSION% $C%LOCATION_NAME%$F:$P $G > start "GRASS %GRASS_VERSION% Shell" cmd.exe /E:ON /F:ON /V:ON > > %WINGISBASE%\bin\gis.m.bat > === I'm trying to follow what's going on here but it's bit confusing - would help if somebody posted a diff of the proposed changes to init.bat (the usual way). Have a few comments anyway about my original philosophy of why init.bat does things the way it does, which hopefully might help clarify things. There is not supposed to be a command-prompt running separately from that included in gis.m - I thought we were moving towards the idea of having a command prompt built into the gronsole Window and using that (I think it's improved further in wxgrass) - so that was the point of that. I think it is confusing for new users having to type exit in a command Window to totally exit GRASS as well as just going File-->Exit in the GUI menus (is that what's being proposed here?). If somebody wants a GUI and console then I think it's OK to require them to start GRASS in text mode and run gis.m from the command prompt. So I actually think Moritz's new gis.m.bat is a really good idea. I just was too lazy to get round to implementing that before. And there was some complication about the way the gis.m Shell script was generated although I think I simplified things a little bit. Also I'm not sure what the "cd %HOME%" is for. GRASS on Unix doesn't change the directory you were in before starting it AFAIK - why should it on Windows? And how important is the "/E:ON /F:ON /V:ON"? I just want to be sure we're not introducing anything that doesn't *need* to be there and is only likely to confuse people in years to come. > > where gis.m.bat simply contains: > > === > @ start "GIS Manager" "%GRASS_WISH%" "%WINGISBASE%/etc/gm/gm.tcl" > === > > This way we have a functioning gis.m.bat which one can also launch from > the command line if grass was started with in text mode. That's a good idea. ISTR that the gis.m shell script now also runs gis.m in the background, i.e. you don't need to run it as "gis.m &" any more - is that right? We'd need to make sure GRASS_WISH is always set though. Currently init.bat doesn't require it to be set and will use Window's association of .tcl files with the Tcl interpreter to start gis.m correctly if not. But I don't think it's unreasonable to require GRASS_WISH to always be set and we could change that. > Nice also to finally get rid of this empty and useless cmd.exe window we > had before. Do you mean with the changes the init.bat script is exiting/abandoning after starting gis.m? The whole point of it staying running (and as a side-effect keeping a command prompt Window open - I don't know how to hide that but I presume it's possible) is because there are actions that run as part of exiting GRASS - the main one being deleting temporary files, but also setting the PATH back to its original value if a command-line session was being run. If we exit init.bat after starting gis.m then the temporary files won't be deleted on exit which I don't think is a good idea. > Only thing which is a bit annoying: you have to close the two (cmd and > gis.m) seperately (i.e. gis.m does not close when you type exit in > cmd.exe). But that's minor in my eyes. Users who don't normally use the command line may not know to type exit - I think it's a big enough issue not to introduce it as a problem when it wasn't there before - see my comments above. > One question I don't know how to solve, though: just as for other scripts > a gis.m.bat is created during compilation, which contains: > > @"%GRASS_SH%" -c '"%GISBASE%/scripts/gis.m" %*' > > However, I think that gis.m should run independently of whether someone > has installed a shell, so I'd rather replace this bat file by the one > above. This would mean creating some form of exception for gis.m to the > below entry in include/Make/Script.make: It was my idea for a while (never implemented it though) that the Script Makefile could look and see if there was a "Windows version" (i.e. the script name with a .bat extension) in the same directory, and if so install it rather than installing a wrapper to the Bourne shell version of the script. Would that perhaps be useful here if we got it working? BTW sorry I've been so inactive in the discussions recently. I had very limited internet access for a much longer period than anticipated over the past month and a half, but have a regular connection again so should hopefully be able to contribute a bit more now. Have quite a backlog of other stuff to get through though. Paul From paul-grass at stjohnspoint.co.uk Thu Nov 1 22:32:06 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Nov 1 22:32:08 2007 Subject: [GRASS-dev] Re: projshare path In-Reply-To: <2637.85.10.71.105.1193936288.squirrel@geog-pc40.ulb.ac.be> References: <2637.85.10.71.105.1193936288.squirrel@geog-pc40.ulb.ac.be> Message-ID: On Thu, 1 Nov 2007, Moritz Lennert wrote: > Another issue with paths: > > For configure I have to give the location of the proj share directory in > *nix path form (/c/grass/share/proj/). > > However, this won't work at runtime. So we need to translate PROJSHARE > from one to the other before putting it into init.bat. It might be better for the configure script to accept it in the proper format rather than trying to translate later?? (Would of course also be nice to get rid of the whole dependency on PROJSHARE..) Paul From rez at touchofmadness.com Fri Nov 2 01:07:33 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Nov 2 01:07:38 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <18217.43711.32560.445575@cerise.gclements.plus.com> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <1193906678.2980.140.camel@dev64.localdomain> <18217.43711.32560.445575@cerise.gclements.plus.com> Message-ID: <1193962053.2980.184.camel@dev64.localdomain> On Thu, 2007-11-01 at 10:30 +0000, Glynn Clements wrote: > Brad Douglas wrote: > > > > Let's just all try and put together a complete list of what's > > > needed first, then I'll have a go at it. > > > > I haven't been following the thread, but caught something interesting in > > this message. > > > > It may be overkill, but I'd like to add configure checks for the final > > listing. What we have has served us well, but adding more checks takes > > little time and would help catch portability issues. > > > > Please cc: me on the final list unless someone decides this would be > > more clutter than solution. > > configure is meant for compile-time checks. You can still build GRASS > without the utilities which are used in scripts. Conversely, just > because the utilities are present on the host, it doesn't mean that > they will be present on the target. Why not check and disable parts that do not have the required program(s)? Target<->host isn't a great argument. You can say that with just about anything in configure. In the vast majority of instances, GRASS is packaged. When I build a new RPM spec file, configure.in is very useful in revealing dependencies. -- 73, de Brad KB8UYR/6 From hamish_nospam at yahoo.com Fri Nov 2 01:40:21 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Nov 2 01:40:24 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: Message-ID: <700963.42646.qm@web52705.mail.re2.yahoo.com> Michael Barton wrote: > Most of these shell scripts are not in the menu system because they require > external programs that are not GRASS dependencies. Unless you are planning > for Windows users to run these from the command line, you can eliminate many > of these. Do you have a list of the scripts not included in the menus? They should all fail with a nice error message in the usual way if the required external dependency are missing, so it shouldn't cause any harm to include them. ? Hamish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mlennert at club.worldonline.be Fri Nov 2 01:44:32 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Nov 2 01:49:16 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be> <4721CC87.5010609@club.worldonline.be> <4721E0E0.6080500@ufg.uni-kiel.de> <4721E80B.90606@ufg.uni-kiel.de> <4721EDB9.4090206@ufg.uni-kiel.de> <4721F27F.1030903@club.worldonline.be> <4721F454.9000303@ufg.uni-kiel.de> <472209EC.8040006@ufg.uni-kiel.de> <472212DC.1060503@club.worldonline.be> <4725A9E2.50807@ufg.uni-kiel.de> <4725AD25.3040607@club.worldonline.be> <4725D789.6070305@ufg.uni-kiel.de> <4725DD23.6050209@club.worldonline.be> <4725E2C6.9000408@ufg.uni-kiel.de> <18214.30000.228315.147756@cerise.gclements.plus.com> <4726E54B.7040508@ufg.uni-kiel.de> <18215.6250.408112.551042@cerise.gclements.plus.com> <47272DDF.4010203@ufg.uni-kiel.de> <20071031224813.11476432.hamish_nospam@yahoo.com> <47285231.10209@club.worldonline.be> <47285906.5080602@ufg.uni-kiel.de> <2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be> Message-ID: <3318.85.10.71.105.1193964272.squirrel@geog-pc40.ulb.ac.be> Hello Paul, On Thu, November 1, 2007 22:28, Paul Kelly wrote: > I'm trying to follow what's going on here but it's bit confusing - would > help if somebody posted a diff of the proposed changes to init.bat (the usual way). Yes, sorry. Here it is: --- grasssrc/grass6/lib/init/init.bat Thu Nov 1 22:32:29 2007 +++ init.bat.new Thu Nov 1 22:56:41 2007 @@ -95,13 +95,17 @@ rem This doesn't seem to work; don't understand return codes from gis_set.tcl P K rem if return ok, gis.m start: if %errorlevel% == 2 goto exitinit - -if not "%GRASS_WISH%"=="" ( - "%GRASS_WISH%" "%WINGISBASE%\etc\gm\gm.tcl" -) else ( - "%WINGISBASE%\etc\gm\gm.tcl" -) - + +rem Get LOCATION_NAME to use in prompt +FOR /F "usebackq delims==" %%i IN (`g.gisenv "get=LOCATION_NAME"`) DO @set +LOCATION_NAME=%%i + +cd %HOME% +prompt GRASS %GRASS_VERSION% $C%LOCATION_NAME%$F:$P $G +start "GRASS %GRASS_VERSION% Shell" cmd.exe + +%WINGISBASE%\bin\gis.m.bat + "%WINGISBASE%\etc\clean_temp" > NUL: goto exitinit > Have a few comments anyway about my original philosophy of why > init.bat does things the way it does, which hopefully might help clarify things. > There is not supposed to be a command-prompt running separately from that > included in gis.m - I thought we were moving towards the idea of having a > command prompt built into the gronsole Window and using that (I think it's > improved further in wxgrass) - so that was the point of that. Well, currently the gronsole command prompt is very limited, and so having access to a console still has its advantages. Current feedback from wingrass users shows that there are not only windows users afraid of anything which remotely looks like a command prompt, but also those users who are comfortable with grass on the command line in *nix and would like to (or have to) run grass on a windows machine. From Benjamin's suggestions I also had the feeling that there is a need for the console... But if we decide to leave the console for power users who can find out how to start grass in text mode and, if needed, launch gis.m from there, I'm fine with that as well. A new gis.m.bat as the one I proposed makes this easier. > I think it > is confusing for new users having to type exit in a command Window to totally exit GRASS as well as just going File-->Exit in the GUI menus (is > that what's being proposed here?). It is. This is how it has been for users on other platforms for quite a while. Yes it is a bit confusing, but if we think that having a console is important it might be the lesser of evils. > If somebody wants a GUI and console then I think it's OK to require them to start GRASS in text mode and run gis.m from the command prompt. So I actually think Moritz's new gis.m.bat is a really good idea. +1 Benjamin ? > And there was some > complication about the way the gis.m Shell script was generated although I > think I simplified things a little bit. Currently the gis.m.bat script is created via Script.Make, just as any other script. But it shouldn't as it is a special case where the script does not need sh.exe to be launched. This is why I'm looking for a way to treat gis.m differently from the other scripts. > Also I'm not sure what the "cd %HOME%" is for. GRASS on Unix doesn't change the directory you were in before starting it AFAIK - why should it > on Windows? Because you don't start it from a command line, but by clicking on the grass63.bat file, and so it always starts in c:\grass\bin or wherever the .bat file resides. You can obviously change this behaviour when you make a shortcut which you put on your desktop and in the properties of which you can set a startup directory, but once again we're already at the level of a more advanced user here. To me starting in the %HOME% directory seems the most intuitive in a windows environment. > And how important is the "/E:ON /F:ON /V:ON"? For the record (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true): /e:on : Enables command extensions. [but only for a limited list of commands] /f:on : Enables file and directory name completion. /v:on : Enables delayed environment variable expansion. Probably not important at all and they can always be set by the user if they want to. Actually in XP /E is set on by default AFAICT. > I just want to > be sure we're not introducing anything that doesn't *need* to be there and > is only likely to confuse people in years to come. >> where gis.m.bat simply contains: >> === >> @ start "GIS Manager" "%GRASS_WISH%" "%WINGISBASE%/etc/gm/gm.tcl" === >> This way we have a functioning gis.m.bat which one can also launch from the command line if grass was started with in text mode. > > That's a good idea. ISTR that the gis.m shell script now also runs gis.m in the background, i.e. you don't need to run it as "gis.m &" any more - is that right? This is because in the gis.m script launches gm.tcl with the ampersand: exec "$GRASS_WISH" "$GISBASE/etc/gm/gm.tcl" -name gm_tcl & IIUC, this will not work in windows, however, and so we use the windows specific 'start' command. > > We'd need to make sure GRASS_WISH is always set though. Currently init.bat > doesn't require it to be set and will use Window's association of .tcl files with the Tcl interpreter to start gis.m correctly if not. Are you sure ? In init.bat, we currently have: if "%GRASS_WISH%"=="" set GRASS_WISH=wish.exe So unless someone explicitely unset GRASS_WISH, it will always be set. I've actually tried running gis.m with GRASS_WISH unset and it starts but crashes immediately because of the missing GRASS_WISH. This is probably due to: /c/grass/grass-6.3.cvs/etc/gm$ grep WISH * animate.tcl:# exec $GRASS_WISH "$0" "$@" gmmenu.tcl: {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} tksys.tcl:exec $GRASS_WISH "$0" "$@" > But I > don't think it's unreasonable to require GRASS_WISH to always be set and we could change that. >> Nice also to finally get rid of this empty and useless cmd.exe window we >> had before. > > Do you mean with the changes the init.bat script is exiting/abandoning after starting gis.m? The whole point of it staying running (and as a side-effect keeping a command prompt Window open - I don't know how to hide that but I presume it's possible) is because there are actions that run as part of exiting GRASS - the main one being deleting temporary files, but also setting the PATH back to its original value if a command-line session was being run. If we exit init.bat after starting gis.m then the temporary files won't be deleted on exit which I don't think is a good idea. Yes. I had forgotten about all that. So, we'll have to find another way. Just as a reminder: the problem is that windows automatically opens a cmd.exe window when you launch a .bat file. I think that unless you use some other programming language that calls this .bat file (instead of just clicking on it), this is unavoidable. But it is not so nice to have this "useless" cmd.exe window open all the time. Actually you can hide the window if you use a shortcut to grass63.bat. In its properties you can set it to "minimized". But again, this means more advanced user action than what we seem to aim at. We could maybe include a .lnk file in the distribution for which this is preset. Don't know how portable these binary .lnk files are... One option would be to use the start command in grass63.bat, such as: start /min cmd /c "%WINGISBASE%\etc\init.bat" %* It spawns a new minimized cmd.exe which then runs init.bat. This works great for GUI startup, but when you launch grass63.bat -text, you have the incovenience of a) another cmd window open for grass and b) you have to maximize the window to be able to enter grass. And since the 'text' option can come from the .grassrc6 file, we cannot count on a '-text' parameter being available in grass63.bat. We could have another .bat file which contains the call to gm.tcl and the exit clean up routines and call this .bat file with start /min from Init.bat. However, if you give it a .bat file, start will keep the cmd window open even after the script finishes. This means you have to then maximize the window and close it yourself... So, currently, the only satisfying options I see is to either teach people how to make a shortcut to their desktop (or wherever they want) and to configure this shortcut to minimize the cmd.exe window, or to create some sort of executable (in tcl, python or whatever) that calls grass63.bat. But maybe someone else has a better idea... >> Only thing which is a bit annoying: you have to close the two (cmd and gis.m) seperately (i.e. gis.m does not close when you type exit in cmd.exe). But that's minor in my eyes. > > Users who don't normally use the command line may not know to type exit True. > I think it's a big enough issue not to introduce it as a problem when it > wasn't there before - see my comments above. Ok, won't for now, then. >> One question I don't know how to solve, though: just as for other scripts >> a gis.m.bat is created during compilation, which contains: >> @"%GRASS_SH%" -c '"%GISBASE%/scripts/gis.m" %*' >> However, I think that gis.m should run independently of whether someone has installed a shell, so I'd rather replace this bat file by the one above. This would mean creating some form of exception for gis.m to the below entry in include/Make/Script.make: > > It was my idea for a while (never implemented it though) that the Script Makefile could look and see if there was a "Windows version" (i.e. the script name with a .bat extension) in the same directory, and if so install it rather than installing a wrapper to the Bourne shell version of > the script. Would that perhaps be useful here if we got it working? Yes, definitely. Do I understand correctly that this would mean that instead of running $(BIN)/$(PGM).bat: $(MODULE_TOPDIR)/scripts/windows_launch.bat^M sed -e "s#SCRIPT_NAME#$(PGM)#" $(MODULE_TOPDIR)/scripts/windows_launch.bat > $@ on every script, we only run it for those scripts which do not have an equivalent .bat in the scripts directory ? Currently this would only concern gis.m, but if someone writes a cmd.exe replacement of another script, this would also be included. > but have a regular connection again so should hopefully be able to > contribute a bit more now. Great to have you back ! Moritz From glynn at gclements.plus.com Fri Nov 2 03:12:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 03:12:51 2007 Subject: [GRASS-dev] WinGRASS curses issue In-Reply-To: <1991.85.10.71.105.1193926855.squirrel@geog-pc40.ulb.ac.be> References: <47288243.3080604@ufg.uni-kiel.de> <18216.40712.310855.30515@cerise.gclements.plus.com> <1571.85.10.71.105.1193920121.squirrel@geog-pc40.ulb.ac.be> <1690.85.10.71.105.1193922119.squirrel@geog-pc40.ulb.ac.be> <1991.85.10.71.105.1193926855.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18218.34720.88471.849423@cerise.gclements.plus.com> Moritz Lennert wrote: > I found the problem: > > I don't know why but pushing enter gives a CR (carriage return) the very > first time, but from then on always gives NL (newline). But V_call only > checked for the first. This is supposed to be handled by the nonl() and nl() calls in V_init() and V_exit() respectively. The input loop in V_call() should only ever see CR: The nl and nonl routines control whether the underlying display device translates the return key into newline on input, and whether it trans- lates newline into return and line-feed on output (in either case, the call addch('\n') does the equivalent of return and line feed on the virtual screen). Initially, these translations do occur. If you dis- able them using nonl, curses will be able to make better use of the line-feed capability, resulting in faster cursor motion. Also, curses will then be able to detect the return key. > Fixed in cvs: The fix won't hurt anything. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 2 03:16:42 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 03:16:44 2007 Subject: [GRASS-dev] [grass-code R][525] v.buffer: switch to disable tolerance WARNING In-Reply-To: <20071101205541.5E84640417@pyrosoma.intevation.org> References: <20071101205541.5E84640417@pyrosoma.intevation.org> Message-ID: <18218.34954.96257.790020@cerise.gclements.plus.com> grass-dev@grass.itc.it wrote: > code R item #525, was opened at 2007-11-01 21:55 > Status: Open > Priority: 3 > Submitted By: Andras Fabian (alpilotx) > Assigned to: Nobody (None) > Summary: v.buffer: switch to disable tolerance WARNING > Issue status: None > GRASS component: None > Operating system: None > Operating system version: > > > Initial Comment: > Hi, > > > I have just experienced, how expensive it can be, to write a WARNING > out for every point, when buffering. I try to build simple buffers > (only 8 points needed) around a lot of points - in one case 370.000 - > and for the reason I choose a high tolerance value (to be sure, it > will be reset to the max allowed one). THis works, but takes > unbelievably long with all the warnings: > > "WARNING: The tolerance was reset to ..." > > Now I have commented out the warning in main.c of v.buffer, and > suddenly it is running like mad (30 seconds instead of over 10 > minutes). So maybe it would be nice to : > > - either add another switch to turn off this warning > - or include it under the "--quiet" option (NO warning if "--quiet" set). Another option is to prevent the warning from being issued more than once. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 2 03:21:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 03:21:42 2007 Subject: [GRASS-dev] Re: projshare path In-Reply-To: References: <2637.85.10.71.105.1193936288.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18218.35252.99082.537570@cerise.gclements.plus.com> Paul Kelly wrote: > > Another issue with paths: > > > > For configure I have to give the location of the proj share directory in > > *nix path form (/c/grass/share/proj/). > > > > However, this won't work at runtime. So we need to translate PROJSHARE > > from one to the other before putting it into init.bat. > > It might be better for the configure script to accept it in the proper > format rather than trying to translate later?? Then the configure script has to translate it to MSys' syntax perform the existence checks. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 2 03:32:42 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 03:32:44 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <1193962053.2980.184.camel@dev64.localdomain> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <1193906678.2980.140.camel@dev64.localdomain> <18217.43711.32560.445575@cerise.gclements.plus.com> <1193962053.2980.184.camel@dev64.localdomain> Message-ID: <18218.35914.431616.350205@cerise.gclements.plus.com> Brad Douglas wrote: > > > > Let's just all try and put together a complete list of what's > > > > needed first, then I'll have a go at it. > > > > > > I haven't been following the thread, but caught something interesting in > > > this message. > > > > > > It may be overkill, but I'd like to add configure checks for the final > > > listing. What we have has served us well, but adding more checks takes > > > little time and would help catch portability issues. > > > > > > Please cc: me on the final list unless someone decides this would be > > > more clutter than solution. > > > > configure is meant for compile-time checks. You can still build GRASS > > without the utilities which are used in scripts. Conversely, just > > because the utilities are present on the host, it doesn't mean that > > they will be present on the target. > > Why not check and disable parts that do not have the required > program(s)? There's no need to disable a script just because the host doesn't have the files it uses. The host doesn't need them and the target may well have them. > Target<->host isn't a great argument. You can say that with just about > anything in configure. No; configure checks what is required for building a project. It cannot detect whether you will be able to run it, and doesn't attempt to. > In the vast majority of instances, GRASS is > packaged. When I build a new RPM spec file, configure.in is very useful > in revealing dependencies. You shouldn't be listing every program which some script *might* use as a dependency. The dependencies for a GRASS RPM (etc) should be those packages without which it will be largely unusable (e.g. GDAL, PROJ). It would be quite annoying if you wanted to install it for use in a web application and it insisted upon installing Tcl/Tk, X, OpenGL etc. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 2 03:35:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 03:35:55 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <2111.85.10.71.105.1193928961.squirrel@geog-pc40.ulb.ac.be> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <18217.41963.573310.753044@cerise.gclements.plus.com> <18217.58237.931274.556101@cerise.gclements.plus.com> <2111.85.10.71.105.1193928961.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18218.36104.543742.871503@cerise.gclements.plus.com> Moritz Lennert wrote: > >> 3. Additional utilities: > > > >> perl d.monsize > > > > BTW, this one is rather gratuitous: > > I guess that if this is for a windows distribution, any of the d.* modules > can be left aside, or ? Yes. But requiring perl to strip whitespace from a string is gratuitous for any platform. None of the other installed scripts require perl. g.html2man requires perl, but that's only used at build time, and isn't installed. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 2 03:39:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 03:39:12 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <18217.41963.573310.753044@cerise.gclements.plus.com> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <18217.41963.573310.753044@cerise.gclements.plus.com> Message-ID: <18218.36303.406700.189159@cerise.gclements.plus.com> Glynn Clements wrote: > 3. Additional utilities: > sqlite3 v.db.join This doesn't seem to make sense either. v.db.join doesn't actually use sqlite3 (it uses GRASS DB modules to do all of the work), it just refuses to run if you don't have it. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 2 03:49:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 03:49:07 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: <2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be> References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be> <4721CC87.5010609@club.worldonline.be> <4721E0E0.6080500@ufg.uni-kiel.de> <4721E80B.90606@ufg.uni-kiel.de> <4721EDB9.4090206@ufg.uni-kiel.de> <4721F27F.1030903@club.worldonline.be> <4721F454.9000303@ufg.uni-kiel.de> <472209EC.8040006@ufg.uni-kiel.de> <472212DC.1060503@club.worldonline.be> <4725A9E2.50807@ufg.uni-kiel.de> <4725AD25.3040607@club.worldonline.be> <4725D789.6070305@ufg.uni-kiel.de> <4725DD23.6050209@club.worldonline.be> <4725E2C6.9000408@ufg.uni-kiel.de> <18214.30000.228315.147756@cerise.gclements.plus.com> <4726E54B.7040508@ufg.uni-kiel.de> <18215.6250.408112.551042@cerise.gclements.plus.com> <47272DDF.4010203@ufg.uni-kiel.de> <20071031224813.11476432.hamish_nospam@yahoo.com> <47285231.10209@club.worldonline.be> <47285906.5080602@ufg.uni-kiel.de> <2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18218.36897.248659.839487@cerise.gclements.plus.com> Moritz Lennert wrote: > One question I don't know how to solve, though: just as for other scripts > a gis.m.bat is created during compilation, which contains: > > @"%GRASS_SH%" -c '"%GISBASE%/scripts/gis.m" %*' > > However, I think that gis.m should run independently of whether someone > has installed a shell, so I'd rather replace this bat file by the one > above. This would mean creating some form of exception for gis.m to the > below entry in include/Make/Script.make: > > $(BIN)/$(PGM).bat: $(MODULE_TOPDIR)/scripts/windows_launch.bat^M > sed -e "s#SCRIPT_NAME#$(PGM)#" $(MODULE_TOPDIR)/scripts/windows_launch.bat > $@ > > Is that possible ? Just add a rule for $(BIN)/$(PGM).bat to gis.m/Makefile, e.g.: $(BIN)/$(PGM).bat: $(PGM).bat $(INSTALL_DATA) $< $@ If you have multiple rules for the same target, the dependencies are merged (which, in this case, is harmless), and the commands from the last rule are used, so a rule in the Makefile will override the generic one in the *.make file. -- Glynn Clements From glynn at gclements.plus.com Fri Nov 2 03:58:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 03:58:31 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be> <4721CC87.5010609@club.worldonline.be> <4721E0E0.6080500@ufg.uni-kiel.de> <4721E80B.90606@ufg.uni-kiel.de> <4721EDB9.4090206@ufg.uni-kiel.de> <4721F27F.1030903@club.worldonline.be> <4721F454.9000303@ufg.uni-kiel.de> <472209EC.8040006@ufg.uni-kiel.de> <472212DC.1060503@club.worldonline.be> <4725A9E2.50807@ufg.uni-kiel.de> <4725AD25.3040607@club.worldonline.be> <4725D789.6070305@ufg.uni-kiel.de> <4725DD23.6050209@club.worldonline.be> <4725E2C6.9000408@ufg.uni-kiel.de> <18214.30000.228315.147756@cerise.gclements.plus.com> <4726E54B.7040508@ufg.uni-kiel.de> <18215.6250.408112.551042@cerise.gclements.plus.com> <47272DDF.4010203@ufg.uni-kiel.de> <20071031224813.11476432.hamish_nospam@yahoo.com> <47285231.10209@club.worldonline.be> <47285906.5080602@ufg.uni-kiel.de> <2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be> Message-ID: <18218.37460.394466.588287@cerise.gclements.plus.com> Paul Kelly wrote: > >> The start command does actually work to put gis.m in the background. > >> I changed init.bat to read: > > > > I propose to do it in this (slightly modified) way: > > > > In init.bat: > > > > === > > rem Get LOCATION_NAME to use in prompt > > FOR /F "usebackq delims==" %%i IN (`g.gisenv "get=LOCATION_NAME"`) DO @set > > LOCATION_NAME=%%i > > > > cd %HOME% > > prompt GRASS %GRASS_VERSION% $C%LOCATION_NAME%$F:$P $G > > start "GRASS %GRASS_VERSION% Shell" cmd.exe /E:ON /F:ON /V:ON > > > > %WINGISBASE%\bin\gis.m.bat > > === > > I'm trying to follow what's going on here but it's bit confusing - would > help if somebody posted a diff of the proposed changes to init.bat (the > usual way). Have a few comments anyway about my original philosophy of why > init.bat does things the way it does, which hopefully might help clarify > things. > > There is not supposed to be a command-prompt running separately from that > included in gis.m - I thought we were moving towards the idea of having a > command prompt built into the gronsole Window and using that (I think it's > improved further in wxgrass) - so that was the point of that. I think it > is confusing for new users having to type exit in a command Window to > totally exit GRASS as well as just going File-->Exit in the GUI menus (is > that what's being proposed here?). > > If somebody wants a GUI and console then I think it's OK to require them > to start GRASS in text mode and run gis.m from the command prompt. So I > actually think Moritz's new gis.m.bat is a really good idea. I just was > too lazy to get round to implementing that before. And there was some > complication about the way the gis.m Shell script was generated although I > think I simplified things a little bit. For Windows, we should probably install separate .bat files (and shortcuts on the Start Menu, if possible) for GUI-only, console-only and GUI+console modes. > Also I'm not sure what the "cd %HOME%" is for. GRASS on Unix doesn't > change the directory you were in before starting it AFAIK - why should it > on Windows? Windows users will probably want to start GRASS from a shortcut rather than from a console. By default, the current directory will be the one containing the batch file. We may be able to solve the problem by providing our own shortcuts which start in the user's home directory (I *think* that you can use environment variables in that field). If the user starts GRASS from an existing console, they probably don't want to change the current directory. > > Nice also to finally get rid of this empty and useless cmd.exe window we > > had before. > > Do you mean with the changes the init.bat script is exiting/abandoning > after starting gis.m? The whole point of it staying running (and as a > side-effect keeping a command prompt Window open - I don't know how to > hide that but I presume it's possible) The "start" command has a flag to hide the console window. -- Glynn Clements From c.michael.barton at gmail.com Fri Nov 2 05:38:50 2007 From: c.michael.barton at gmail.com (Michael Barton) Date: Fri Nov 2 05:39:10 2007 Subject: [GRASS-dev] Re: need a truly quiet quiet In-Reply-To: <200711020049.lA20nLYH020297@grass.itc.it> References: <200711020049.lA20nLYH020297@grass.itc.it> Message-ID: On Nov 1, 2007, at 5:49 PM, grass-dev-request@grass.itc.it wrote: > Initial Comment: > Hi, > > I have just experienced, how expensive it can be, to write a > WARNING out for every point, when buffering. I try to build simple > buffers (only 8 points needed) around a lot of points - in one case > 370.000 - and for the reason I choose a high tolerance value (to be > sure, it will be reset to the max allowed one). THis works, but > takes unbelievably long with all the warnings: > "WARNING: The tolerance was reset to ..." > > Now I have commented out the warning in main.c of v.buffer, and > suddenly it is running like mad (30 seconds instead of over 10 > minutes). So maybe it would be nice to : > - either add another switch to turn off this warning > - or include it under the "--quiet" option (NO warning if "--quiet" > set). > > Andras Fabian > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/? > func=detail&atid=188&aid=525&group_id=21 > Andras, I really really agree with you. This has been an endless source of problems for me trying to script a GUI around modules that will not be quiet. Michael ____________________ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071101/bdc0b65a/attachment-0001.html From michael.barton at asu.edu Fri Nov 2 05:58:30 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Nov 2 05:58:55 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: Message-ID: Since I don't use Windows, I can't contribute to most of this, but I'm trying to follow because it's important to have a Windows version available for my students. I have a few GUI-related comments below. On 11/1/07 2:28 PM, "Paul Kelly" wrote: > > I'm trying to follow what's going on here but it's bit confusing - would > help if somebody posted a diff of the proposed changes to init.bat (the > usual way). Have a few comments anyway about my original philosophy of why > init.bat does things the way it does, which hopefully might help clarify > things. > > There is not supposed to be a command-prompt running separately from that > included in gis.m - I thought we were moving towards the idea of having a > command prompt built into the gronsole Window and using that (I think it's > improved further in wxgrass) - so that was the point of that. I think it > is confusing for new users having to type exit in a command Window to > totally exit GRASS as well as just going File-->Exit in the GUI menus (is > that what's being proposed here?). I second this. The command prompt in GRONSOLE works to run all GRASS modules and scripts EXCEPT those that require an interactive (e.g., curses) xterm interface. There aren't many of these left and only some of those will run well in Windows I suspect. It will also run Unix commands (many unavailable in Windows anyway) that don't require an interactive response (e.g., ls, cat, etc). Beyond the interactive part, I'm not sure why some people think it is so limited. It is designed to be a GRASS terminal, not a general purpose, everything Unix terminal. I'd love to have GRASS exit directly from the GUI exit command, or at least have an "exit GUI" and "exit GRASS" entry. But apparently it is not easy to do with the current init.sh. I don't know how to rewrite this to make it possible, though Glynn has offered a few suggestions. > > If somebody wants a GUI and console then I think it's OK to require them > to start GRASS in text mode and run gis.m from the command prompt. So I > actually think Moritz's new gis.m.bat is a really good idea. I just was > too lazy to get round to implementing that before. And there was some > complication about the way the gis.m Shell script was generated although I > think I simplified things a little bit. If we can do this across all platforms, it would be very nice. ... > > That's a good idea. ISTR that the gis.m shell script now also runs gis.m > in the background, i.e. you don't need to run it as "gis.m &" any more - > is that right? Correct. Does this work on Windows though? > ... > >> Only thing which is a bit annoying: you have to close the two (cmd and >> gis.m) seperately (i.e. gis.m does not close when you type exit in >> cmd.exe). But that's minor in my eyes. > > Users who don't normally use the command line may not know to type exit - > I think it's a big enough issue not to introduce it as a problem when it > wasn't there before - see my comments above. I agree. This is a pain for most computer users today. I don't find it a problem, but it makes GRASS look somewhat archaic. 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 Nov 2 06:16:27 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Nov 2 06:16:42 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: <3318.85.10.71.105.1193964272.squirrel@geog-pc40.ulb.ac.be> Message-ID: On 11/1/07 5:44 PM, "Moritz Lennert" wrote: > Well, currently the gronsole command prompt is very limited, Granted, it does not permit query/response or other interactive terminal use. But how is it limited otherwise? > and so having > access to a console still has its advantages. Current feedback from > wingrass users shows that there are not only windows users afraid of > anything which remotely looks like a command prompt, but also those users > who are comfortable with grass on the command line in *nix and would like > to (or have to) run grass on a windows machine. From Benjamin's > suggestions I also had the feeling that there is a need for the console... > > But if we decide to leave the console for power users who can find out how > to start grass in text mode and, if needed, launch gis.m from there, I'm > fine with that as well. A new gis.m.bat as the one I proposed makes this > easier. What about doing this the other way around. That is, when GRASS is launched with -tcltk or -gui, it goes directly to the GUI, instead of launching a terminal first. Then there is a menu item to launch a terminal if a user wants to. 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 Nov 2 06:25:10 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Nov 2 06:25:24 2007 Subject: [GRASS-dev] commands that are TOO quiet Message-ID: I bet you never thought you'd hear this from me. Working with a student in the vector network modules, it seems that these are too quiet, even if the --q switch is NOT enabled. If v.net.salesman and v.net.steiner have improper parameters set or do not have a proper file to work with, they appear to run and produce an output, but nothing is ever created. They just fail VERY quietly. There is no message that they cannot find any valid nodes or that a vector file was not created. Nothing. Also, both tend to regularly crash the GUI for some reason. Probably something to do with progress output, but I'm not sure. Sometimes when they crash, they do produce output (if they have been given proper parameters) and other times they do 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071101/57001f44/attachment.html From glynn at gclements.plus.com Fri Nov 2 08:04:22 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 08:04:26 2007 Subject: [GRASS-dev] Re: need a truly quiet quiet In-Reply-To: References: <200711020049.lA20nLYH020297@grass.itc.it> Message-ID: <18218.52214.24285.761270@cerise.gclements.plus.com> Michael Barton wrote: > > I have just experienced, how expensive it can be, to write a > > WARNING out for every point, when buffering. I try to build simple > > buffers (only 8 points needed) around a lot of points - in one case > > 370.000 - and for the reason I choose a high tolerance value (to be > > sure, it will be reset to the max allowed one). THis works, but > > takes unbelievably long with all the warnings: > > "WARNING: The tolerance was reset to ..." > > > > Now I have commented out the warning in main.c of v.buffer, and > > suddenly it is running like mad (30 seconds instead of over 10 > > minutes). So maybe it would be nice to : > > - either add another switch to turn off this warning > > - or include it under the "--quiet" option (NO warning if "--quiet" > > set). > > I really really agree with you. This has been an endless source of > problems for me trying to script a GUI around modules that will not > be quiet. With the exception of Tcl's exec and open| treating stderr output as an error, scripts shouldn't care whether modules are writing anything to stderr. If a script has problems with modules writing to stderr, that's the fault of the script, not the module. -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Fri Nov 2 09:15:03 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Nov 2 09:16:02 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: References: Message-ID: <472ADC87.9020408@ufg.uni-kiel.de> > > Correct. Does this work on Windows though? Yes. > > ... >>> Only thing which is a bit annoying: you have to close the two (cmd and >>> gis.m) seperately (i.e. gis.m does not close when you type exit in >>> cmd.exe). But that's minor in my eyes. >> Users who don't normally use the command line may not know to type exit - >> I think it's a big enough issue not to introduce it as a problem when it >> wasn't there before - see my comments above. > > I agree. This is a pain for most computer users today. I don't find it a > problem, but it makes GRASS look somewhat archaic. > How about adding an entry "Start GRASS Shell" to the Tcl/Tk menus? This way, we could do without starting a shell by default from Init.bat and users can launch as many as they need. We may assume that someone who intentionally launches a shell to do some work also has the wits to close it afterwards (which can be done by simply clicking the little "x" on the window). Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From wolf+grass at bergenheim.net Fri Nov 2 10:55:51 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Fri Nov 2 10:56:25 2007 Subject: [GRASS-dev] SoC projects to trunk Message-ID: <472AF427.3050701@bergenheim.net> Hi list, I have now brought the two SoC modules (v.generalize and v.net.visibility) to the CVS trunk. I would appreciate it very much if someone could check the code once again :) just to make sure it is suitably stable. I would also love it if someone could help me add these new modules to the gui. v.net.visibility should probably go next to the other v.net.* modules, but what about generalize? Should it go under Develop map? I'll look into how to add these there myself, but any hints are appreciated. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From benjamin.ducke at ufg.uni-kiel.de Fri Nov 2 12:37:54 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Nov 2 12:38:51 2007 Subject: [GRASS-dev] SoC projects to trunk In-Reply-To: <472AF427.3050701@bergenheim.net> References: <472AF427.3050701@bergenheim.net> Message-ID: <472B0C12.4080105@ufg.uni-kiel.de> For gis.m, look into: GRASSBASE/etc/gm/gmmenu.tcl. Just copy a menu entry and work from there. I am sure you will find it easy enough to understand the syntax. One hint: be careful to get closing ] brackets right. Benjamin Wolf Bergenheim wrote: > Hi list, > > I have now brought the two SoC modules (v.generalize and > v.net.visibility) to the CVS trunk. I would appreciate it very much if > someone could check the code once again :) just to make sure it is > suitably stable. > > I would also love it if someone could help me add these new modules to > the gui. v.net.visibility should probably go next to the other v.net.* > modules, but what about generalize? Should it go under Develop map? > > I'll look into how to add these there myself, but any hints are appreciated. > > --Wolf > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From wolf+grass at bergenheim.net Fri Nov 2 12:48:19 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Fri Nov 2 12:48:52 2007 Subject: [GRASS-dev] SoC projects to trunk In-Reply-To: <472B0C12.4080105@ufg.uni-kiel.de> References: <472AF427.3050701@bergenheim.net> <472B0C12.4080105@ufg.uni-kiel.de> Message-ID: <472B0E83.4080402@bergenheim.net> On 02.11.2007 13:37, Benjamin Ducke wrote: > For gis.m, look into: > > GRASSBASE/etc/gm/gmmenu.tcl. > > Just copy a menu entry and work from there. I am sure you > will find it easy enough to understand the syntax. > One hint: be careful to get closing ] brackets right. Brilliant! Thanks Benjamin! It works like a charm. Committed to trunk. Now is someone could merge these changes to the 6.3 branch I'd be a very happy camper! --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From neteler at fbk.eu Fri Nov 2 13:16:19 2007 From: neteler at fbk.eu (Markus Neteler) Date: Fri Nov 2 13:16:21 2007 Subject: [GRASS-dev] SoC projects to trunk In-Reply-To: <472B0E83.4080402@bergenheim.net> References: <472AF427.3050701@bergenheim.net> <472B0C12.4080105@ufg.uni-kiel.de> <472B0E83.4080402@bergenheim.net> Message-ID: <20071102121619.GA22676@fbk.eu> On Fri, Nov 02, 2007 at 12:48:19PM +0100, Wolf Bergenheim wrote: > On 02.11.2007 13:37, Benjamin Ducke wrote: > > For gis.m, look into: > > > > GRASSBASE/etc/gm/gmmenu.tcl. > > > > Just copy a menu entry and work from there. I am sure you > > will find it easy enough to understand the syntax. > > One hint: be careful to get closing ] brackets right. > > Brilliant! Thanks Benjamin! It works like a charm. Committed to trunk. > > Now is someone could merge these changes to the 6.3 branch I'd be a very > happy camper! Done so (including Makefile fix). Time to get out 6.3.0RC2! Markus From wolf+grass at bergenheim.net Fri Nov 2 13:24:49 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Fri Nov 2 13:25:22 2007 Subject: [GRASS-dev] SoC projects to trunk In-Reply-To: <20071102121619.GA22676@fbk.eu> References: <472AF427.3050701@bergenheim.net> <472B0C12.4080105@ufg.uni-kiel.de> <472B0E83.4080402@bergenheim.net> <20071102121619.GA22676@fbk.eu> Message-ID: <472B1711.6030308@bergenheim.net> On 02.11.2007 14:16, Markus Neteler wrote: > Done so (including Makefile fix). > Yay! Thanks for that! --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From maris.gis at gmail.com Fri Nov 2 13:43:05 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Fri Nov 2 13:43:09 2007 Subject: [GRASS-dev] SoC projects to trunk In-Reply-To: <20071102121619.GA22676@fbk.eu> References: <472AF427.3050701@bergenheim.net> <472B0C12.4080105@ufg.uni-kiel.de> <472B0E83.4080402@bergenheim.net> <20071102121619.GA22676@fbk.eu> Message-ID: <2b3d8c1c0711020543v41bf3782v21e13d07a2511599@mail.gmail.com> Hi all! Before Markus releases 6.3.0RC2, would it be possible to include a small usability fix: [#521] Provide interactive environment on startup [1] - there has been no negative feedback about this fix (anyone willing something to say?). I'm currently also looking into Glynns objections on patch #515. Maris. 1. http://wald.intevation.org/tracker/index.php?func=detail&aid=521&group_id=21&atid=205 2007/11/2, Markus Neteler : > On Fri, Nov 02, 2007 at 12:48:19PM +0100, Wolf Bergenheim wrote: > > On 02.11.2007 13:37, Benjamin Ducke wrote: > > > For gis.m, look into: > > > > > > GRASSBASE/etc/gm/gmmenu.tcl. > > > > > > Just copy a menu entry and work from there. I am sure you > > > will find it easy enough to understand the syntax. > > > One hint: be careful to get closing ] brackets right. > > > > Brilliant! Thanks Benjamin! It works like a charm. Committed to trunk. > > > > Now is someone could merge these changes to the 6.3 branch I'd be a very > > happy camper! > > Done so (including Makefile fix). > > Time to get out 6.3.0RC2! > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From rez at touchofmadness.com Fri Nov 2 15:18:28 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Nov 2 15:18:39 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <18218.35914.431616.350205@cerise.gclements.plus.com> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <1193906678.2980.140.camel@dev64.localdomain> <18217.43711.32560.445575@cerise.gclements.plus.com> <1193962053.2980.184.camel@dev64.localdomain> <18218.35914.431616.350205@cerise.gclements.plus.com> Message-ID: <1194013108.4035.45.camel@dev64.localdomain> On Fri, 2007-11-02 at 02:32 +0000, Glynn Clements wrote: > Brad Douglas wrote: > > > > > > Let's just all try and put together a complete list of what's > > > > > needed first, then I'll have a go at it. > > > > > > > > I haven't been following the thread, but caught something interesting in > > > > this message. > > > > > > > > It may be overkill, but I'd like to add configure checks for the final > > > > listing. What we have has served us well, but adding more checks takes > > > > little time and would help catch portability issues. > > > > > > > > Please cc: me on the final list unless someone decides this would be > > > > more clutter than solution. > > > > > > configure is meant for compile-time checks. You can still build GRASS > > > without the utilities which are used in scripts. Conversely, just > > > because the utilities are present on the host, it doesn't mean that > > > they will be present on the target. > > > > Why not check and disable parts that do not have the required > > program(s)? > > There's no need to disable a script just because the host doesn't have > the files it uses. The host doesn't need them and the target may well > have them. I disagree only because most scripts do not exit informatively enough for users to discover and correct the problem. > > Target<->host isn't a great argument. You can say that with just about > > anything in configure. > > No; configure checks what is required for building a project. It > cannot detect whether you will be able to run it, and doesn't attempt > to. True, but there's no rule against it and I've seen other projects do it. > > In the vast majority of instances, GRASS is > > packaged. When I build a new RPM spec file, configure.in is very useful > > in revealing dependencies. > > You shouldn't be listing every program which some script *might* use > as a dependency. > > The dependencies for a GRASS RPM (etc) should be those packages > without which it will be largely unusable (e.g. GDAL, PROJ). It would > be quite annoying if you wanted to install it for use in a web > application and it insisted upon installing Tcl/Tk, X, OpenGL etc. Again, I disagree. I think you're underestimating the stupidity of humans. If someone needs it for a specific application, then they should build it themselves. I used to get quite a few emails until I significantly tightened up the dependencies. I now get 0 other than the occasional query about why GRASS has so many dependencies, which is why I now build two versions. However, I have no problem so long as you're nominating yourself to deal with every user that reports problems that are caused by missing programs. ;-) (Not terribly frequent, but frequent enough for me) As a compromise, how about just putting that list on the wiki or in grass6/rpm to make it easier for packagers to build dependencies (in the interest of quelling some of the non-problem reports)? -- 73, de Brad KB8UYR/6 From glynn at gclements.plus.com Fri Nov 2 18:00:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Nov 2 18:00:38 2007 Subject: [GRASS-dev] Wingrass and TclTk In-Reply-To: <1194013108.4035.45.camel@dev64.localdomain> References: <194309.10140.qm@web52708.mail.re2.yahoo.com> <472991EA.1020002@ufg.uni-kiel.de> <1193906678.2980.140.camel@dev64.localdomain> <18217.43711.32560.445575@cerise.gclements.plus.com> <1193962053.2980.184.camel@dev64.localdomain> <18218.35914.431616.350205@cerise.gclements.plus.com> <1194013108.4035.45.camel@dev64.localdomain> Message-ID: <18219.22450.737020.155227@cerise.gclements.plus.com> Brad Douglas wrote: > > > Why not check and disable parts that do not have the required > > > program(s)? > > > > There's no need to disable a script just because the host doesn't have > > the files it uses. The host doesn't need them and the target may well > > have them. > > I disagree only because most scripts do not exit informatively enough > for users to discover and correct the problem. If the user doesn't have the program, the fact that it exists on the build system doesn't mean anything. Conversely, there's no need for someone building GRASS to track down and install programs which aren't required for building it (I'm missing several of the less common programs used by the scripts, but that hasn't stopped me from building Cygwin packages which include all of the scripts). Also, many scripts explicitly check for any uncommon utilities which they use. If they don't, the shell will generate a "command not found" error for any missing program. > > > Target<->host isn't a great argument. You can say that with just about > > > anything in configure. > > > > No; configure checks what is required for building a project. It > > cannot detect whether you will be able to run it, and doesn't attempt > > to. > > True, but there's no rule against it and I've seen other projects do it. I've seen other projects do plenty of things which I wouldn't recommend. > > > In the vast majority of instances, GRASS is > > > packaged. When I build a new RPM spec file, configure.in is very useful > > > in revealing dependencies. > > > > You shouldn't be listing every program which some script *might* use > > as a dependency. > > > > The dependencies for a GRASS RPM (etc) should be those packages > > without which it will be largely unusable (e.g. GDAL, PROJ). It would > > be quite annoying if you wanted to install it for use in a web > > application and it insisted upon installing Tcl/Tk, X, OpenGL etc. > > Again, I disagree. I think you're underestimating the stupidity of > humans. If someone needs it for a specific application, then they > should build it themselves. I used to get quite a few emails until I > significantly tightened up the dependencies. I now get 0 other than the > occasional query about why GRASS has so many dependencies, which is why > I now build two versions. It's quite common for systems with many components to be split into multiple packages, typically a "core" package and collection of add-ons. E.g. the gcc source is a single tar file, but distributions often provide a separate package for each language. If anything warrants that kind of treatment, GRASS certainly does. Even if you use all of the 23 different --without-* switches, you still get most of GRASS. > However, I have no problem so long as you're nominating yourself to deal > with every user that reports problems that are caused by missing > programs. ;-) (Not terribly frequent, but frequent enough for me) > > As a compromise, how about just putting that list on the wiki or in > grass6/rpm to make it easier for packagers to build dependencies (in the > interest of quelling some of the non-problem reports)? I don't see any problem putting it on the Wiki, as long as it's understood that the list will probably never be complete. New dependencies are likely to be added as fast as people find the existing ones. -- Glynn Clements From woklist at kyngchaos.com Sat Nov 3 02:11:12 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Nov 3 02:11:31 2007 Subject: [GRASS-dev] r.li lib name Message-ID: Building CVS today (last build a couple weeks ago). I'm getting a liblibr_li. I remember this from quite a while ago, but I thought it was fixed (ie renamed). I could also have just forgotten about it and noticed again just now. ----- William Kyngesburye http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. From glynn at gclements.plus.com Sat Nov 3 04:50:41 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Nov 3 04:50:44 2007 Subject: [GRASS-dev] r.li lib name In-Reply-To: References: Message-ID: <18219.61457.985434.435281@cerise.gclements.plus.com> William Kyngesburye wrote: > Building CVS today (last build a couple weeks ago). I'm getting a > liblibr_li. I remember this from quite a while ago, but I thought it > was fixed (ie renamed). I could also have just forgotten about it and > noticed again just now. It hasn't changed since: revision 1.2 date: 2006/11/21 22:41:06; author: markus; state: Exp; lines: +8 -13 Serena Pallecchi/Faunalia: various fixes; r.li lib now shared lib -- Glynn Clements From woklist at kyngchaos.com Sat Nov 3 05:50:15 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Nov 3 05:50:35 2007 Subject: [GRASS-dev] r.li lib name In-Reply-To: <18219.61457.985434.435281@cerise.gclements.plus.com> References: <18219.61457.985434.435281@cerise.gclements.plus.com> Message-ID: <01E5DEE6-BA78-467B-870C-35797A055294@kyngchaos.com> I saw that. I found this - I guess I did mention it last Dec, but nothing was done: http://grass.itc.it/pipermail/grass-dev/2006-December/028101.html Time to hit the bug tracker, I guess. Along with that other endian issue I mentioned there. On Nov 2, 2007, at 10:50 PM, Glynn Clements wrote: > > William Kyngesburye wrote: > >> Building CVS today (last build a couple weeks ago). I'm getting a >> liblibr_li. I remember this from quite a while ago, but I thought it >> was fixed (ie renamed). I could also have just forgotten about it >> and >> noticed again just now. > > It hasn't changed since: > > revision 1.2 > date: 2006/11/21 22:41:06; author: markus; state: Exp; lines: +8 > -13 > Serena Pallecchi/Faunalia: various fixes; r.li lib now shared lib > > -- > Glynn Clements ----- 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 neteler at fbk.eu Sat Nov 3 11:35:18 2007 From: neteler at fbk.eu (Markus Neteler) Date: Sat Nov 3 11:35:22 2007 Subject: [GRASS-dev] r.li lib name In-Reply-To: <18219.61457.985434.435281@cerise.gclements.plus.com> References: <18219.61457.985434.435281@cerise.gclements.plus.com> Message-ID: <13561661.post@talk.nabble.com> Glynn Clements wrote: > > William Kyngesburye wrote: >> Building CVS today (last build a couple weeks ago). I'm getting a >> liblibr_li. I remember this from quite a while ago, but I thought it >> was fixed (ie renamed). I could also have just forgotten about it and >> noticed again just now. > > It hasn't changed since: > > revision 1.2 > date: 2006/11/21 22:41:06; author: markus; state: Exp; lines: +8 -13 > Serena Pallecchi/Faunalia: various fixes; r.li lib now shared lib > In general, if such thing is known and easy to fix and original author absent, why not just fixing it rather than populating bug tracker and mailing list? Or is it complicated? Markus -- View this message in context: http://www.nabble.com/r.li-lib-name-tf4741579.html#a13561661 Sent from the Grass - Dev mailing list archive at Nabble.com. From grass-dev at grass.itc.it Sat Nov 3 18:07:02 2007 From: grass-dev at grass.itc.it (grass-dev@grass.itc.it) Date: Sat Nov 3 18:07:05 2007 Subject: [GRASS-dev] [grass-code P][526] Provide option to end GRASS session from gis.m Message-ID: <20071103170702.0F5694041B@pyrosoma.intevation.org> code P item #526, was opened at 2007-11-03 19:07 Status: Open Priority: 3 Submitted By: M?ris Narti?s (marisn) Assigned to: Nobody (None) Summary: Provide option to end GRASS session from gis.m Patch status: None Patch type: enhancement GRASS component: startup GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: This patch adds "EXIT GRASS" to gis.m menu. GRASS CLI exit is done by sending SIGINT to GRASS shell. Shell's pid is provided by GRASS_SHELL_PID env variable. Works and is tested on bash. tcsh/csh requires a small change (I don't have tcsh to make tests how onint works). May also work with ksh. Will NOT work with rc. This implementation also includes code from patch #515. How it works (in bash): GRASS_SHELL_PID is set from .bashrc on GRASS shell startup; gis.m is also launched from .bashrc and NOT from init.sh; gis.m "EXIT GRASS" calls Gm::quit true to indicate full exit; Gm::quit checks GRASS_SHELL_PID presence and sends SIGINT; GRASS shell traps SIGINT signal and issues exit from GRASS shell; init.sh cleans up any open gis.m instances et.al. To add other shell support, shell must provide a way: 1) how to get process PID (echo $$); 2) how to trap SIGINT (trap "exit" SIGINT); 3) how to launch gis.m after shell startup from init.sh (.bashrc); 4) how to send signal to other process. This code may require aditional tweaks before can be commited. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=526&group_id=21 From mlennert at club.worldonline.be Sat Nov 3 20:11:49 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sat Nov 3 20:04:58 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: References: Message-ID: <472CC7F5.3050506@club.worldonline.be> Michael Barton wrote: > The command prompt in GRONSOLE works to run all GRASS modules and scripts > EXCEPT those that require an interactive (e.g., curses) xterm interface. > There aren't many of these left and only some of those will run well in > Windows I suspect. It will also run Unix commands (many unavailable in > Windows anyway) that don't require an interactive response (e.g., ls, cat, > etc). Beyond the interactive part, I'm not sure why some people think it is > so limited. It is designed to be a GRASS terminal, not a general purpose, > everything Unix terminal. The enourmous advantage of using the command line for grass is the almost unlimited capacity to mix grass commands with others or just to be able to combine different grass commands. The scripts in the scripts directory are a perfect example of such combination. I know I can use the gronsole prompt to type in grass commands, but this is only a very small part of the added value of the command line. I know I can use some other shell commands on the gronsole, but it's not easy to combine them into scripts and ISTR that the commands you can use are limited (e.g. can you run a 'for * in g.mlist' type of loop ?). AFAICT, windows commands do not work at all. So, at this stage, I don't think that the gronsole prompt can replace a command line. The question, therefore, is, whether we think that most windows users should have access to a command line by default, or whether this is confusing to most and thus should be left to those who feel comfortable launching grass directly from a cmd.exe window with the -text option (or modify their .grasssrc6 file by hand). Moritz From michael.barton at asu.edu Sat Nov 3 20:48:23 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Nov 3 20:48:34 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: <472CC7F5.3050506@club.worldonline.be> Message-ID: On 11/3/07 12:11 PM, "Moritz Lennert" wrote: > Michael Barton wrote: > >> The command prompt in GRONSOLE works to run all GRASS modules and scripts >> EXCEPT those that require an interactive (e.g., curses) xterm interface. >> There aren't many of these left and only some of those will run well in >> Windows I suspect. It will also run Unix commands (many unavailable in >> Windows anyway) that don't require an interactive response (e.g., ls, cat, >> etc). Beyond the interactive part, I'm not sure why some people think it is >> so limited. It is designed to be a GRASS terminal, not a general purpose, >> everything Unix terminal. > > The enourmous advantage of using the command line for grass is the > almost unlimited capacity to mix grass commands with others or just to > be able to combine different grass commands. The scripts in the scripts > directory are a perfect example of such combination. You can combine GRASS commands with any other kind of command in the GRONSOLE command line. All it does is pass whatever you type to the shell. > > I know I can use the gronsole prompt to type in grass commands, but this > is only a very small part of the added value of the command line. I know > I can use some other shell commands on the gronsole, but it's not easy > to combine them into scripts and ISTR that the commands you can use are > limited (e.g. can you run a 'for * in g.mlist' type of loop ?). Maybe I don't quite understand. But you can write a script of any kind recognized by the shell and run it from the GRONSOLE command line. For example, I just wrote a small Python script called test.py x=1+2 print x >From the GRONSOLE command line, 'python test.py' returns 3 in the output window. You can't do something interactive, however. That is, you can't type 'python' and then treat the GRONSOLE as an interactive Python terminal. > > AFAICT, windows commands do not work at all. If they work from GRASS command line (i.e., whatever shell you have), they will work from GRONSOLE. If they don't work from the GRASS command line they probably won't work. > > So, at this stage, I don't think that the gronsole prompt can replace a > command line. It cannot replace it for everything. AFAICT, it works fine for every command EXECPT those that require some kind of interaction. > > The question, therefore, is, whether we think that most windows users > should have access to a command line by default, or whether this is > confusing to most and thus should be left to those who feel comfortable > launching grass directly from a cmd.exe window with the -text option (or > modify their .grasssrc6 file by hand). I guess, my thought is the same as Benjamin's. Why not make it an optional item from the menu? Why not do this for all of GRASS? We could make it a cmd-key combinations (cmd-t maybe) if people want so that it's easy to launch. Or make an init.sh startup flag (e.g. -guiterm) so that people who always want to terminal can have one automatically launch. Michael > > Moritz __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sun Nov 4 10:35:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Nov 4 10:35:43 2007 Subject: [GRASS-dev] r.li lib name In-Reply-To: <13561661.post@talk.nabble.com> References: <18219.61457.985434.435281@cerise.gclements.plus.com> <13561661.post@talk.nabble.com> Message-ID: <18221.37483.518611.843628@cerise.gclements.plus.com> Markus Neteler wrote: > >> Building CVS today (last build a couple weeks ago). I'm getting a > >> liblibr_li. I remember this from quite a while ago, but I thought it > >> was fixed (ie renamed). I could also have just forgotten about it and > >> noticed again just now. > > > > It hasn't changed since: > > > > revision 1.2 > > date: 2006/11/21 22:41:06; author: markus; state: Exp; lines: +8 -13 > > Serena Pallecchi/Faunalia: various fixes; r.li lib now shared lib > > > > In general, if such thing is known and easy to fix and original author > absent, why not just fixing it rather than populating bug tracker and > mailing list? Or is it complicated? Because different people have different ideas regarding what is or is not a bug. None of the things mentioned in the bug tracker entry are unambiguous bugs or have an obvious unique "solution". -- Glynn Clements From glynn at gclements.plus.com Sun Nov 4 10:45:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Nov 4 10:45:24 2007 Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk] In-Reply-To: <472CC7F5.3050506@club.worldonline.be> References: <472CC7F5.3050506@club.worldonline.be> Message-ID: <18221.38062.83420.836999@cerise.gclements.plus.com> Moritz Lennert wrote: > > The command prompt in GRONSOLE works to run all GRASS modules and scripts > > EXCEPT those that require an interactive (e.g., curses) xterm interface. > > There aren't many of these left and only some of those will run well in > > Windows I suspect. It will also run Unix commands (many unavailable in > > Windows anyway) that don't require an interactive response (e.g., ls, cat, > > etc). Beyond the interactive part, I'm not sure why some people think it is > > so limited. It is designed to be a GRASS terminal, not a general purpose, > > everything Unix terminal. > > The enourmous advantage of using the command line for grass is the > almost unlimited capacity to mix grass commands with others or just to > be able to combine different grass commands. The scripts in the scripts > directory are a perfect example of such combination. > > I know I can use the gronsole prompt to type in grass commands, but this > is only a very small part of the added value of the command line. I know > I can use some other shell commands on the gronsole, but it's not easy > to combine them into scripts and ISTR that the commands you can use are > limited (e.g. can you run a 'for * in g.mlist' type of loop ?). Those commands aren't run via a shell, so you can't use any shell built-ins or syntax, unless you explicitly run "sh -c ...". Even then, each command is run as a separate child process, so there's no persistence of state between them. -- Glynn Clements From tutey at o2.pl Sun Nov 4 16:36:34 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Nov 4 15:36:48 2007 Subject: [GRASS-dev] Re: [GRASS-user] Intersections on World Map In-Reply-To: References: Message-ID: <472DE702.8030909@o2.pl> Martin Bley wrote: > I still get stucked on an issue using v.overlay. I > imported a shapefile with the world continents (the one > from ESRI). Projection is Lat-Long. > > VERTI L 2 1 -180 -80 180 -80 1 1 > > Now I use the following command to merge the intersection > between the latitude (80 South) and the areas in the > world continents vector. > > v.overlay ainput=$vector atype=line alayer=1 binput=World > btype=area \ blayer=1 output=$out operator=and > > Works pretty well so far, until I reach latitude South > 75+. Intersections doesn't match continents anymore > (please see attached PNG file). > > I would appreciate any hint. Hi There is a known bug/feature in v.overlay in lat/long locations [1]. I can't say if it has the same background as your issue. It might. Letting you know just in case. http://wald.intevation.org/tracker/?func=detail&atid=204&aid=452&group_id=21 Maciek From c.michael.barton at gmail.com Sun Nov 4 19:47:26 2007 From: c.michael.barton at gmail.com (Michael Barton) Date: Sun Nov 4 19:47:45 2007 Subject: [GRASS-dev] Call for documentation help Message-ID: <472E13BE.80009@asu.edu> The GRASS team needs your help. As you all are well aware, GRASS is enormously sophisticated spatial analysis sophisticated. This also makes it equally complicated and sometimes baffling for users, with over 300 individual modules. GRASS has a top notch integrated and contextual help system. BUT we need help in making the most of the help system. As with all open source software, the development team is a group of dedicated volunteers who work hard (in addition to their regular jobs) to create the first rate software that you all use. They are also very responsible in trying to document the program modules they code and maintain. This is where your help is needed. In spite of best intentions and efforts, development team members with coding skills need to put most of their always limited time into writing and maintaining the code that makes GRASS such a powerful and versatile software package. Many of you in the GRASS community are expert users even if you do not have expertise in programming. It is also clear from the traffic on this list that you are regularly willing to share your expertise with others by answering questions. Would some of you be willing to join the development team to help manage and improve the GRASS documentation and help system? You don't need to be proficient at programming, and because this is a team effort, you don't even need to know all parts of GRASS. What is needed is sufficient knowledge of some GRASS modules to help improve and maintain their documentation pages, a little bit of html (the help pages are in very basic html), and a desire to work cooperatively to improve GRASS. Here is a partial list of roles that are needed. Individual module management: -Add or improve examples. Examples of how to use a module to get different results is very helpful -Add or improve example graphic in modules. Screen shots are often worth many words -Improve and enrich descriptions in English. In many cases, documentation was written by valiant souls for whom English is a 2nd (or 3rd or 4th) language. Native speakers are needed to enrich these descriptions. -Add or improve non-English versions of the documentation. GRASS is trying hard to be international and is used around the world. Much of the operational language of the modules have been translated to other languages (though a lot more help is needed in this too). Help and doc pages in other languages would make GRASS much more usable globally. Overall: -Documentation management. Someone or ones to mangage a team of documentation helpers, ID holes and weak spots in the documentation, coordinate with the coding team, and think about documentation standards. If you are interested and willing to contribute a small part of your time to help others use GRASS, please respond to the GRASS Developer list and copy the GRASS project team leader, Markus Neteler Michael -- Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 WWW: http://www.public.asu.edu/~cmbarton From dca.gis at gmail.com Sun Nov 4 21:13:19 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Sun Nov 4 21:13:24 2007 Subject: [GRASS-dev] Call for documentation help In-Reply-To: <472E13BE.80009@asu.edu> References: <472E13BE.80009@asu.edu> Message-ID: <1a486f560711041213q45b11c53i35638010a2df9095@mail.gmail.com> I would add, wrt examples, "try to build working examples using the demo data available" (spearfish, IMO; we should think about the new demo for 7.0). We should probably use a system not unlike R's demo() command or python's doctests, where the code examples within the docs may be extracted and executed. This might also be merged into the regression testing system. Daniel. On 11/4/07, Michael Barton wrote: > > The GRASS team needs your help. As you all are well aware, GRASS is > enormously sophisticated spatial analysis sophisticated. This also makes > it equally complicated and sometimes baffling for users, with over 300 > individual modules. GRASS has a top notch integrated and contextual help > system. BUT we need help in making the most of the help system. > > As with all open source software, the development team is a group of > dedicated volunteers who work hard (in addition to their regular jobs) > to create the first rate software that you all use. They are also very > responsible in trying to document the program modules they code and > maintain. > > This is where your help is needed. In spite of best intentions and > efforts, development team members with coding skills need to put most of > their always limited time into writing and maintaining the code that > makes GRASS such a powerful and versatile software package. Many of you > in the GRASS community are expert users even if you do not have > expertise in programming. It is also clear from the traffic on this list > that you are regularly willing to share your expertise with others by > answering questions. > > Would some of you be willing to join the development team to help manage > and improve the GRASS documentation and help system? You don't need to > be proficient at programming, and because this is a team effort, you > don't even need to know all parts of GRASS. What is needed is sufficient > knowledge of some GRASS modules to help improve and maintain their > documentation pages, a little bit of html (the help pages are in very > basic html), and a desire to work cooperatively to improve GRASS. Here > is a partial list of roles that are needed. > > Individual module management: > -Add or improve examples. Examples of how to use a module to get > different results is very helpful > -Add or improve example graphic in modules. Screen shots are often worth > many words > -Improve and enrich descriptions in English. In many cases, > documentation was written by valiant souls for whom English is a 2nd (or > 3rd or 4th) language. Native speakers are needed to enrich these > descriptions. > -Add or improve non-English versions of the documentation. GRASS is > trying hard to be international and is used around the world. Much of > the operational language of the modules have been translated to other > languages (though a lot more help is needed in this too). Help and doc > pages in other languages would make GRASS much more usable globally. > > Overall: > -Documentation management. Someone or ones to mangage a team of > documentation helpers, ID holes and weak spots in the documentation, > coordinate with the coding team, and think about documentation standards. > > If you are interested and willing to contribute a small part of your > time to help others use GRASS, please respond to the GRASS Developer > list and copy the GRASS project team leader, > Markus Neteler > > Michael > > -- > > Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > Phone: 480-965-6262 > Fax: 480-965-7671 > WWW: http://www.public.asu.edu/~cmbarton > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- -- Daniel Calvelo Aros -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071104/59c69e52/attachment-0001.html From c.michael.barton at gmail.com Mon Nov 5 01:01:04 2007 From: c.michael.barton at gmail.com (Michael Barton) Date: Mon Nov 5 01:01:22 2007 Subject: [GRASS-dev] Re: GRASS documentation In-Reply-To: <472E3473.6010809@feralindia.org> References: <472E3473.6010809@feralindia.org> Message-ID: <472E5D40.9080603@asu.edu> Ravinder Singh Bhalla wrote: > Dear Michael, > I'd be happy to contribute some time for the documentation. It would > really help if someone coordinated the effort - pointing to specific > modules needing work. > Cheers, > Ravi Thanks very much for the offer of help. Coordination would be very helpful of course. However, anyone can look at modules they know well and work to update them. Here are somethings to know about doing this (Markus might want to add more suggestions). 1. The doc/help file needs to be retrieved from the source code. If you don't compile GRASS yourself and don't want to deal with cvs, you can download this from the web access to the GRASS source tree. This will move to a new location fairly soon. But for now, it is at 2. The doc page is located inside the directory/folder for the module source code. For example, the doc file for r.info is found inside the grass6/raster/r.info folder 3. The doc page for a normal module or script is named description.html. Hence, to see and download the doc page for r.info, go to . 4. The doc page is just plain ASCII text with html tags. You can look at it in any text editor or an html editor. BUT CAUTION. Many slick html editors will try to add in extra tags (CSS or other). MS Word is especially notorioius for this. If you want to use an html editor, I can recommend KompoZer. It is an open source WYSIWYG html editor (successor to NVU) and located at . Make sure you turn OFF cascading style sheets in the preferences. 5. In the description.html file, you will notice that the name and basic name of the module/script and basic list of its options are missing. It is SUPPOSED to be that way. DON'T add this information back in. It is automatically generated from the module itself. 6. The doc file starts with the description of how the module/script works. This is where it will be really nice to have some input. Richer description, fix typos and grammatical errors, add graphics, add examples, etc. Any graphics should be in PNG format and pre-scaled to the proper size. Make them legible, but not too big. GIMP does a good job of scaling (use the cubic convolution resampling method, as it looks better). ImageMagic also works well if you like the command line. The image reference should be entered with the assumption that the image is in the same directory as the doc file. 7. How to get the updated help file into GRASS. This is where a coordinator would be very helpful. Until someone volunteers for this, maybe Markus will suggest a way to do this that does not make too much work for him. There is probably a way/place to submit such updates so that member of the development team with CVS access can get it into GRASS (e.g., the current bug tracker, though like the CVS, this too is slated to change soon). Thanks again for helping. Michael -- Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 WWW: http://www.public.asu.edu/~cmbarton From jachym.cepicky at gmail.com Mon Nov 5 07:27:52 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Mon Nov 5 07:27:59 2007 Subject: [GRASS-dev] Call for documentation help In-Reply-To: <1a486f560711041213q45b11c53i35638010a2df9095@mail.gmail.com> References: <472E13BE.80009@asu.edu> <1a486f560711041213q45b11c53i35638010a2df9095@mail.gmail.com> Message-ID: <1194244072.6533.11.camel@kocour> Hi, just noting: there is already great new demo dataset for GRASS available. See http://www.grassbook.org/data_menu3rd.php The documentation should IMHO be updated according to it. R demo() is good. I would suggest new "--demo" flag, which could run small demo script (demo.sh in each modules directory). What do you think? Jachym Daniel Calvelo p??e v Ne 04. 11. 2007 v 15:13 -0500: > I would add, wrt examples, "try to build working examples using the > demo data available" (spearfish, IMO; we should think about the new > demo for 7.0). We should probably use a system not unlike R's demo() > command or python's doctests, where the code examples within the docs > may be extracted and executed. This might also be merged into the > regression testing system. > > Daniel. > > On 11/4/07, Michael Barton wrote: > The GRASS team needs your help. As you all are well aware, > GRASS is > enormously sophisticated spatial analysis sophisticated. This > also makes > it equally complicated and sometimes baffling for users, with > over 300 > individual modules. GRASS has a top notch integrated and > contextual help > system. BUT we need help in making the most of the help > system. > > As with all open source software, the development team is a > group of > dedicated volunteers who work hard (in addition to their > regular jobs) > to create the first rate software that you all use. They are > also very > responsible in trying to document the program modules they > code and > maintain. > > This is where your help is needed. In spite of best intentions > and > efforts, development team members with coding skills need to > put most of > their always limited time into writing and maintaining the > code that > makes GRASS such a powerful and versatile software package. > Many of you > in the GRASS community are expert users even if you do not > have > expertise in programming. It is also clear from the traffic on > this list > that you are regularly willing to share your expertise with > others by > answering questions. > > Would some of you be willing to join the development team to > help manage > and improve the GRASS documentation and help system? You don't > need to > be proficient at programming, and because this is a team > effort, you > don't even need to know all parts of GRASS. What is needed is > sufficient > knowledge of some GRASS modules to help improve and maintain > their > documentation pages, a little bit of html (the help pages are > in very > basic html), and a desire to work cooperatively to improve > GRASS. Here > is a partial list of roles that are needed. > > Individual module management: > -Add or improve examples. Examples of how to use a module to > get > different results is very helpful > -Add or improve example graphic in modules. Screen shots are > often worth > many words > -Improve and enrich descriptions in English. In many cases, > documentation was written by valiant souls for whom English is > a 2nd (or > 3rd or 4th) language. Native speakers are needed to enrich > these > descriptions. > -Add or improve non-English versions of the documentation. > GRASS is > trying hard to be international and is used around the world. > Much of > the operational language of the modules have been translated > to other > languages (though a lot more help is needed in this too). Help > and doc > pages in other languages would make GRASS much more usable > globally. > > Overall: > -Documentation management. Someone or ones to mangage a team > of > documentation helpers, ID holes and weak spots in the > documentation, > coordinate with the coding team, and think about documentation > standards. > > If you are interested and willing to contribute a small part > of your > time to help others use GRASS, please respond to the GRASS > Developer > list and copy the GRASS project team > leader, > Markus Neteler > > Michael > > -- > > Professor of Anthropology > Director of Graduate Studies > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > Phone: 480-965-6262 > Fax: 480-965-7671 > WWW: http://www.public.asu.edu/~cmbarton > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > > > -- > -- Daniel Calvelo Aros > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- 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/20071105/934c9dac/attachment.bin From glynn at gclements.plus.com Mon Nov 5 08:09:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Nov 5 08:09:15 2007 Subject: [GRASS-dev] Re: GRASS documentation In-Reply-To: <472E5D40.9080603@asu.edu> References: <472E3473.6010809@feralindia.org> <472E5D40.9080603@asu.edu> Message-ID: <18222.49553.512498.581932@cerise.gclements.plus.com> Michael Barton wrote: > 4. The doc page is just plain ASCII text with html tags. You can look at > it in any text editor or an html editor. BUT CAUTION. Many slick html > editors will try to add in extra tags (CSS or other). MS Word is > especially notorioius for this. If you want to use an html editor, I can > recommend KompoZer. It is an open source WYSIWYG html editor (successor > to NVU) and located at . Make sure you > turn OFF cascading style sheets in the preferences. Have you actually tried using an HTML editor on those files? They aren't valid HTML, and aren't supposed to be. In particular, they lack the DOCTYPE declaration, the ... section, and the opening and tags (but include the closing tags). Anything which tries to save anything resembling valid HTML will have to have its output edited manually. Those files *must not* contain any of the parts which are output by the --html-description option. Also: 1. They must not contain tags or entities which are not understood by the g.html2man script (tools/g.html2man/g.html2man). 2. Any portions which are not modified must not be re-formatted during the editing process, as this will make the output from "cvs diff" useless. IOW: do not use a "WYSYWIG" HTML editor on those files, but either a normal text editor or something which is designed for editing HTML *source* (e.g. [X]Emacs' html-mode or psgml-mode). -- Glynn Clements From michael.barton at asu.edu Mon Nov 5 08:27:42 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Nov 5 08:27:50 2007 Subject: [GRASS-dev] Re: GRASS documentation In-Reply-To: <18222.49553.512498.581932@cerise.gclements.plus.com> Message-ID: Thanks for the clarifications Glynn. On 11/5/07 12:09 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> 4. The doc page is just plain ASCII text with html tags. You can look at >> it in any text editor or an html editor. BUT CAUTION. Many slick html >> editors will try to add in extra tags (CSS or other). MS Word is >> especially notorioius for this. If you want to use an html editor, I can >> recommend KompoZer. It is an open source WYSIWYG html editor (successor >> to NVU) and located at . Make sure you >> turn OFF cascading style sheets in the preferences. > > Have you actually tried using an HTML editor on those files? They > aren't valid HTML, and aren't supposed to be. In particular, they lack > the DOCTYPE declaration, the ... section, and the opening > and tags (but include the closing tags). > > Anything which tries to save anything resembling valid HTML will have > to have its output edited manually. Those files *must not* contain any > of the parts which are output by the --html-description option. > I've mainly created new files rather than edited old ones, using both plain text editor for some and more recently KompoZer for some others with graphics. You're comments make it clear that one must be careful in formatting with an HTML editor. Such a program is very helpful, however, for placing graphics, links, and simple text enhancements (level 1, bold, italics, etc). > Also: > > 1. They must not contain tags or entities which are not understood by > the g.html2man script (tools/g.html2man/g.html2man). Can you or someone specify what these are? > > 2. Any portions which are not modified must not be re-formatted during > the editing process, as this will make the output from "cvs diff" > useless. > Maybe one way to do this is to work with a copy of the description.html file, then use a simple text editor to cut out the edited/enhanced section and paste it into the original--leaving other areas untouched. However, any significant changes, including adding images, could put a bunch of stuff into a cvs diff. > IOW: do not use a "WYSYWIG" HTML editor on those files, but either a > normal text editor or something which is designed for editing HTML > *source* (e.g. [X]Emacs' html-mode or psgml-mode). When I used KompoZer, I did a lot of switching back and forth between the 'normal' mode and source mode. This worked OK, but would not be the best way to go for simple enhancements to the text. In any case, one needs to follow these guidelines to have a useful file that will work in the autogenerated help system. 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 hamish_nospam at yahoo.com Mon Nov 5 08:29:00 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Nov 5 08:29:03 2007 Subject: [GRASS-dev] Call for documentation help In-Reply-To: <1194244072.6533.11.camel@kocour> Message-ID: <408433.44038.qm@web52710.mail.re2.yahoo.com> Jachym Cepicky wrote: > just noting: there is already great new demo dataset for GRASS > available. See > > http://www.grassbook.org/data_menu3rd.php > > The documentation should IMHO be updated according to it. I would think it would be more productive to first focus on adding examples to help pages that do not have one, rather than spend lots of time remaking existing examples using another dataset. And even when all modules that usefully could have an example* have one, before working on redoing Spearfish examples we might work on examples which do not use a known & reproducible dataset. All examples that use a sample dataset should be stating which one they use. [*] e.g. there is little point adding an example for d.erase The immediate question then becomes which dataset to use for new examples. Hamish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From hamish_nospam at yahoo.com Mon Nov 5 08:19:03 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Nov 5 08:54:50 2007 Subject: [GRASS-dev] v.in.ogr -r and -e Message-ID: <20071105201903.b7616797.hamish_nospam@yahoo.com> Hi, I just added a new -r flag to v.in.ogr. It limits import to features falling in the current region; ie sets the spatial= option automatically. In doing that I noticed that the "-e" flag doesn't seem to be connected to any code. Anyone know what it is supposed to do? (added in cvs vector/v.in.ogr/main.c rev 1.29) Hamish From hamish_nospam at yahoo.com Mon Nov 5 09:17:20 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Nov 5 09:17:23 2007 Subject: [GRASS-dev] Re: GRASS documentation In-Reply-To: Message-ID: <411924.99814.qm@web52705.mail.re2.yahoo.com> Michael Barton wrote: > When I used KompoZer, I did a lot of switching back and forth between the > 'normal' mode and source mode. This worked OK, but would not be the best way > to go for simple enhancements to the text. FWIW, I think KompoZer could do a nicer job of adding in some whitespace. eg gis.m/docs/gm_*.html files are a bit dense & hard to work on without adding in some newlines. Otherwise they seem ok. I wasn't going to mention this before as it is just a minor complaint (typical html editor cruft would be grounds for complaint though), but in the context of the current thread... As for anyone getting ideas about fancy html tricks, please employ the K.I.S.S. principal. content >> flash thanks, Hamish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From neteler at fbk.eu Mon Nov 5 09:26:45 2007 From: neteler at fbk.eu (Markus Neteler) Date: Mon Nov 5 09:26:48 2007 Subject: [GRASS-dev] v.in.ogr -r and -e In-Reply-To: <20071105201903.b7616797.hamish_nospam@yahoo.com> References: <20071105201903.b7616797.hamish_nospam@yahoo.com> Message-ID: <472ED3C5.20704@fbk.eu> Hamish wrote on 11/05/2007 08:19 AM: > Hi, > > I just added a new -r flag to v.in.ogr. It limits import to features falling in the current region; ie sets the spatial= option automatically. > Hamish, cool, thanks! > In doing that I noticed that the "-e" flag doesn't seem to be connected to any code. Anyone know what it is supposed to do? (added in cvs vector/v.in.ogr/main.c rev 1.29) > It should do the same as r.in.gdal: -e Extend location extents based on new dataset To modify the DEFAULT_WIND file according to the map extent. Markus From glynn at gclements.plus.com Mon Nov 5 13:10:50 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Nov 5 13:11:00 2007 Subject: [GRASS-dev] Re: GRASS documentation In-Reply-To: References: <18222.49553.512498.581932@cerise.gclements.plus.com> Message-ID: <18223.2122.861808.744601@cerise.gclements.plus.com> Michael Barton wrote: > > 1. They must not contain tags or entities which are not understood by > > the g.html2man script (tools/g.html2man/g.html2man). > > Can you or someone specify what these are? >From a brief look at the g.html2man source, the following all appear to be understood to some extent: 

    •   
       
      
  <TR> <UL>

However, g.html2man just uses regexp matching; it doesn't include a
proper HTML parser. Consequently, there will be other restrictions on
the precise format, e.g. I wouldn't expect line breaks between
attributes to work.

> > 2. Any portions which are not modified must not be re-formatted during
> > the editing process, as this will make the output from "cvs diff"
> > useless.
> 
> Maybe one way to do this is to work with a copy of the description.html
> file, then use a simple text editor to cut out the edited/enhanced section
> and paste it into the original--leaving other areas untouched.
> 
> However, any significant changes, including adding images, could put a bunch
> of stuff into a cvs diff.

If there are many "genuine" changes, then you would expect to see a
substantial diff. The point is that changes shouldn't result in excess
diff output because unchanged sections have been reformatted (or
rather, regenerated) by the editor.

-- 
Glynn Clements <glynn@gclements.plus.com>

From mlennert at club.worldonline.be  Mon Nov  5 13:30:45 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Nov  5 13:35:44 2007
Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass
	and TclTk]
In-Reply-To: <18218.37460.394466.588287@cerise.gclements.plus.com>
References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be>	<4721E0E0.6080500@ufg.uni-kiel.de>	<4721E80B.90606@ufg.uni-kiel.de>	<4721EDB9.4090206@ufg.uni-kiel.de>	<4721F27F.1030903@club.worldonline.be>	<4721F454.9000303@ufg.uni-kiel.de>	<472209EC.8040006@ufg.uni-kiel.de>	<472212DC.1060503@club.worldonline.be>	<4725A9E2.50807@ufg.uni-kiel.de>	<4725AD25.3040607@club.worldonline.be>	<4725D789.6070305@ufg.uni-kiel.de>	<4725DD23.6050209@club.worldonline.be>	<4725E2C6.9000408@ufg.uni-kiel.de>	<18214.30000.228315.147756@cerise.gclements.plus.com>	<4726E54B.7040508@ufg.uni-kiel.de>	<18215.6250.408112.551042@cerise.gclements.plus.com>	<47272DDF.4010203@ufg.uni-kiel.de>	<20071031224813.11476432.hamish_nospam@yahoo.com>	<47285231.10209@club.worldonline.be>	<47285906.5080602@ufg.uni-kiel.de>	<2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be>	<Pine.LNX.4.62.0711011815060.8644@vortex.ukshells.co.uk>
	<18218.37460.394466.588287@cerise.gclements.plus.com>
Message-ID: <472F0CF5.8060304@club.worldonline.be>

On 02/11/07 03:58, Glynn Clements wrote:

> We may be able to solve the problem by providing our own shortcuts
> which start in the user's home directory (I *think* that you can use
> environment variables in that field).

I just tried with %USERPROFILE% and it works.
So can I assume that links are portable between machines (they are 
binaries) ? If yes, I'll just include a standard link into the 
distribution, inviting people to copy it to the desktop. This link can 
also be configured to minimize the cmd window which would solve that 
problem.

> If the user starts GRASS from an existing console, they probably don't
> want to change the current directory.
> 
>>> Nice also to finally get rid of this empty and useless cmd.exe window we
>>> had before.
>> Do you mean with the changes the init.bat script is exiting/abandoning 
>> after starting gis.m? The whole point of it staying running (and as a 
>> side-effect keeping a command prompt Window open - I don't know how to 
>> hide that but I presume it's possible)
> 
> The "start" command has a flag to hide the console window.

That is what Benjamin and I suggested to use. However, Paul is right 
that we currenly need a cmd session to remain open in order to do the 
clean up work at the end. And whichever way I turn the issue, I haven't 
been able to find a satisfying solution, yet. For more details, see 
towards the end of 
http://grass.itc.it/pipermail/grass5/2007-November/033889.html - from 
"Yes. I had forgotten about all that")

Moritz

From glynn at gclements.plus.com  Mon Nov  5 14:44:06 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Nov  5 14:44:10 2007
Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass
	and TclTk]
In-Reply-To: <472F0CF5.8060304@club.worldonline.be>
References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be>
	<4721E0E0.6080500@ufg.uni-kiel.de> <4721E80B.90606@ufg.uni-kiel.de>
	<4721EDB9.4090206@ufg.uni-kiel.de>
	<4721F27F.1030903@club.worldonline.be>
	<4721F454.9000303@ufg.uni-kiel.de>
	<472209EC.8040006@ufg.uni-kiel.de>
	<472212DC.1060503@club.worldonline.be>
	<4725A9E2.50807@ufg.uni-kiel.de>
	<4725AD25.3040607@club.worldonline.be>
	<4725D789.6070305@ufg.uni-kiel.de>
	<4725DD23.6050209@club.worldonline.be>
	<4725E2C6.9000408@ufg.uni-kiel.de>
	<18214.30000.228315.147756@cerise.gclements.plus.com>
	<4726E54B.7040508@ufg.uni-kiel.de>
	<18215.6250.408112.551042@cerise.gclements.plus.com>
	<47272DDF.4010203@ufg.uni-kiel.de>
	<20071031224813.11476432.hamish_nospam@yahoo.com>
	<47285231.10209@club.worldonline.be>
	<47285906.5080602@ufg.uni-kiel.de>
	<2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be>
	<Pine.LNX.4.62.0711011815060.8644@vortex.ukshells.co.uk>
	<18218.37460.394466.588287@cerise.gclements.plus.com>
	<472F0CF5.8060304@club.worldonline.be>
Message-ID: <18223.7718.661934.522909@cerise.gclements.plus.com>


Moritz Lennert wrote:

> > We may be able to solve the problem by providing our own shortcuts
> > which start in the user's home directory (I *think* that you can use
> > environment variables in that field).
> 
> I just tried with %USERPROFILE% and it works.
> So can I assume that links are portable between machines (they are 
> binaries) ?

I believe so.

> If yes, I'll just include a standard link into the 
> distribution, inviting people to copy it to the desktop. This link can 
> also be configured to minimize the cmd window which would solve that 
> problem.

The GUI should probably be started via a .bat file which uses the
"start" command with the option to hide the console window. The
console window won't appear unless something is written to
stdout/stderr (and they aren't redirected).

> > The "start" command has a flag to hide the console window.
> 
> That is what Benjamin and I suggested to use. However, Paul is right 
> that we currenly need a cmd session to remain open in order to do the 
> clean up work at the end. And whichever way I turn the issue, I haven't 
> been able to find a satisfying solution, yet. For more details, see 
> towards the end of 
> http://grass.itc.it/pipermail/grass5/2007-November/033889.html - from 
> "Yes. I had forgotten about all that")

Is it not possible to "start" a batch file which runs gis.m in the
foreground then deletes the files when it terminates? Or does that
still open a console window?

-- 
Glynn Clements <glynn@gclements.plus.com>

From neteler at fbk.eu  Mon Nov  5 15:37:52 2007
From: neteler at fbk.eu (Markus Neteler)
Date: Mon Nov  5 15:37:54 2007
Subject: [GRASS-dev] Re: GRASS documentation
In-Reply-To: <18223.2122.861808.744601@cerise.gclements.plus.com>
References: <18222.49553.512498.581932@cerise.gclements.plus.com>	<C35413FE.280C8%michael.barton@asu.edu>
	<18223.2122.861808.744601@cerise.gclements.plus.com>
Message-ID: <472F2AC0.5050901@fbk.eu>

Glynn Clements wrote on 11/05/2007 01:10 PM:
> Michael Barton wrote:
>   
>>> 1. They must not contain tags or entities which are not understood by
>>> the g.html2man script (tools/g.html2man/g.html2man).
>>>       
>> Can you or someone specify what these are?
>>     
>
> From a brief look at the g.html2man source, the following all appear
> to be understood to some extent:
>
> <A> <B> <BLINK> <BODY> <BR> <CODE> <DD> <DL> <DT> <EM> <H2> <H3> <H4>
> <HEAD> <HEADER> <HR> <I> <IMG> <LI> <OL> <P> <PRE> <SUP> <TABLE> <TD>
> <TH> <TITLE> <TR> <UL>
>
> However, g.html2man just uses regexp matching; it doesn't include a
> proper HTML parser. Consequently, there will be other restrictions on
> the precise format, e.g. I wouldn't expect line breaks between
> attributes to work.
>
>   
>>> 2. Any portions which are not modified must not be re-formatted during
>>> the editing process, as this will make the output from "cvs diff"
>>> useless.
>>>       
>> Maybe one way to do this is to work with a copy of the description.html
>> file, then use a simple text editor to cut out the edited/enhanced section
>> and paste it into the original--leaving other areas untouched.
>>
>> However, any significant changes, including adding images, could put a bunch
>> of stuff into a cvs diff.
>>     
>
> If there are many "genuine" changes, then you would expect to see a
> substantial diff. The point is that changes shouldn't result in excess
> diff output because unchanged sections have been reformatted (or
> rather, regenerated) by the editor.
>   

I have started a new file
SUBMITTING_DOCS
in the main source code directory. Hints should be collected there.

See also:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/SUBMITTING_DOCS?rev=HEAD&content-type=text/vnd.viewcvs-markup

Markus

From mlennert at club.worldonline.be  Mon Nov  5 15:41:10 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Nov  5 15:46:11 2007
Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass
	and TclTk]
In-Reply-To: <18223.7718.661934.522909@cerise.gclements.plus.com>
References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be>	<4721EDB9.4090206@ufg.uni-kiel.de>	<4721F27F.1030903@club.worldonline.be>	<4721F454.9000303@ufg.uni-kiel.de>	<472209EC.8040006@ufg.uni-kiel.de>	<472212DC.1060503@club.worldonline.be>	<4725A9E2.50807@ufg.uni-kiel.de>	<4725AD25.3040607@club.worldonline.be>	<4725D789.6070305@ufg.uni-kiel.de>	<4725DD23.6050209@club.worldonline.be>	<4725E2C6.9000408@ufg.uni-kiel.de>	<18214.30000.228315.147756@cerise.gclements.plus.com>	<4726E54B.7040508@ufg.uni-kiel.de>	<18215.6250.408112.551042@cerise.gclements.plus.com>	<47272DDF.4010203@ufg.uni-kiel.de>	<20071031224813.11476432.hamish_nospam@yahoo.com>	<47285231.10209@club.worldonline.be>	<47285906.5080602@ufg.uni-kiel.de>	<2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be>	<Pine.LNX.4.62.0711011815060.8644@vortex.ukshells.co.uk>	<18218.37460.394466.588287@cerise.gclements.plus.com>	<472F0CF5.8060304@club.worldonline.be>
	<18223.7718.661934.522909@cerise.gclements.pl us.com>
Message-ID: <472F2B86.9010602@club.worldonline.be>

On 05/11/07 14:44, Glynn Clements wrote:

> 
>> If yes, I'll just include a standard link into the 
>> distribution, inviting people to copy it to the desktop. This link can 
>> also be configured to minimize the cmd window which would solve that 
>> problem.

Actually it doesn't. If your .grassrc6 is configured to start grass in 
text mode, minimizing the window via the link does not allow you to see 
the terminal window...

So, again, the best solution seems to be two different .bat files for 
gui and text startup (also see below).

> 
> The GUI should probably be started via a .bat file which uses the
> "start" command with the option to hide the console window. The
> console window won't appear unless something is written to
> stdout/stderr (and they aren't redirected).

It actually appears as soon as you launch any .bat file.

> 
>>> The "start" command has a flag to hide the console window.
>> That is what Benjamin and I suggested to use. However, Paul is right 
>> that we currenly need a cmd session to remain open in order to do the 
>> clean up work at the end. And whichever way I turn the issue, I haven't 
>> been able to find a satisfying solution, yet. For more details, see 
>> towards the end of 
>> http://grass.itc.it/pipermail/grass5/2007-November/033889.html - from 
>> "Yes. I had forgotten about all that")
> 
> Is it not possible to "start" a batch file which runs gis.m in the
> foreground then deletes the files when it terminates? Or does that
> still open a console window?
> 

Yes, that is actually the "definition" of start (from 
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/start.mspx?mfr=true):

"Starts a separate Command Prompt window to run a specified program or 
command."

There is a flag /min to minimize this new window. There is also a flag 
/b ("Starts an application without opening a new Command Prompt 
window"). This opens the application in the current window...

But the problem is not launching gis.m without a terminal. That's quite 
easy. The problem is that launching grass63.bat automatically opens a 
terminal and that it is difficult to get rid of that, unless we follow 
your suggestion and have different .bat files for launching grass with 
or without gui.

As I wrote in the mail mentioned above:

> One option would be to use the start command in grass63.bat, such as:
> 
> start /min cmd /c "%WINGISBASE%\etc\init.bat" %*
> 
> It spawns a new minimized cmd.exe which then runs init.bat. This works
> great for GUI startup, but when you launch grass63.bat -text, you have the
> incovenience of a) another cmd window open for grass and b) you have to
> maximize the window to be able to enter grass. And since the 'text' option
> can come from the .grassrc6 file, we cannot count on a '-text' parameter
> being available in grass63.bat.

So, if we use two different grass63.bat files (or we parse the command 
line and .grassrc6 in grass63.bat), this option seems the easiest. It 
actually opens a cmd.exe window but this is minimized and so you only 
see it in the task bar (would be great to be able to get rid of that as 
well, but that should be acceptable - don't know if it is possible to 
hide a program from the task bar).

One option would be to create a gui launching script in another language 
(i.e. C, tcl, etc) so that it doesn't automatically provoke the launch 
of a cmd window.



Moritz

From tutey at o2.pl  Mon Nov  5 16:57:11 2007
From: tutey at o2.pl (Maciej Sieczka)
Date: Mon Nov  5 15:57:22 2007
Subject: [GRASS-dev] Re: [GRASS-user] Call for documentation help
In-Reply-To: <472E13BE.80009@asu.edu>
References: <472E13BE.80009@asu.edu>
Message-ID: <472F3D57.2050701@o2.pl>

"Updating GRASS Documentation" how-to [1].

[1]http://grass.gdf-hannover.de/wiki/Updating_GRASS_Documentation


Maciek

From michael.barton at asu.edu  Mon Nov  5 15:59:41 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Nov  5 15:59:51 2007
Subject: [GRASS-dev] Re: GRASS documentation
In-Reply-To: <411924.99814.qm@web52705.mail.re2.yahoo.com>
Message-ID: <C3547DED.280D3%michael.barton@asu.edu>




On 11/5/07 1:17 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

> Michael Barton wrote:
>> When I used KompoZer, I did a lot of switching back and forth between the
>> 'normal' mode and source mode. This worked OK, but would not be the best way
>> to go for simple enhancements to the text.
> 
> 
> FWIW, I think KompoZer could do a nicer job of adding in some whitespace.
> 
> eg gis.m/docs/gm_*.html files are a bit dense & hard to work on without adding
> in some newlines. Otherwise they seem ok.
> 
> I wasn't going to mention this before as it is just a minor complaint (typical
> html editor cruft would be grounds for complaint though), but in the context
> of
> the current thread...


In this case, one should blame the workman (me) not the tool. I followed
existing formats without thinking about white space, etc. a lot.

> 
> As for anyone getting ideas about fancy html tricks, please employ the
> K.I.S.S.
> principal.  content >> flash

Definitely! Some PNG graphic examples would be nice *where appropriate*. But
we shouldn't have animations or flying labels.

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 Nov  5 16:00:50 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Nov  5 16:00:59 2007
Subject: [GRASS-dev] Re: GRASS documentation
In-Reply-To: <18223.2122.861808.744601@cerise.gclements.plus.com>
Message-ID: <C3547E32.280D4%michael.barton@asu.edu>

Thanks very much. This is a good guideline. This is a place where a doc
coordinator could put this on the WIKI.

Michael


On 11/5/07 5:10 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>>> 1. They must not contain tags or entities which are not understood by
>>> the g.html2man script (tools/g.html2man/g.html2man).
>> 
>> Can you or someone specify what these are?
> 
> From a brief look at the g.html2man source, the following all appear
> to be understood to some extent:
> 
> <A> <B> <BLINK> <BODY> <BR> <CODE> <DD> <DL> <DT> <EM> <H2> <H3> <H4>
> <HEAD> <HEADER> <HR> <I> <IMG> <LI> <OL> <P> <PRE> <SUP> <TABLE> <TD>
> <TH> <TITLE> <TR> <UL>
> 
> However, g.html2man just uses regexp matching; it doesn't include a
> proper HTML parser. Consequently, there will be other restrictions on
> the precise format, e.g. I wouldn't expect line breaks between
> attributes to work.
> 
>>> 2. Any portions which are not modified must not be re-formatted during
>>> the editing process, as this will make the output from "cvs diff"
>>> useless.
>> 
>> Maybe one way to do this is to work with a copy of the description.html
>> file, then use a simple text editor to cut out the edited/enhanced section
>> and paste it into the original--leaving other areas untouched.
>> 
>> However, any significant changes, including adding images, could put a bunch
>> of stuff into a cvs diff.
> 
> If there are many "genuine" changes, then you would expect to see a
> substantial diff. The point is that changes shouldn't result in excess
> diff output because unchanged sections have been reformatted (or
> rather, regenerated) by the editor.

__________________________________________
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  Mon Nov  5 16:09:16 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Nov  5 16:14:16 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names before
	launching rectification
Message-ID: <472F321C.1040800@club.worldonline.be>

Hello,

If you give an illegal output name to i.rectify, this is only tested 
after rectification. This should be done before in order to have to wait 
for the whole process to finish to then notice it won't work.

Moritz

From neteler at fbk.eu  Mon Nov  5 16:25:25 2007
From: neteler at fbk.eu (Markus Neteler)
Date: Mon Nov  5 16:25:27 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names before
	launching rectification
In-Reply-To: <472F321C.1040800@club.worldonline.be>
References: <472F321C.1040800@club.worldonline.be>
Message-ID: <472F35E5.90105@fbk.eu>

Moritz Lennert wrote on 11/05/2007 04:09 PM:
> Hello,
>
> If you give an illegal output name to i.rectify, this is only tested
> after rectification. This should be done before in order to have to wait
> for the whole process to finish to then notice it won't work.
>   
Right - I guess
 G_legal_filename()
at the beginning would do the job.

Markus

From mlennert at club.worldonline.be  Mon Nov  5 17:10:24 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Nov  5 17:15:24 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names before
	launching rectification
In-Reply-To: <472F35E5.90105@fbk.eu>
References: <472F321C.1040800@club.worldonline.be> <472F35E5.90105@fbk.eu>
Message-ID: <472F4070.3050201@club.worldonline.be>

On 05/11/07 16:25, Markus Neteler wrote:
> Moritz Lennert wrote on 11/05/2007 04:09 PM:
>> Hello,
>>
>> If you give an illegal output name to i.rectify, this is only tested
>> after rectification. This should be done before in order to have to wait
>> for the whole process to finish to then notice it won't work.
>>   
> Right - I guess
>  G_legal_filename()
> at the beginning would do the job.

Yes, just make sure to check the given output filename + the given 
extension.

BTW anyone know how to give an empty extension in the tcltk gui ? On the 
command line I can use extension="", but in the gui I get an error 
because of an illegal ".

Moritz

From glynn at gclements.plus.com  Mon Nov  5 22:13:08 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Nov  5 22:13:11 2007
Subject: wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass
	and TclTk]
In-Reply-To: <472F2B86.9010602@club.worldonline.be>
References: <1280.85.10.88.247.1193335246.squirrel@geog-pc40.ulb.ac.be>
	<4721EDB9.4090206@ufg.uni-kiel.de>
	<4721F27F.1030903@club.worldonline.be>
	<4721F454.9000303@ufg.uni-kiel.de>
	<472209EC.8040006@ufg.uni-kiel.de>
	<472212DC.1060503@club.worldonline.be>
	<4725A9E2.50807@ufg.uni-kiel.de>
	<4725AD25.3040607@club.worldonline.be>
	<4725D789.6070305@ufg.uni-kiel.de>
	<4725DD23.6050209@club.worldonline.be>
	<4725E2C6.9000408@ufg.uni-kiel.de>
	<18214.30000.228315.147756@cerise.gclements.plus.com>
	<4726E54B.7040508@ufg.uni-kiel.de>
	<18215.6250.408112.551042@cerise.gclements.plus.com>
	<47272DDF.4010203@ufg.uni-kiel.de>
	<20071031224813.11476432.hamish_nospam@yahoo.com>
	<47285231.10209@club.worldonline.be>
	<47285906.5080602@ufg.uni-kiel.de>
	<2567.85.10.71.105.1193935067.squirrel@geog-pc40.ulb.ac.be>
	<Pine.LNX.4.62.0711011815060.8644@vortex.ukshells.co.uk>
	<18218.37460.394466.588287@cerise.gclements.plus.com>
	<472F0CF5.8060304@club.worldonline.be>
	<18223.7718.661934.522909@cerise.gclements.pl us.com>
	<472F2B86.9010602@club.worldonline.be>
Message-ID: <18223.34660.286720.573528@cerise.gclements.plus.com>


Moritz Lennert wrote:

> >>> The "start" command has a flag to hide the console window.
> >> That is what Benjamin and I suggested to use. However, Paul is right 
> >> that we currenly need a cmd session to remain open in order to do the 
> >> clean up work at the end. And whichever way I turn the issue, I haven't 
> >> been able to find a satisfying solution, yet. For more details, see 
> >> towards the end of 
> >> http://grass.itc.it/pipermail/grass5/2007-November/033889.html - from 
> >> "Yes. I had forgotten about all that")
> > 
> > Is it not possible to "start" a batch file which runs gis.m in the
> > foreground then deletes the files when it terminates? Or does that
> > still open a console window?
> 
> Yes, that is actually the "definition" of start (from 
> http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/start.mspx?mfr=true):
> 
> "Starts a separate Command Prompt window to run a specified program or 
> command."
> 
> There is a flag /min to minimize this new window. There is also a flag 
> /b ("Starts an application without opening a new Command Prompt 
> window"). This opens the application in the current window...
> 
> But the problem is not launching gis.m without a terminal. That's quite 
> easy. The problem is that launching grass63.bat automatically opens a 
> terminal and that it is difficult to get rid of that, unless we follow 
> your suggestion and have different .bat files for launching grass with 
> or without gui.

I think that different files for text vs GUI is probably going to be a
good idea for other reasons. I'm not sure what reasons exactly, but
Windows makes a distinction between console-mode and GUI executables
(unlike Unix, where X is just another library).

Also, the console for a batch file isn't necessarily a problem if the
batch file terminates as soon as it has spawned the GUI. The issue is
whether it's possible to spawn another batch file with /b then quit. 
If that's possible, the spawned batch file can deal with clean-up.

> As I wrote in the mail mentioned above:
> 
> > One option would be to use the start command in grass63.bat, such as:
> > 
> > start /min cmd /c "%WINGISBASE%\etc\init.bat" %*
> > 
> > It spawns a new minimized cmd.exe which then runs init.bat. This works
> > great for GUI startup, but when you launch grass63.bat -text, you have the
> > incovenience of a) another cmd window open for grass and b) you have to
> > maximize the window to be able to enter grass. And since the 'text' option
> > can come from the .grassrc6 file, we cannot count on a '-text' parameter
> > being available in grass63.bat.
> 
> So, if we use two different grass63.bat files (or we parse the command 
> line and .grassrc6 in grass63.bat), this option seems the easiest. It 
> actually opens a cmd.exe window but this is minimized and so you only 
> see it in the task bar (would be great to be able to get rid of that as 
> well, but that should be acceptable - don't know if it is possible to 
> hide a program from the task bar).
> 
> One option would be to create a gui launching script in another language 
> (i.e. C, tcl, etc) so that it doesn't automatically provoke the launch 
> of a cmd window.

Right. "wish" should be a GUI application, so a Tcl/Tk script run via
wish shouldn't open a new console. The script doesn't have to actually
use Tk. Actually, it wouldn't surprise me if tclsh was a GUI
application, to allow loading Tk dynamically.

Requiring Tcl/Tk isn't an issue for a script which is meant to launch
gis.m.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Nov  5 22:17:05 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Nov  5 22:17:13 2007
Subject: [GRASS-dev] Re: GRASS documentation
In-Reply-To: <C3547DED.280D3%michael.barton@asu.edu>
References: <411924.99814.qm@web52705.mail.re2.yahoo.com>
	<C3547DED.280D3%michael.barton@asu.edu>
Message-ID: <18223.34897.667134.299993@cerise.gclements.plus.com>


Michael Barton wrote:

> > As for anyone getting ideas about fancy html tricks, please employ the
> > K.I.S.S.
> > principal.  content >> flash
> 
> Definitely! Some PNG graphic examples would be nice *where appropriate*. But
> we shouldn't have animations or flying labels.

Also, bear in mind that images won't show up in the manual pages
(which are generated from the HTML), so they shouldn't be considered a
substitute for an adequate textual description.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Nov  5 22:24:44 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Nov  5 22:24:47 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names before
	launching rectification
In-Reply-To: <472F4070.3050201@club.worldonline.be>
References: <472F321C.1040800@club.worldonline.be> <472F35E5.90105@fbk.eu>
	<472F4070.3050201@club.worldonline.be>
Message-ID: <18223.35356.775748.654620@cerise.gclements.plus.com>


Moritz Lennert wrote:

> >> If you give an illegal output name to i.rectify, this is only tested
> >> after rectification. This should be done before in order to have to wait
> >> for the whole process to finish to then notice it won't work.
> >>   
> > Right - I guess
> >  G_legal_filename()
> > at the beginning would do the job.
> 
> Yes, just make sure to check the given output filename + the given 
> extension.

Oh; you're talking about illegal *file* names (as opposed to map
names)?

I don't think that we have a check for that.

Actually, the only reliable way to check whether a filename is legal
is to actually create the file. That should also ensure that creation
doesn't fail for other reasons (permissions, read-only filesystem,
etc).

> BTW anyone know how to give an empty extension in the tcltk gui ? On the 
> command line I can use extension="", but in the gui I get an error 
> because of an illegal ".

On the command line, using:

	extension=""

is the same as using just:

	extension=

The quotes are removed by the shell.

More generally, Tcl requires any quotes to go around the entire
"word", so a command line argument such as:

	text="hello world"

would need to be entered as 

	"text=hello world"
or:
	{text=hello world}

in Tcl.

-- 
Glynn Clements <glynn@gclements.plus.com>

From mlennert at club.worldonline.be  Mon Nov  5 22:52:41 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Nov  5 22:45:52 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names    
	before launching rectification
In-Reply-To: <18223.35356.775748.654620@cerise.gclements.plus.com>
References: <472F321C.1040800@club.worldonline.be> <472F35E5.90105@fbk.eu>
	<472F4070.3050201@club.worldonline.be>
	<18223.35356.775748.654620@cerise.gclements.plus.com>
Message-ID: <472F90A9.4060303@club.worldonline.be>

On Mon, November 5, 2007 22:24, Glynn Clements wrote:
> 
> Moritz Lennert wrote:
> 
>> >> If you give an illegal output name to i.rectify, this is only tested
>> >> after rectification. This should be done before in order to have to
>> wait
>> >> for the whole process to finish to then notice it won't work.
>> >>
>> > Right - I guess
>> >  G_legal_filename()
>> > at the beginning would do the job.
>>
>> Yes, just make sure to check the given output filename + the given
>> extension.
> 
> Oh; you're talking about illegal *file* names (as opposed to map
> names)?

No sorry, I meant map names.

> 
>> BTW anyone know how to give an empty extension in the tcltk gui ? On the
>> command line I can use extension="", but in the gui I get an error
>> because of an illegal ".
> 
> On the command line, using:
> 
> 	extension=""
> 
> is the same as using just:
> 
> 	extension=
> 
> The quotes are removed by the shell.

Thanks for the info.

> 
> More generally, Tcl requires any quotes to go around the entire
> "word", so a command line argument such as:
> 
> 	text="hello world"
> 
> would need to be entered as
> 
> 	"text=hello world"
> or:
> 	{text=hello world}
> 

So what would be the tcltk gui equivalent of extension= or extension="" 
? "Extension" is a text field to be filled in. So as a result you get a 
command line with extension=anything you put in the field (without any 
quotes. However, leaving the field empty does not work, as it is a 
required field. '""' doesn't work either. Would it work if the gui used 
curly braces around the result ? I.e. how to indicate an empty string to 
the gui ?

Moritz

From hamish_nospam at yahoo.com  Tue Nov  6 01:51:48 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Nov  6 01:51:52 2007
Subject: [GRASS-dev] v.in.ogr -r and -e
In-Reply-To: <472ED3C5.20704@fbk.eu>
Message-ID: <898323.96119.qm@web52712.mail.re2.yahoo.com>

Hamish:
> > In doing that I noticed that the "-e" flag doesn't seem to be connected to
> > any code. Anyone know what it is supposed to do? (added in cvs
> > vector/v.in.ogr/main.c rev 1.29)
Markus:
> It should do the same as r.in.gdal:
>   -e   Extend location extents based on new dataset
> 
> To modify the DEFAULT_WIND file according to the map extent.

see attached patch. (untested)


question- earlier in the v.in.ogr code as part of the projection-override check
there is a comment:
/* G_get_window seems to be unreliable if the location has been changed */
G__get_window ( &loc_wind, "", "DEFAULT_WIND", "PERMANENT");


should we worry about that for the extend flag?


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vio_extendflag.diff
Type: text/x-patch
Size: 1847 bytes
Desc: 4065563721-vio_extendflag.diff
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20071105/900e8b41/vio_extendflag.bin
From michael.barton at asu.edu  Tue Nov  6 03:16:14 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Nov  6 03:17:10 2007
Subject: [GRASS-dev] select issue with wingrass
Message-ID: <C3551C7E.28173%michael.barton@asu.edu>

I have a postdoc who just arrived to learn a bit of GRASS in my lab today.
He installed WinGRASS about a week ago. It launches fine. But he cannot see
any of the map files inside the mapset when he tries to add a map to a GUI
window. This is controlled by select.tcl. We checked this against the
Spearfish dataset and confirmed that the data are fine and that he does have
access to the maps. In fact, if he types in a map name, any module seems to
run fine--including displaying a map in the GIS Manager.

When you click a button to launch select.tcl, you get a window/dialog with a
tree which shows available mapsets and, if they exist, any accessible maps
in the mapset. You can select a map and click OK. Everything works for Javi
except seeing the maps inside the mapsets. He can even see the mapsets
(first level of the tree); just not the maps inside a mapset.

A first guess on my part is something to do with translating forward slash
for *nix and Mac "/" to backward slash for Windows "\". The odd thing is
that this worked fine with earlier builds of WinGRASS, so maybe it's
something else.

Have either of you guys run into this?

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/20071105/b6dd425f/attachment-0001.html
From michael.barton at asu.edu  Tue Nov  6 03:25:02 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Nov  6 03:25:26 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names
	before launching rectification
In-Reply-To: <472F4070.3050201@club.worldonline.be>
Message-ID: <C3551E8E.2817B%michael.barton@asu.edu>




On 11/5/07 9:10 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> BTW anyone know how to give an empty extension in the tcltk gui ? On the
> command line I can use extension="", but in the gui I get an error
> because of an illegal ".

Moritz,

I'd offer some advice, but I'm not sure I understand what you mean.

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 hamish_nospam at yahoo.com  Tue Nov  6 04:52:25 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Nov  6 04:52:28 2007
Subject: [GRASS-dev] SoC projects to trunk
In-Reply-To: <472AF427.3050701@bergenheim.net>
Message-ID: <873481.40654.qm@web52710.mail.re2.yahoo.com>

Wolf Bergenheim wrote:
> I have now brought the two SoC modules (v.generalize and
> v.net.visibility) to the CVS trunk.

Hi, a few cleanup issues-


Does v.net.visibility have anything to do with the other v.net.* modules, 
or is it just similar in name? As the other v.net.* modules all share vector
network node system (built with v.net), I worry that if v.net.visibility has
nothing to do with this it may cause confusion and v.path.obstacles would be a
better name. As I've not used it yet, I don't know, maybe it does.


I notice on the help page:
 - Still calls it v.path.obstacles in many places
 - A simple screenshot would be nice, using a standard dataset and given
commands so we can reproduce it while learning
 - It would be nice if the examples use a standard sample dataset
 - missing <BR> before "Mentor:"
 - "Last Changed:" needs to be have "$Date$" for the CVS to pick that up



I also notice that indent was run on the module at the same time as other
changes*. For a usable diff history indent changes must be committed on their
own, and with full command line options used, so that it is possible to
recreate and spot errors from new changes. As done it is very hard to follow
what the standardization changes were.  See the SUBMITTING file rule 15.

* http://freegis.org/cgi-bin/viewcvs.cgi/grass6/vector/v.net.visibility/


thanks,
Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From hamish_nospam at yahoo.com  Tue Nov  6 05:00:56 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Nov  6 05:00:59 2007
Subject: [GRASS-dev] Wingrass and TclTk
In-Reply-To: <47299129.7070103@ufg.uni-kiel.de>
Message-ID: <109791.99346.qm@web52704.mail.re2.yahoo.com>

> > So can we include TclTk and Mysys, if needed, in a single package that
> > allows all of GRASS to run?

Benjamin Ducke wrote:
> Yes, we can.
> I will put together such a "complete" package including these and other
> useful things for GRASS that are currently in the add-on repository.
> That would also include my own GRASS extensions and r.cva (which finally
> seems to run OK on Windows).
> 
> We will then have an all-in-one package for novice users and Moritz can
> still provide a bare-bones version for people that need or want it lean.
> 
> I think this should make everyone happy.


please double check the r.cva license. AFAIK it is not compatible with the GPL
and you can not distribute binary versions of the two together.

Or did you write a GEM framework script that merely provides the user the means
to compile and install r.cva easily?


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From hamish_nospam at yahoo.com  Tue Nov  6 05:32:20 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Nov  6 05:32:23 2007
Subject: [GRASS-dev] Wingrass and TclTk
In-Reply-To: <1194013108.4035.45.camel@dev64.localdomain>
Message-ID: <516067.92096.qm@web52702.mail.re2.yahoo.com>

> > > > > > Let's just all try and put together a complete list of what's
> > > > > > needed first, then I'll have a go at it.
Brad:
> > > > > I haven't been following the thread, but caught something interesting
> > > > > in this message.
> > > > > 
> > > > > It may be overkill, but I'd like to add configure checks for the
> final
> > > > > listing.  What we have has served us well, but adding more checks
> > > > > takes little time and would help catch portability issues.
> > > > > 
> > > > > Please cc: me on the final list unless someone decides this would be
> > > > > more clutter than solution.
Glynn:
> > > > configure is meant for compile-time checks. You can still build GRASS
> > > > without the utilities which are used in scripts. Conversely, just
> > > > because the utilities are present on the host, it doesn't mean that
> > > > they will be present on the target.
> > > 
> > > Why not check and disable parts that do not have the required
> > > program(s)?
> > 
> > There's no need to disable a script just because the host doesn't have
> > the files it uses. The host doesn't need them and the target may well
> > have them.
> 
> I disagree only because most scripts do not exit informatively enough
> for users to discover and correct the problem.

Please provide an example. I am not aware of any with special deps that do not
exit with "hey! you need to install awk to use this!" or something like that.
If those checks are missing for a non-standard utility program, then the bug is
in the script and should be fixed there. But I am not aware of any.

 
> > > Target<->host isn't a great argument.  You can say that with just about
> > > anything in configure. 
> > 
> > No; configure checks what is required for building a project. It
> > cannot detect whether you will be able to run it, and doesn't attempt
> > to.
> 
> True, but there's no rule against it and I've seen other projects do it.

No rule against it doesn't mean it's a good idea. It's a mistake to assume that
3rd party programs installed on the packager's machine will be on the user's
machine too.

> > > In the vast majority of instances, GRASS is
> > > packaged.  When I build a new RPM spec file, configure.in is very useful
> > > in revealing dependencies.

Debian, has both "Build-depends:" and "Depends:, Suggests:, Recommends:" lines
in the control file for build time and run time deps. I would hope RPM has
something similar.


> As a compromise, how about just putting that list on the wiki or in
> grass6/rpm to make it easier for packagers to build dependencies (in the
> interest of quelling some of the non-problem reports)?


Yes, absolutely these programs should be listed in the REQUIREMENTS.html file.
(that is linked to on the downloads page)

FWIW, see the "Optional packages" section of the cygwin download page.


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From hamish_nospam at yahoo.com  Tue Nov  6 06:13:56 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Nov  6 06:13:59 2007
Subject: [GRASS-dev] d.monsize perl req [was: Wingrass and TclTk]
In-Reply-To: <18218.36104.543742.871503@cerise.gclements.plus.com>
Message-ID: <716677.12082.qm@web52712.mail.re2.yahoo.com>

Glynn Clements  wrote:
> > >> 3. Additional utilities:
> > >
> > >> perl			d.monsize
> > >
> > > BTW, this one is rather gratuitous:
..
> Yes. But requiring perl to strip whitespace from a string is
> gratuitous for any platform.
> 
> None of the other installed scripts require perl. g.html2man requires
> perl, but that's only used at build time, and isn't installed.


I replaced the perl call in CVS/HEAD with:
  awk '{print $1}'


But I get this error from g.parser when I run the script:
G63> g.gisenv set="DEBUG=5"
G63> d.monsize x1 setwidth=300 setheight=100
D2/5: filename =
/usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/scripts/d.monsize
D2/5: set GIS_OPT_SETMONITOR=x1
D2/5: set GIS_OPT_SETWIDTH=300
D2/5: set GIS_OPT_SETHEIGHT=100
execl() failed: Exec format error


?
Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From wolf+grass at bergenheim.net  Tue Nov  6 08:17:26 2007
From: wolf+grass at bergenheim.net (Wolf Bergenheim)
Date: Tue Nov  6 08:18:00 2007
Subject: [GRASS-dev] SoC projects to trunk
In-Reply-To: <873481.40654.qm@web52710.mail.re2.yahoo.com>
References: <873481.40654.qm@web52710.mail.re2.yahoo.com>
Message-ID: <47301506.3070209@bergenheim.net>

On 06.11.2007 05:52, Hamish wrote:
> Wolf Bergenheim wrote:
>> I have now brought the two SoC modules (v.generalize and
>> v.net.visibility) to the CVS trunk.
> 
> Hi, a few cleanup issues-

Hi,

Thanks for your input :)

> 
> 
> Does v.net.visibility have anything to do with the other v.net.* modules, 
> or is it just similar in name?

v.net.visibility creates a visibility graph, which can then be further
analyzed with v.net.path to create the shortest path through or around
the obstacles. So I'd say it is very closely related to the other
v.net.* modules. (I'll add an example)

> As the other v.net.* modules all share vector
> network node system (built with v.net), I worry that if v.net.visibility has
> nothing to do with this it may cause confusion and v.path.obstacles would be a
> better name. As I've not used it yet, I don't know, maybe it does.
> 

In a way it is like v.net in that it creates a network which can be
further analyzed with the other v.net.* modules.

> 
> I notice on the help page:
>  - Still calls it v.path.obstacles in many places

fixed

>  - A simple screenshot would be nice, using a standard dataset and given
> commands so we can reproduce it while learning
>  - It would be nice if the examples use a standard sample dataset

I'll see if I can find something in either dataset.

>  - missing <BR> before "Mentor:"

fixed

>  - "Last Changed:" needs to be have "$Date$" for the CVS to pick that up

fixed


Thanks again for your input,
--Wolf

-- 

<:3 )---- Wolf Bergenheim ----( 8:>

From glynn at gclements.plus.com  Tue Nov  6 10:46:51 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue Nov  6 10:46:54 2007
Subject: [GRASS-dev] v.in.ogr -r and -e
In-Reply-To: <898323.96119.qm@web52712.mail.re2.yahoo.com>
References: <472ED3C5.20704@fbk.eu>
	<898323.96119.qm@web52712.mail.re2.yahoo.com>
Message-ID: <18224.14347.846219.475740@cerise.gclements.plus.com>


Hamish wrote:

> Hamish:
> > > In doing that I noticed that the "-e" flag doesn't seem to be connected to
> > > any code. Anyone know what it is supposed to do? (added in cvs
> > > vector/v.in.ogr/main.c rev 1.29)
> Markus:
> > It should do the same as r.in.gdal:
> >   -e   Extend location extents based on new dataset
> > 
> > To modify the DEFAULT_WIND file according to the map extent.
> 
> see attached patch. (untested)
> 
> 
> question- earlier in the v.in.ogr code as part of the projection-override check
> there is a comment:
> /* G_get_window seems to be unreliable if the location has been changed */
> G__get_window ( &loc_wind, "", "DEFAULT_WIND", "PERMANENT");
> 
> 
> should we worry about that for the extend flag?

No. The code introduced by the patch doesn't use G_get_window().

G_get_window() caches the window the first time that it's called, and
returns the cached value thereafter. Even if the mapset directory, the
value of WIND_OVERRIDE, or the contents of the WIND/$WIND_OVERRIDE
file change, the cached value will always be returned.

If you need to allow for such changes, use G__get_window(), which
doesn't cache anything. G_get_default_window() just calls
G__get_window(window,"","DEFAULT_WIND","PERMANENT"), and so doesn't
cache.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Tue Nov  6 10:55:06 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue Nov  6 10:55:12 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C3551C7E.28173%michael.barton@asu.edu>
References: <C3551C7E.28173%michael.barton@asu.edu>
Message-ID: <18224.14842.248814.671621@cerise.gclements.plus.com>


Michael Barton wrote:

> I have a postdoc who just arrived to learn a bit of GRASS in my lab today.
> He installed WinGRASS about a week ago. It launches fine. But he cannot see
> any of the map files inside the mapset when he tries to add a map to a GUI
> window. This is controlled by select.tcl. We checked this against the
> Spearfish dataset and confirmed that the data are fine and that he does have
> access to the maps. In fact, if he types in a map name, any module seems to
> run fine--including displaying a map in the GIS Manager.
> 
> When you click a button to launch select.tcl, you get a window/dialog with a
> tree which shows available mapsets and, if they exist, any accessible maps
> in the mapset. You can select a map and click OK. Everything works for Javi
> except seeing the maps inside the mapsets. He can even see the mapsets
> (first level of the tree); just not the maps inside a mapset.
> 
> A first guess on my part is something to do with translating forward slash
> for *nix and Mac "/" to backward slash for Windows "\". The odd thing is
> that this worked fine with earlier builds of WinGRASS, so maybe it's
> something else.

The relevant code is:

    # main selection subroutine
    if {$element != "symbol"} {
        foreach dir [exec g.mapsets -p] {
            set windfile "$location_path/$dir/WIND"
            if { ! [ file exists $windfile ] } { continue }
            if { $dir == $current_mapset } {
                $tree insert end root ms_$dir -text $dir -data $dir -open 1 \
                -image [Bitmap::get openfold] -drawcross auto
            } else {
                $tree insert end root ms_$dir -text $dir -data $dir -open 0 \
                -image [Bitmap::get folder] -drawcross auto
            }
            set path "$location_path/$dir/$element/"
            foreach fp [ lsort [glob -nocomplain $path/*] ]  {
            set file [file tail $fp]
            $tree insert end ms_$dir $file@$dir -text $file -data $file \
                -image [Bitmap::get file] -drawcross never
            }
        }
    }

The "file exists $windfile" test is obviously working, otherwise he
wouldn't see the mapsets. The most likely problem is with the "glob"
command. The glob(n) manpage implies that / should work. Can you try
running tclsh/wish interactively and testing the behaviour of the glob
command?

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Tue Nov  6 11:08:27 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue Nov  6 11:08:31 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names    
	before launching rectification
In-Reply-To: <472F90A9.4060303@club.worldonline.be>
References: <472F321C.1040800@club.worldonline.be> <472F35E5.90105@fbk.eu>
	<472F4070.3050201@club.worldonline.be>
	<18223.35356.775748.654620@cerise.gclements.plus.com>
	<472F90A9.4060303@club.worldonline.be>
Message-ID: <18224.15643.651881.932382@cerise.gclements.plus.com>


Moritz Lennert wrote:

> >> >> If you give an illegal output name to i.rectify, this is only tested
> >> >> after rectification. This should be done before in order to have to
> >> wait
> >> >> for the whole process to finish to then notice it won't work.
> >> >>
> >> > Right - I guess
> >> >  G_legal_filename()
> >> > at the beginning would do the job.
> >>
> >> Yes, just make sure to check the given output filename + the given
> >> extension.
> > 
> > Oh; you're talking about illegal *file* names (as opposed to map
> > names)?
> 
> No sorry, I meant map names.

Oops; I saw "extension" and assumed filenames.

> So what would be the tcltk gui equivalent of extension= or extension="" 
> ?

The Tcl equivalent is just:

	extension=

> "Extension" is a text field to be filled in. So as a result you get a 
> command line with extension=anything you put in the field (without any 
> quotes. However, leaving the field empty does not work, as it is a 
> required field. '""' doesn't work either. Would it work if the gui used 
> curly braces around the result ? I.e. how to indicate an empty string to 
> the gui ?

This appears to be a deficiency with the way that the GUI decides
whether to pass an option.

G_parser() can distinguish between an absent option and an option with
the empty string as its value.

If the GUI treats an empty text field as the option not being given,
then there is no way to pass an empty string as an option value. 
Anything you put into the text field will be passed literally as the
option's value.

AFAICT, the only solution is to add a checkbox to each option to force
the option to be passed. I suspect that i.rectify won't be the only
module where you might want to pass the empty string as an option
value.

Note that we have a similar problem with scripts using g.parser. I.e. 
there's no way to distinguish between an absent option and the empty
string as the option's value.

-- 
Glynn Clements <glynn@gclements.plus.com>

From mlennert at club.worldonline.be  Tue Nov  6 12:42:35 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Nov  6 12:47:40 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names before
	launching rectification
In-Reply-To: <C3551E8E.2817B%michael.barton@asu.edu>
References: <C3551E8E.2817B%michael.barton@asu.edu>
Message-ID: <4730532B.1010800@club.worldonline.be>

On 06/11/07 03:25, Michael Barton wrote:
> 
> 
> On 11/5/07 9:10 AM, "Moritz Lennert" <mlennert@club.worldonline.be>
> wrote:
> 
>> BTW anyone know how to give an empty extension in the tcltk gui ?
>> On the command line I can use extension="", but in the gui I get an
>> error because of an illegal ".
> 
> Moritz,
> 
> I'd offer some advice, but I'm not sure I understand what you mean.

How do you reproduce the following command:

i.rectify [...] extension=

in the gui launched when running i.rectify from the menu or from the
command line without options ?

Glynn has already pointed out that this seems to be a general deficiency:

On 06/11/07 11:08, Glynn Clements wrote:
> 
> This appears to be a deficiency with the way that the GUI decides 
> whether to pass an option.
> 
> G_parser() can distinguish between an absent option and an option
> with the empty string as its value.
> 
> If the GUI treats an empty text field as the option not being given, 
> then there is no way to pass an empty string as an option value. 
> Anything you put into the text field will be passed literally as the 
> option's value.
> 
> AFAICT, the only solution is to add a checkbox to each option to
> force the option to be passed. I suspect that i.rectify won't be the
> only module where you might want to pass the empty string as an
> option value.
> 
> Note that we have a similar problem with scripts using g.parser. I.e.
>  there's no way to distinguish between an absent option and the empty
>  string as the option's value.

Moritz

From mlennert at club.worldonline.be  Tue Nov  6 14:58:09 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Nov  6 15:03:14 2007
Subject: [GRASS-dev] GRASS 6.2.3RC1 published
In-Reply-To: <20071021164930.GA31121@bartok.fbk.eu>
References: <20071021164930.GA31121@bartok.fbk.eu>
Message-ID: <473072F1.90105@club.worldonline.be>

On 21/10/07 18:49, Markus Neteler wrote:
> GRASS 6.2.3RC1 has been published today:
>  http://grass.itc.it/grass62/source/
> 
> (on the mirrors soon).
> 
> This is a release candidate for the 6.2.3 bugfix release.
> 
> Bug fixes:
> 
>     * gis.m: georectifier tool documented (Markus Neteler)
>     * r.out.bin: fixed too short buffer which would sometimes crash R-GRASS interface (Roger Bivand)
>     * v.db.update: backported fixes for numeric value types (Debian #434897) (Markus Neteler)
>     * GUI crash of g.region with accented characters (non English locale) (Maris Nartis, Hamish Bowman)
>     * gis.m: maptool crash fixed (Moritz Lennert)
>     * silently ignore --quiet and --verbose command line switches (Hamish Bowman) 
> 
> Please add, if missing, more items at
> http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#6.2.3cvs
> 
> And please *test* this release candidate.

Another fix which should be backported to 6.2.3 IMHO:

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/tcltk/gis.m/gmtree.tcl.diff?r1=1.16&r2=1.17

At least the part concerning opening a Map Display automatically if none 
is open. AFAICT, this is just the following small change:

===================================================================
RCS file: /home/grass/grassrepository/grass6/gui/tcltk/gis.m/gmtree.tcl,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- grass6/gui/tcltk/gis.m/gmtree.tcl	2007/02/11 20:04:41	1.16
+++ grass6/gui/tcltk/gis.m/gmtree.tcl	2007/02/19 00:07:45	1.17
@@ -287,6 +287,10 @@
      global new_root_node
      global mon

+    # Create new tree, if none exists
+    if { [array size GmTree::tree] < 1 } {
+	Gm::startmon
+    }

      if { [catch {match string {} $new_root_node}] } {
      set new_root_node root

Moritz

From mlennert at club.worldonline.be  Tue Nov  6 16:12:56 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Nov  6 16:18:02 2007
Subject: [GRASS-dev] Re: select issue with wingrass
In-Reply-To: <C3551C7E.28173%michael.barton@asu.edu>
References: <C3551C7E.28173%michael.barton@asu.edu>
Message-ID: <47308478.2010106@club.worldonline.be>

On 06/11/07 03:16, Michael Barton wrote:
> I have a postdoc who just arrived to learn a bit of GRASS in my lab 
> today. He installed WinGRASS about a week ago. It launches fine. But he 
> cannot see any of the map files inside the mapset when he tries to add a 
> map to a GUI window. This is controlled by select.tcl. We checked this 
> against the Spearfish dataset and confirmed that the data are fine and 
> that he does have access to the maps. In fact, if he types in a map 
> name, any module seems to run fine--including displaying a map in the 
> GIS Manager.
> 
> When you click a button to launch select.tcl, you get a window/dialog 
> with a tree which shows available mapsets and, if they exist, any 
> accessible maps in the mapset. You can select a map and click OK. 
> Everything works for Javi except seeing the maps inside the mapsets. He 
> can even see the mapsets (first level of the tree); just not the maps 
> inside a mapset.
> 
> A first guess on my part is something to do with translating forward 
> slash for *nix and Mac "/" to backward slash for Windows "\". The odd 
> thing is that this worked fine with earlier builds of WinGRASS, so maybe 
> it's something else.
> 
> Have either of you guys run into this?

No, I've never had that problem. I'll test, but won't be in front of a 
win machine before tomorrow.

Moritz

From michael.barton at asu.edu  Tue Nov  6 16:18:58 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Nov  6 16:22:50 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <18224.14842.248814.671621@cerise.gclements.plus.com>
Message-ID: <C355D3F2.2819E%michael.barton@asu.edu>

Glynn,

I agree that it certainly looks like the problem code is

glob -nocomplain $path/*

"glob" ought to work because it is pure TclTk in this case (although
identical to the unix command). What about the "*"?

I don't know how to test this on Windows. Suggestions?

Michael


On 11/6/07 2:55 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> The relevant code is:
> 
>     # main selection subroutine
>     if {$element != "symbol"} {
>         foreach dir [exec g.mapsets -p] {
>             set windfile "$location_path/$dir/WIND"
>             if { ! [ file exists $windfile ] } { continue }
>             if { $dir == $current_mapset } {
>                 $tree insert end root ms_$dir -text $dir -data $dir -open 1 \
>                 -image [Bitmap::get openfold] -drawcross auto
>             } else {
>                 $tree insert end root ms_$dir -text $dir -data $dir -open 0 \
>                 -image [Bitmap::get folder] -drawcross auto
>             }
>             set path "$location_path/$dir/$element/"
>             foreach fp [ lsort [glob -nocomplain $path/*] ]  {
>             set file [file tail $fp]
>             $tree insert end ms_$dir $file@$dir -text $file -data $file \
>                 -image [Bitmap::get file] -drawcross never
>             }
>         }
>     }
> 
> The "file exists $windfile" test is obviously working, otherwise he
> wouldn't see the mapsets. The most likely problem is with the "glob"
> command. The glob(n) manpage implies that / should work. Can you try
> running tclsh/wish interactively and testing the behaviour of the glob
> command?
> 

__________________________________________
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 Nov  6 16:27:37 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Nov  6 16:27:55 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names
	before launching rectification
In-Reply-To: <4730532B.1010800@club.worldonline.be>
Message-ID: <C355D5F9.281A2%michael.barton@asu.edu>

Sorry to be dense, but an *optioal* argument *must* be present in i.rectify,
even if it is empty? This seems like a very weird situation.

To do it in TclTk, I'd do it one of two ways, depending on which execution
procedure you are using.

You could just put the whole command in quotes as a string.

set cmd "i.rectify ... extension="

[parse and run] cmd

OR

You could put the command in a list and parse it that way.

set cmdlist [list "i.rectify" "arg1" "arg2" ... "extension="]

[parse and run] cmdlist

Michael




On 11/6/07 4:42 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> On 06/11/07 03:25, Michael Barton wrote:
>> 
>> 
>> On 11/5/07 9:10 AM, "Moritz Lennert" <mlennert@club.worldonline.be>
>> wrote:
>> 
>>> BTW anyone know how to give an empty extension in the tcltk gui ?
>>> On the command line I can use extension="", but in the gui I get an
>>> error because of an illegal ".
>> 
>> Moritz,
>> 
>> I'd offer some advice, but I'm not sure I understand what you mean.
> 
> How do you reproduce the following command:
> 
> i.rectify [...] extension=
> 
> in the gui launched when running i.rectify from the menu or from the
> command line without options ?
> 
> Glynn has already pointed out that this seems to be a general deficiency:
> 
> On 06/11/07 11:08, Glynn Clements wrote:
>> 
>> This appears to be a deficiency with the way that the GUI decides
>> whether to pass an option.
>> 
>> G_parser() can distinguish between an absent option and an option
>> with the empty string as its value.
>> 
>> If the GUI treats an empty text field as the option not being given,
>> then there is no way to pass an empty string as an option value.
>> Anything you put into the text field will be passed literally as the
>> option's value.
>> 
>> AFAICT, the only solution is to add a checkbox to each option to
>> force the option to be passed. I suspect that i.rectify won't be the
>> only module where you might want to pass the empty string as an
>> option value.
>> 
>> Note that we have a similar problem with scripts using g.parser. I.e.
>>  there's no way to distinguish between an absent option and the empty
>>  string as the option's value.
> 
> Moritz

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


From glynn at gclements.plus.com  Tue Nov  6 16:53:47 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue Nov  6 16:53:51 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C355D3F2.2819E%michael.barton@asu.edu>
References: <18224.14842.248814.671621@cerise.gclements.plus.com>
	<C355D3F2.2819E%michael.barton@asu.edu>
Message-ID: <18224.36363.257444.442407@cerise.gclements.plus.com>


Michael Barton wrote:

> I agree that it certainly looks like the problem code is
> 
> glob -nocomplain $path/*
> 
> "glob" ought to work because it is pure TclTk in this case (although
> identical to the unix command). What about the "*"?
> 
> I don't know how to test this on Windows. Suggestions?

Run tclsh in a console, and type e.g.:

	glob -nocomplain C:/*

-- 
Glynn Clements <glynn@gclements.plus.com>

From mlennert at club.worldonline.be  Tue Nov  6 16:57:25 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Nov  6 17:02:30 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names before
	launching rectification
In-Reply-To: <C355D5F9.281A2%michael.barton@asu.edu>
References: <C355D5F9.281A2%michael.barton@asu.edu>
Message-ID: <47308EE5.3070304@club.worldonline.be>

On 06/11/07 16:27, Michael Barton wrote:
> Sorry to be dense, but an *optioal* argument *must* be present in i.rectify,
> even if it is empty? This seems like a very weird situation.

It is not optional.

This is not an issue in gis.m from where you cannot call i.rectify 
anymore (you have to go through the georectifying tool) .You can try it 
by typing i.rectify at the command line. In the tcltk window that pops 
up, just type any bogus values into all fields except for extension. If 
you click on run, you will get the error message:

ERROR: Required parameter <extension> not set:
     (Output file extension (inputfile(s) + extension)).

But in my case I don't want an extension, or, said differently, I want 
the extension to be empty. At the command line, I can just type 
'extension=', but there is no way I can give an 'empty' value to the 
extension parameter in the tcltk gui.

> 
> To do it in TclTk, I'd do it one of two ways, depending on which execution
> procedure you are using.
> 
> You could just put the whole command in quotes as a string.
> 
> set cmd "i.rectify ... extension="
> 
> [parse and run] cmd
> 
> OR
> 
> You could put the command in a list and parse it that way.
> 
> set cmdlist [list "i.rectify" "arg1" "arg2" ... "extension="]
> 
> [parse and run] cmdlist

So this means we have to change g.parser as Glynn seems to suggest, 
especially if this concerns other modules as well.

Moritz

From cdavilam at jemila.jazztel.es  Tue Nov  6 19:03:14 2007
From: cdavilam at jemila.jazztel.es (=?ISO-8859-15?Q?Carlos_D=E1vila?=)
Date: Tue Nov  6 19:03:15 2007
Subject: [GRASS-dev] Compiling problem after adding _()
Message-ID: <4730AC62.7050205@jemila.jazztel.es>

After change listed below in /lib/rst/interp_float/input2d.c modules 
r.resampl.rest and v.surf.rst don't compile.
-          G_fatal_error ("mask raster map [%s] not found", 
params->maskmap);
+        G_fatal_error (_("Mask raster map <%s> not found"), 
params->maskmap);

Error message is the same for both modules:
grass6/dist.i686-pc-linux-gnu/lib/libgrass_interpfl.so: undefined 
reference to `_'
collect2: ld returned 1 exit status

Is this normal?

Carlos

From landa.martin at gmail.com  Tue Nov  6 19:36:44 2007
From: landa.martin at gmail.com (Martin Landa)
Date: Tue Nov  6 19:36:49 2007
Subject: [GRASS-dev] Compiling problem after adding _()
In-Reply-To: <4730AC62.7050205@jemila.jazztel.es>
References: <4730AC62.7050205@jemila.jazztel.es>
Message-ID: <f8fe65c40711061036n772c1269k15b6e49d3e412f15@mail.gmail.com>

Ciao,

in this case you need to include glocale header file

#include <grass/glocale.h>

Martin

2007/11/6, Carlos D?vila <cdavilam@jemila.jazztel.es>:
> After change listed below in /lib/rst/interp_float/input2d.c modules
> r.resampl.rest and v.surf.rst don't compile.
> -          G_fatal_error ("mask raster map [%s] not found",
> params->maskmap);
> +        G_fatal_error (_("Mask raster map <%s> not found"),
> params->maskmap);
>
> Error message is the same for both modules:
> grass6/dist.i686-pc-linux-gnu/lib/libgrass_interpfl.so: undefined
> reference to `_'
> collect2: ld returned 1 exit status
>
> Is this normal?
>
> Carlos
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

From michael.barton at asu.edu  Tue Nov  6 19:45:28 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Nov  6 19:46:41 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names
	before launching rectification
In-Reply-To: <47308EE5.3070304@club.worldonline.be>
Message-ID: <C3560458.3477D%michael.barton@asu.edu>

Is this an error of requiring extension to be set? If so, this can be
changed in the C code of the module. This seems like the simplest solution.

Michael


On 11/6/07 8:57 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> On 06/11/07 16:27, Michael Barton wrote:
>> Sorry to be dense, but an *optioal* argument *must* be present in i.rectify,
>> even if it is empty? This seems like a very weird situation.
> 
> It is not optional.
> 
> This is not an issue in gis.m from where you cannot call i.rectify
> anymore (you have to go through the georectifying tool) .You can try it
> by typing i.rectify at the command line. In the tcltk window that pops
> up, just type any bogus values into all fields except for extension. If
> you click on run, you will get the error message:
> 
> ERROR: Required parameter <extension> not set:
>      (Output file extension (inputfile(s) + extension)).
> 
> But in my case I don't want an extension, or, said differently, I want
> the extension to be empty. At the command line, I can just type
> 'extension=', but there is no way I can give an 'empty' value to the
> extension parameter in the tcltk gui.
> 
>> 
>> To do it in TclTk, I'd do it one of two ways, depending on which execution
>> procedure you are using.
>> 
>> You could just put the whole command in quotes as a string.
>> 
>> set cmd "i.rectify ... extension="
>> 
>> [parse and run] cmd
>> 
>> OR
>> 
>> You could put the command in a list and parse it that way.
>> 
>> set cmdlist [list "i.rectify" "arg1" "arg2" ... "extension="]
>> 
>> [parse and run] cmdlist
> 
> So this means we have to change g.parser as Glynn seems to suggest,
> especially if this concerns other modules as well.
> 
> Moritz
> 

__________________________________________
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 cdavilam at jemila.jazztel.es  Tue Nov  6 19:47:19 2007
From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=)
Date: Tue Nov  6 19:47:24 2007
Subject: [GRASS-dev] Compiling problem after adding _()
In-Reply-To: <f8fe65c40711061036n772c1269k15b6e49d3e412f15@mail.gmail.com>
References: <4730AC62.7050205@jemila.jazztel.es>
	<f8fe65c40711061036n772c1269k15b6e49d3e412f15@mail.gmail.com>
Message-ID: <4730B6B7.6050603@jemila.jazztel.es>

Martin Landa escribi?:
> Ciao,
>
> in this case you need to include glocale header file
>
> #include <grass/glocale.h>
Thanks.
Applied and sent to cvs
Carlos

From landa.martin at gmail.com  Tue Nov  6 19:53:33 2007
From: landa.martin at gmail.com (Martin Landa)
Date: Tue Nov  6 19:53:36 2007
Subject: [GRASS-dev] Compiling problem after adding _()
In-Reply-To: <4730B6B7.6050603@jemila.jazztel.es>
References: <4730AC62.7050205@jemila.jazztel.es>
	<f8fe65c40711061036n772c1269k15b6e49d3e412f15@mail.gmail.com>
	<4730B6B7.6050603@jemila.jazztel.es>
Message-ID: <f8fe65c40711061053i46a579f7jc9176c186bcc1341@mail.gmail.com>

Hi,

I have already commited it to CVS... (as example)

Martin

2007/11/6, Carlos D?vila <cdavilam@jemila.jazztel.es>:
> Martin Landa escribi?:
> > Ciao,
> >
> > in this case you need to include glocale header file
> >
> > #include <grass/glocale.h>
> Thanks.
> Applied and sent to cvs
> Carlos
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

From cdavilam at jemila.jazztel.es  Tue Nov  6 20:17:25 2007
From: cdavilam at jemila.jazztel.es (=?ISO-8859-1?Q?Carlos_D=E1vila?=)
Date: Tue Nov  6 20:17:36 2007
Subject: [GRASS-dev] Compiling problem after adding _()
In-Reply-To: <f8fe65c40711061053i46a579f7jc9176c186bcc1341@mail.gmail.com>
References: <4730AC62.7050205@jemila.jazztel.es>	
	<f8fe65c40711061036n772c1269k15b6e49d3e412f15@mail.gmail.com>	
	<4730B6B7.6050603@jemila.jazztel.es>
	<f8fe65c40711061053i46a579f7jc9176c186bcc1341@mail.gmail.com>
Message-ID: <4730BDC5.3020307@jemila.jazztel.es>

Martin Landa escribi?:
> Hi,
>
> I have already commited it to CVS... (as example)
You are faster than me. I got a commit error while writing my previous mail.
Regards

From landa.martin at gmail.com  Tue Nov  6 20:36:41 2007
From: landa.martin at gmail.com (Martin Landa)
Date: Tue Nov  6 20:36:52 2007
Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.120,
	1.121
In-Reply-To: <20071106182445.DD5DB600D44@lists.intevation.de>
References: <20071106182445.DD5DB600D44@lists.intevation.de>
Message-ID: <f8fe65c40711061136n2e20ba91ga662110394a4d640@mail.gmail.com>

Nice Hamish! I love it.

2007/11/6, grass@intevation.de <grass@intevation.de>:
> Author: hamish
>
> Update of /grassrepository/grass6/lib/init
> In directory doto:/tmp/cvs-serv31353
>
> Modified Files:
>         init.sh
> Log Message:
> Gratuitous use of ASCII art
>
>
> Index: init.sh
> ===================================================================
> RCS file: /grassrepository/grass6/lib/init/init.sh,v
> retrieving revision 1.120
> retrieving revision 1.121
> diff -u -d -r1.120 -r1.121
> --- init.sh     6 Oct 2007 05:04:58 -0000       1.120
> +++ init.sh     6 Nov 2007 18:24:43 -0000       1.121
> @@ -9,7 +9,7 @@
>  #              Huidae Cho - Korea - grass4u@gmail.com
>  #              Justin Hickey - Thailand - jhickey@hpcc.nectec.or.th
>  #              Markus Neteler - Germany/Italy - neteler@itc.it
> -#                              Hamish Bowman - New Zealand - hamish_nospam at yahoo,com
> +#              Hamish Bowman - New Zealand - hamish_nospam at yahoo,com
>  # PURPOSE:     The source file for this shell script is in
>  #              src/general/init/init.sh. It sets up some environment
>  #              variables and the lock file. It also parses any remaining
> @@ -786,6 +786,13 @@
>         fi
>  fi
>
> +echo '          __________  ___   __________    _______________'
> +echo '         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/'
> +echo '        / / __/ /_/ / /| | \__ \\__ \   / / __ / / \__ \ '
> +echo '       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ / '
> +echo '       \____/_/ |_/_/  |_/____/____/   \____/___//____/  '
> +echo
> +
>  if [ -f "$GISBASE/locale/$LCL/etc/welcome" ] ; then
>         cat "$GISBASE/locale/$LCL/etc/welcome"
>  else
> @@ -810,6 +817,8 @@
>  esac
>
>  echo "When ready to quit enter:                exit"
> +echo
> +
>
>  case "$sh" in
>
>
>
> _______________________________________________
> grass-commit mailing list
> grass-commit@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-commit
>


-- 
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

From jachym.cepicky at gmail.com  Tue Nov  6 21:10:32 2007
From: jachym.cepicky at gmail.com (Jachym Cepicky)
Date: Tue Nov  6 21:10:37 2007
Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh,
	1.120, 1.121
In-Reply-To: <f8fe65c40711061136n2e20ba91ga662110394a4d640@mail.gmail.com>
References: <20071106182445.DD5DB600D44@lists.intevation.de>
	<f8fe65c40711061136n2e20ba91ga662110394a4d640@mail.gmail.com>
Message-ID: <1194379832.6334.21.camel@kocour>

Cool :-)

Jachym

Martin Landa p??e v ?t 06. 11. 2007 v 20:36 +0100:
> Nice Hamish! I love it.
> 
> 2007/11/6, grass@intevation.de <grass@intevation.de>:
> > Author: hamish
> >
> > Update of /grassrepository/grass6/lib/init
> > In directory doto:/tmp/cvs-serv31353
> >
> > Modified Files:
> >         init.sh
> > Log Message:
> > Gratuitous use of ASCII art
> >
> >
> > Index: init.sh
> > ===================================================================
> > RCS file: /grassrepository/grass6/lib/init/init.sh,v
> > retrieving revision 1.120
> > retrieving revision 1.121
> > diff -u -d -r1.120 -r1.121
> > --- init.sh     6 Oct 2007 05:04:58 -0000       1.120
> > +++ init.sh     6 Nov 2007 18:24:43 -0000       1.121
> > @@ -9,7 +9,7 @@
> >  #              Huidae Cho - Korea - grass4u@gmail.com
> >  #              Justin Hickey - Thailand - jhickey@hpcc.nectec.or.th
> >  #              Markus Neteler - Germany/Italy - neteler@itc.it
> > -#                              Hamish Bowman - New Zealand - hamish_nospam at yahoo,com
> > +#              Hamish Bowman - New Zealand - hamish_nospam at yahoo,com
> >  # PURPOSE:     The source file for this shell script is in
> >  #              src/general/init/init.sh. It sets up some environment
> >  #              variables and the lock file. It also parses any remaining
> > @@ -786,6 +786,13 @@
> >         fi
> >  fi
> >
> > +echo '          __________  ___   __________    _______________'
> > +echo '         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/'
> > +echo '        / / __/ /_/ / /| | \__ \\__ \   / / __ / / \__ \ '
> > +echo '       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ / '
> > +echo '       \____/_/ |_/_/  |_/____/____/   \____/___//____/  '
> > +echo
> > +
> >  if [ -f "$GISBASE/locale/$LCL/etc/welcome" ] ; then
> >         cat "$GISBASE/locale/$LCL/etc/welcome"
> >  else
> > @@ -810,6 +817,8 @@
> >  esac
> >
> >  echo "When ready to quit enter:                exit"
> > +echo
> > +
> >
> >  case "$sh" in
> >
> >
> >
> > _______________________________________________
> > grass-commit mailing list
> > grass-commit@grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-commit
> >
> 
> 
-- 
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/20071106/b580f615/attachment.bin
From jachym.cepicky at gmail.com  Tue Nov  6 21:56:26 2007
From: jachym.cepicky at gmail.com (Jachym Cepicky)
Date: Tue Nov  6 21:56:29 2007
Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh,
	1.120, 1.121
In-Reply-To: <1194379832.6334.21.camel@kocour>
References: <20071106182445.DD5DB600D44@lists.intevation.de>
	<f8fe65c40711061136n2e20ba91ga662110394a4d640@mail.gmail.com>
	<1194379832.6334.21.camel@kocour>
Message-ID: <1194382586.6334.30.camel@kocour>

BTW: this works better for me:

Index: init.sh
===================================================================
RCS file: /grassrepository/grass6/lib/init/init.sh,v
retrieving revision 1.121
diff -u -r1.121 init.sh
--- init.sh     6 Nov 2007 18:24:43 -0000       1.121
+++ init.sh     6 Nov 2007 20:55:05 -0000
@@ -788,7 +788,7 @@
 
 echo '          __________  ___   __________    _______________'
 echo '         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/'
-echo '        / / __/ /_/ / /| | \__ \\__ \   / / __ / / \__ \ '
+echo '        / / __/ /_/ / /| | \__ \\\\_  \\   / / __ / / \\__ \\ '
 echo '       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ / '
 echo '       \____/_/ |_/_/  |_/____/____/   \____/___//____/  '
 echo


Jachym Cepicky p??e v ?t 06. 11. 2007 v 21:10 +0100:
> Cool :-)
> 
> Jachym
> 
> Martin Landa p??e v ?t 06. 11. 2007 v 20:36 +0100:
> > Nice Hamish! I love it.
> > 
> > 2007/11/6, grass@intevation.de <grass@intevation.de>:
> > > Author: hamish
> > >
> > > Update of /grassrepository/grass6/lib/init
> > > In directory doto:/tmp/cvs-serv31353
> > >
> > > Modified Files:
> > >         init.sh
> > > Log Message:
> > > Gratuitous use of ASCII art
> > >
> > >
> > > Index: init.sh
> > > ===================================================================
> > > RCS file: /grassrepository/grass6/lib/init/init.sh,v
> > > retrieving revision 1.120
> > > retrieving revision 1.121
> > > diff -u -d -r1.120 -r1.121
> > > --- init.sh     6 Oct 2007 05:04:58 -0000       1.120
> > > +++ init.sh     6 Nov 2007 18:24:43 -0000       1.121
> > > @@ -9,7 +9,7 @@
> > >  #              Huidae Cho - Korea - grass4u@gmail.com
> > >  #              Justin Hickey - Thailand - jhickey@hpcc.nectec.or.th
> > >  #              Markus Neteler - Germany/Italy - neteler@itc.it
> > > -#                              Hamish Bowman - New Zealand - hamish_nospam at yahoo,com
> > > +#              Hamish Bowman - New Zealand - hamish_nospam at yahoo,com
> > >  # PURPOSE:     The source file for this shell script is in
> > >  #              src/general/init/init.sh. It sets up some environment
> > >  #              variables and the lock file. It also parses any remaining
> > > @@ -786,6 +786,13 @@
> > >         fi
> > >  fi
> > >
> > > +echo '          __________  ___   __________    _______________'
> > > +echo '         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/'
> > > +echo '        / / __/ /_/ / /| | \__ \\__ \   / / __ / / \__ \ '
> > > +echo '       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ / '
> > > +echo '       \____/_/ |_/_/  |_/____/____/   \____/___//____/  '
> > > +echo
> > > +
> > >  if [ -f "$GISBASE/locale/$LCL/etc/welcome" ] ; then
> > >         cat "$GISBASE/locale/$LCL/etc/welcome"
> > >  else
> > > @@ -810,6 +817,8 @@
> > >  esac
> > >
> > >  echo "When ready to quit enter:                exit"
> > > +echo
> > > +
> > >
> > >  case "$sh" in
> > >
> > >
> > >
> > > _______________________________________________
> > > grass-commit mailing list
> > > grass-commit@grass.itc.it
> > > http://grass.itc.it/mailman/listinfo/grass-commit
> > >
> > 
> > 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
-- 
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/20071106/a9fa06eb/attachment.bin
From hamish_nospam at yahoo.com  Tue Nov  6 23:28:03 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Nov  6 23:28:22 2007
Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.120,
	1.121
In-Reply-To: <1194382586.6334.30.camel@kocour>
Message-ID: <654775.59746.qm@web52709.mail.re2.yahoo.com>

Jachym Cepicky wrote:

> BTW: this works better for me:
..
>  echo '          __________  ___   __________    _______________'
>  echo '         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/'
> -echo '        / / __/ /_/ / /| | \__ \\__ \   / / __ / / \__ \ '
> +echo '        / / __/ /_/ / /| | \__ \\\\_  \\   / / __ / / \\__ \\ '
>  echo '       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ / '
>  echo '       \____/_/ |_/_/  |_/____/____/   \____/___//____/  '
>  echo


It was my understanding that using 'single quotes' meant that I didn't have to
worry about it being escaped by the shell? The above is shown literally on
Debian/etch.

I think that is a Dash nasty? Surely this is messing up someone's regex scripts
somewhere, and it doesn't smell much like a Bashism.

$ bash  
$ echo '\\'
\\
$ dash
$ echo '\\'
\

Is the practical solution to bypass the issue by using "double quotes" and
explicitly double-\\ any intended \\s?


artistic credit goes to the figlet package - Frank, Ian & Glenn's Letters
    http://www.figlet.org
handy online frontend  http://www.network-science.de/ascii/


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From glynn at gclements.plus.com  Wed Nov  7 01:02:32 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed Nov  7 01:02:37 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names
	before launching rectification
In-Reply-To: <C3560458.3477D%michael.barton@asu.edu>
References: <47308EE5.3070304@club.worldonline.be>
	<C3560458.3477D%michael.barton@asu.edu>
Message-ID: <18225.152.592333.690793@cerise.gclements.plus.com>


Michael Barton wrote:

> >> Sorry to be dense, but an *optioal* argument *must* be present in i.rectify,
> >> even if it is empty? This seems like a very weird situation.
> > 
> > It is not optional.
> > 
> > This is not an issue in gis.m from where you cannot call i.rectify
> > anymore (you have to go through the georectifying tool) .You can try it
> > by typing i.rectify at the command line. In the tcltk window that pops
> > up, just type any bogus values into all fields except for extension. If
> > you click on run, you will get the error message:
> > 
> > ERROR: Required parameter <extension> not set:
> >      (Output file extension (inputfile(s) + extension)).
> > 
> > But in my case I don't want an extension, or, said differently, I want
> > the extension to be empty. At the command line, I can just type
> > 'extension=', but there is no way I can give an 'empty' value to the
> > extension parameter in the tcltk gui.
> > 
> >> 
> >> To do it in TclTk, I'd do it one of two ways, depending on which execution
> >> procedure you are using.
> >> 
> >> You could just put the whole command in quotes as a string.
> >> 
> >> set cmd "i.rectify ... extension="
> >> 
> >> [parse and run] cmd
> >> 
> >> OR
> >> 
> >> You could put the command in a list and parse it that way.
> >> 
> >> set cmdlist [list "i.rectify" "arg1" "arg2" ... "extension="]
> >> 
> >> [parse and run] cmdlist
> > 
> > So this means we have to change g.parser as Glynn seems to suggest,
> > especially if this concerns other modules as well.
> 
> Is this an error of requiring extension to be set? If so, this can be
> changed in the C code of the module. This seems like the simplest solution.

No, the problem is gis.m's inability to pass the empty string as an
option's value. If you leave the text field blank, the option simply
doesn't get passed.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Wed Nov  7 01:16:35 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed Nov  7 01:16:41 2007
Subject: [GRASS-dev] Re: [GRASS-CVS] hamish: grass6/lib/init init.sh, 1.120,
	1.121
In-Reply-To: <654775.59746.qm@web52709.mail.re2.yahoo.com>
References: <1194382586.6334.30.camel@kocour>
	<654775.59746.qm@web52709.mail.re2.yahoo.com>
Message-ID: <18225.995.337490.322097@cerise.gclements.plus.com>


Hamish wrote:

> > BTW: this works better for me:
> ..
> >  echo '          __________  ___   __________    _______________'
> >  echo '         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/'
> > -echo '        / / __/ /_/ / /| | \__ \\__ \   / / __ / / \__ \ '
> > +echo '        / / __/ /_/ / /| | \__ \\\\_  \\   / / __ / / \\__ \\ '
> >  echo '       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ / '
> >  echo '       \____/_/ |_/_/  |_/____/____/   \____/___//____/  '
> >  echo
> 
> 
> It was my understanding that using 'single quotes' meant that I didn't have to
> worry about it being escaped by the shell? The above is shown literally on
> Debian/etch.

It isn't the shell; it's "echo" that's the problem.

Whether or not the "echo" command interprets escape sequences by
default varies between implementations.

In particular, the GNU version (both the bash built-in and the
standalone echo program from coreutils) does not conform to the Single
Unix Specification.

The SUS interface doesn't support any options, and escape sequences
are always enabled, while the bash version requires that you use -e to
enable them.

POSIX simply states the the behaviour is implementation-defined if any
argument contains a backslash.

	http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html

	http://www.gnu.org/software/coreutils/manual/html_node/echo-invocation.html

> I think that is a Dash nasty? Surely this is messing up someone's regex scripts
> somewhere, and it doesn't smell much like a Bashism.
> 
> $ bash  
> $ echo '\\'
> \\
> $ dash
> $ echo '\\'
> \
> 
> Is the practical solution to bypass the issue by using "double quotes" and
> explicitly double-\\ any intended \\s?

No. If you want to use a backslash, you'll need to forego "echo" in
favour of e.g. a here document:

cat <<EOF
          __________  ___   __________    _______________
         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/
        / / __/ /_/ / /| | \__ \\\\_  \\   / / __ / / \\__ \\ 
       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ / 
       \____/_/ |_/_/  |_/____/____/   \____/___//____/  

EOF

-- 
Glynn Clements <glynn@gclements.plus.com>

From hamish_nospam at yahoo.com  Wed Nov  7 03:12:54 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov  7 03:13:00 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names before
	launching rectification
In-Reply-To: <47308EE5.3070304@club.worldonline.be>
Message-ID: <289001.32428.qm@web52703.mail.re2.yahoo.com>

> ERROR: Required parameter <extension> not set:
>      (Output file extension (inputfile(s) + extension)).
> 
> But in my case I don't want an extension, or, said differently, I want 
> the extension to be empty. At the command line, I can just type 
> 'extension=', but there is no way I can give an 'empty' value to the 
> extension parameter in the tcltk gui.


this would work around the immediate problem:

    if(strlen(extension) == 0)
	G_fatal_error(_("Extension required"));

or default to none,

    ext->answer = "";
    ext->required = NO;

or test for ext="none" and replace it with "".


personally, I've always just used ext='.rect' and worried more about what was
happening with the data bugs in order=3 and the -c flag.


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From mlennert at club.worldonline.be  Wed Nov  7 10:07:45 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov  7 10:13:16 2007
Subject: [GRASS-dev] i.rectify should test for illegal file names	before
	launching rectification
In-Reply-To: <18225.152.592333.690793@cerise.gclements.plus.com>
References: <47308EE5.3070304@club.worldonline.be>	<C3560458.3477D%michael.barton@asu.edu>
	<18225.152.592333.690793@cerise.gclements.plus.com>
Message-ID: <47318061.3010906@club.worldonline.be>

On 07/11/07 01:02, Glynn Clements wrote:
> Michael Barton wrote:
> 
>>>> Sorry to be dense, but an *optioal* argument *must* be present in i.rectify,
>>>> even if it is empty? This seems like a very weird situation.
>>> It is not optional.
>>>
>>> This is not an issue in gis.m from where you cannot call i.rectify
>>> anymore (you have to go through the georectifying tool) .You can try it
>>> by typing i.rectify at the command line. In the tcltk window that pops
>>> up, just type any bogus values into all fields except for extension. If
>>> you click on run, you will get the error message:
>>>
>>> ERROR: Required parameter <extension> not set:
>>>      (Output file extension (inputfile(s) + extension)).
>>>
>>> But in my case I don't want an extension, or, said differently, I want
>>> the extension to be empty. At the command line, I can just type
>>> 'extension=', but there is no way I can give an 'empty' value to the
>>> extension parameter in the tcltk gui.
>>>
>>>> To do it in TclTk, I'd do it one of two ways, depending on which execution
>>>> procedure you are using.
>>>>
>>>> You could just put the whole command in quotes as a string.
>>>>
>>>> set cmd "i.rectify ... extension="
>>>>
>>>> [parse and run] cmd
>>>>
>>>> OR
>>>>
>>>> You could put the command in a list and parse it that way.
>>>>
>>>> set cmdlist [list "i.rectify" "arg1" "arg2" ... "extension="]
>>>>
>>>> [parse and run] cmdlist
>>> So this means we have to change g.parser as Glynn seems to suggest,
>>> especially if this concerns other modules as well.
>> Is this an error of requiring extension to be set? If so, this can be
>> changed in the C code of the module. This seems like the simplest solution.
> 
> No, the problem is gis.m's inability to pass the empty string as an
> option's value. If you leave the text field blank, the option simply
> doesn't get passed.
> 

To be totally fair it isn't gis.m's inability, but the inability of the 
automatically generated tcltk command gui...gis.m's menus actually do 
not include an entry for i.rectify as it is embedded in the georectifier 
(which always sets an extension).

Moritz

From mlennert at club.worldonline.be  Wed Nov  7 10:42:31 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov  7 10:48:17 2007
Subject: [GRASS-dev] Re: select issue with wingrass
In-Reply-To: <47308478.2010106@club.worldonline.be>
References: <C3551C7E.28173%michael.barton@asu.edu>
	<47308478.2010106@club.worldonline.be>
Message-ID: <47318887.6090207@club.worldonline.be>

On 06/11/07 16:12, Moritz Lennert wrote:
> On 06/11/07 03:16, Michael Barton wrote:
>> I have a postdoc who just arrived to learn a bit of GRASS in my lab 
>> today. He installed WinGRASS about a week ago. It launches fine. But 
>> he cannot see any of the map files inside the mapset when he tries to 
>> add a map to a GUI window. This is controlled by select.tcl. We 
>> checked this against the Spearfish dataset and confirmed that the data 
>> are fine and that he does have access to the maps. In fact, if he 
>> types in a map name, any module seems to run fine--including 
>> displaying a map in the GIS Manager.
>>
>> When you click a button to launch select.tcl, you get a window/dialog 
>> with a tree which shows available mapsets and, if they exist, any 
>> accessible maps in the mapset. You can select a map and click OK. 
>> Everything works for Javi except seeing the maps inside the mapsets. 
>> He can even see the mapsets (first level of the tree); just not the 
>> maps inside a mapset.
>>
>> A first guess on my part is something to do with translating forward 
>> slash for *nix and Mac "/" to backward slash for Windows "\". The odd 
>> thing is that this worked fine with earlier builds of WinGRASS, so 
>> maybe it's something else.
>>
>> Have either of you guys run into this?
> 
> No, I've never had that problem. I'll test, but won't be in front of a 
> win machine before tomorrow.
> 

Just tested and I cannot confirm this problem with any of the currently 
available versions (6.3RC1, cvs of of Nov. 1, current cvs). So, it seems 
to me that this is a specific issue in Ravi's installation. Where is his 
GISDBASE ? Is it on his machine or is it a networked drive ? Have you 
tried this with the spearfish data ?

Moritz

From jachym.cepicky at gmail.com  Wed Nov  7 11:21:17 2007
From: jachym.cepicky at gmail.com (Jachym Cepicky)
Date: Wed Nov  7 11:21:25 2007
Subject: [GRASS-dev] Re: [GRASS-user] GRASS on Ubuntu (dapper)
In-Reply-To: <473189B0.3060501@club.worldonline.be>
References: <8d79f4bb0711021708y363e6d69r30039a016ae100f2@mail.gmail.com>
	<4730917F.7090601@club.worldonline.be>
	<1194372398.6334.19.camel@kocour>
	<473189B0.3060501@club.worldonline.be>
Message-ID: <1194430877.6384.17.camel@kocour>

Hi,

thanks to Moritz, you can add line 

deb http://les-ejk.cz/ubuntu dapper multiverse

to your /etc/apt/sources.list

in Ubuntu Dapper Drake (6.10) and you should be able to install GRASS
via

apt-get install grass

I hope, it works :-)

Jachym
 
Moritz Lennert p??e v St 07. 11. 2007 v 10:47 +0100:
> On 06/11/07 19:06, Jachym Cepicky wrote:
> > Hi,
> > 
> > I could add your packages to les-ejk's repository, if you don't might
> 
> Here they are:
> 
> http://geog-pc40.ulb.ac.be/grass/ubuntu/
> 
> Moritz
-- 
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/20071107/7d2bedb8/attachment.bin
From mlennert at club.worldonline.be  Wed Nov  7 11:33:18 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov  7 11:38:26 2007
Subject: [GRASS-dev] Re: [GRASS-user] GRASS on Ubuntu (dapper)
In-Reply-To: <1194430877.6384.17.camel@kocour>
References: <8d79f4bb0711021708y363e6d69r30039a016ae100f2@mail.gmail.com>	
	<4730917F.7090601@club.worldonline.be>
	<1194372398.6334.19.camel@kocour>	
	<473189B0.3060501@club.worldonline.be>
	<1194430877.6384.17.camel@kocour>
Message-ID: <4731946E.9060500@club.worldonline.be>

On 07/11/07 11:21, Jachym Cepicky wrote:
> Hi,
> 
> thanks to Moritz, you can add line 
> 
> deb http://les-ejk.cz/ubuntu dapper multiverse
> 
> to your /etc/apt/sources.list
> 
> in Ubuntu Dapper Drake (6.10) 

AFAIK, Dapper Drake is 6.06.
6.10 is Edgy Eft.

Moritz

From jachym.cepicky at gmail.com  Wed Nov  7 12:30:53 2007
From: jachym.cepicky at gmail.com (Jachym Cepicky)
Date: Wed Nov  7 12:30:58 2007
Subject: [GRASS-dev] Re: [GRASS-user] GRASS on Ubuntu (dapper)
In-Reply-To: <4731946E.9060500@club.worldonline.be>
References: <8d79f4bb0711021708y363e6d69r30039a016ae100f2@mail.gmail.com>
	<4730917F.7090601@club.worldonline.be>
	<1194372398.6334.19.camel@kocour>
	<473189B0.3060501@club.worldonline.be>
	<1194430877.6384.17.camel@kocour>
	<4731946E.9060500@club.worldonline.be>
Message-ID: <1194435053.6384.21.camel@kocour>


Moritz Lennert p??e v St 07. 11. 2007 v 11:33 +0100:

> > 
> > deb http://les-ejk.cz/ubuntu dapper multiverse
> > 
> > 
> > in Ubuntu Dapper Drake (6.10) 
> 
> AFAIK, Dapper Drake is 6.06.
> 6.10 is Edgy Eft.
> 
> Moritz

of course, you are right :) sorry for the mess

j
-- 
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/20071107/f4d5b91a/attachment.bin
From epatton at nrcan.gc.ca  Wed Nov  7 19:32:15 2007
From: epatton at nrcan.gc.ca (Eric Patton)
Date: Wed Nov  7 19:32:19 2007
Subject: [GRASS-dev] GRASS documentation
In-Reply-To: <C3547E32.280D4%michael.barton@asu.edu>
References: <472E5D40.9080603@asu.edu>
	<18222.49553.512498.581932@cerise.gclements.plus.com>
	<C35413FE.280C8%michael.barton@asu.edu>
	<18223.2122.861808.744601@cerise.gclements.plus.com>
	<C3547E32.280D4%michael.barton@asu.edu>
Message-ID: <13632882.post@talk.nabble.com>


>Thanks very much. This is a good guideline. This is a place where a doc
>coordinator could put this on the WIKI.

>Michael


Done. I've added Glynn's suggestions to the Updating Documentation how-to:
http://grass.gdf-hannover.de/wiki/Updating_GRASS_Documentation

~ Eric.



-- 
View this message in context: http://www.nabble.com/Re%3A-GRASS-documentation-tf4748983.html#a13632882
Sent from the Grass - Dev mailing list archive at Nabble.com.

From epatton at nrcan.gc.ca  Wed Nov  7 21:37:15 2007
From: epatton at nrcan.gc.ca (Patton, Eric)
Date: Wed Nov  7 21:37:23 2007
Subject: [GRASS-dev] Re: Call for documentation help
Message-ID: <CA803441152AAE40935609509953BAD20F7260@s0-ott-x4.nrn.nrcan.gc.ca>

WRT documentation standards, I ran a few small scripts on the source directory tree for the display, general, raster, and vector commands to see how much variation there is in the use of different headings and sections within the description.html pages.  

I've attached the listing for the raster commands; as you can see, there's a fair bit of variation in the wording of sections in the html pages. If the goal is to use a uniform documentation style, we should probably figure out which headings are going to be accepted. I know it's not the most pressing issue, but a common style could save a lot of work in re-writes in the future.

OTOH, it may be deemed more important to allow flexibility in the use of headings for each module's html page. 

Ideas?

~ Eric.

-------------- next part --------------
r.average
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.basins.fill
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.bilinear
====================
<H2>DESCRIPTION</H2>
<H3>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.bitpattern
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.buffer
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.carve
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>BUGS AND CAVEAT</H2>
<H2>SEE ALSO</H2>
<H2>REFERENCES</H2>
<H2>AUTHOR</H2>


r.cats
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H3>Input from a file</H3>
<H3>Default and dynamic category labels</H3>
<H2>EXAMPLES</H2>
<H2>TODO</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.circle
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.clump
====================
<H2>DESCRIPTION</H2>
<H2>ALGORITHM</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.coin
====================
<h2>NAME</h2>
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.colors
====================
<h2>DESCRIPTION</h2>
<h2>EXAMPLES</h2>
<h2>SEE ALSO</h2>
<h2>AUTHORS</h2>


r.composite
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.compress
====================
<H2>DESCRIPTION</H2>
<H2>PROGRAM OPTIONS</H2>
<H2>FORMATS</H2>
<H3>PRE-3.0 FORMAT:</H3> 
<H3>POST-3.0 FORMAT:</H3> 
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.contour
====================
<h2>DESCRIPTION</h2>
<H2>
<H2>


r.cost
====================
<H2>DESCRIPTION</H2>
<H2>OPTIONS</H2>
<H2>NULL CELLS</H2>
<H2>NOTES</H2>
<H4>Algorithm notes</H4>
<H2>EXAMPLES</H2>
<H4>Output analysis</H4>
<H4>Shortest distance surfaces</H4>
<H2>BUGS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.covar
====================
<H2>DESCRIPTION</H2>
<H2>PRINCIPLE COMPONENTS</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.cross
====================
<H2>DESCRIPTION</H2>
<H2>OPTIONS</H2>
<H2>EXAMPLE</H2>
<H2>SUPPORT FILES</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.describe
====================
<H2>DESCRIPTION</H2>
<H3>PROGRAM USE</H3>
<H3>NON-INTERACTIVE PROGRAM USE</H3>
<h3>FLAGS</h3>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.digit
====================
<H2>DESCRIPTION</H2>
<H3>THE PROCESS:</H3>
<h4>Start a monitor and display a raster to help setup and zoom to area of interest</h4>
<h4>Digitizing an area based on a existing map; creating a new raster map</h4>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.distance
====================
<H2>DESCRIPTION</H2>
<H3>Explanation:</H3>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.drain
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLES</H2>
<H2>BUGS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.fill.dir
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE</H2>
<H2>ATTENTION</H2>
<H2>NOTE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.flow
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>Algorithm background</H2> 
<H2>FURTHER NOTES</H2>
<H2>DIAGNOSTICS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>
<H2>REFERENCES</H2>


r.grow2
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.gwflow
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.his
====================
<H2>DESCRIPTION</H2>
<H2>THE PROCESS</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.in.arc
====================
<H2>DESCRIPTION</H2>
<h2>NOTES</h2>
<h2>SEE ALSO</h2>
<h2>AUTHOR</h2>


r.in.ascii
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.in.bin
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLES</H2>
<h3>GTOPO30 DEM</h3>
<h3>GMT</h3>
<h3>AVHRR</h3>
<h3>ETOPO2</h3>
<h3>TOPEX/SRTM30 PLUS</h3>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.info
====================
<H2>DESCRIPTION</H2>
<H2>ACCURACY</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.in.gdal
====================
<H2>DESCRIPTION</H2>
<!--<H2>OPTIONS</H2>
<H3>Flags:</H3>
<H2>GDAL supported raster formats</H2>
<H2>Location Creation</H2>
<H2>NOTES</H2>
<H2>EXAMPLES</H2>
<h3>GTOPO30 DEM</h3>
<h3>GLOBE DEM</h3>
<h3>Worldclim.org</h3>
<h3>HDF</h3>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>REFERENCES</H2>
<H2>AUTHOR</H2>


r.in.gridatb
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.in.mat
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLES</H2>
<H2>TODO</H2>
<H2>BUGS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.in.poly
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>INPUT FORMAT</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.in.xyz
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<h4>Memory use</h4>
<h4>Setting region bounds and resolution</h4>
<h4>Filtering</h4>
<h4>Reprojection</h4>
<h4>Interpolation into a DEM</h4>
<H2>EXAMPLE</H2>
<H2>TODO</H2>
<H2>BUGS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.kappa
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.lake
====================
<h2>DESCRIPTION</h2>
<h2>KNOWN BUGS AND LIMITATIONS</h2>
<h2>MAPCALC EQUIVALENT - FOR GRASS HACKERS</h2>
<h2>SEE ALSO</h2>
<h2>AUTHOR</h2>


r.le
====================


r.le.patch
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>REFERENCES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.le.pixel
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>REFERENCES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.le.setup
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>REFERENCES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.le.trace
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>REFERENCES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.li
====================
<h2>NAME</h2>
<h2>KEYWORDS</h2>
<H2>DESCRIPTION</H2>
<H2>NOTE</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>ADDING NEW INDICES</H2>
<H2>REFERENCES</H2>
<H2>AUTHORS</H2>
<HR>


r.los
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.mapcalc
====================
<H2>NAME</H2>
<H2>DESCRIPTION</H2>
<H2>PROGRAM USE</H2>
<H2>OPERATORS AND ORDER OF PRECEDENCE</H2>
<H2>RASTER MAP LAYER NAMES</H2>
<H2>THE NEIGHBORHOOD MODIFIER</H2>
<H2>RASTER MAP LAYER VALUES FROM THE CATEGORY FILE</H2>
<H2>GREY SCALE EQUIVALENTS AND COLOR SEPARATES</H2>
<H2>FUNCTIONS</H2>
<H2>FLOATING POINT VALUES IN THE EXPRESSION</H2>
<H2>NULL support</H2>
<H2>EXAMPLES</H2>
<H2>NOTES</H2>
<H2>BUGS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.median
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.mfilter.fp
====================
<H2>DESCRIPTION</H2>
<H2>FILTERS</H2>
<H2>EXAMPLE FILTER FILE</H2>
<H2>HOW THE FILTER WORKS</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.mfilter
====================
<H2>DESCRIPTION</H2>
<H2>FILTERS</H2>
<H2>EXAMPLE FILTER FILE</H2>
<H2>HOW THE FILTER WORKS</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.mode
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.neighbors
====================
<H2>DESCRIPTION</H2>
<H2>OPTIONS</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.null
====================
<H2>DESCRIPTION</H2>
<h2>EXAMPLES</h2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.arc
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.ascii
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.bin
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.gdal
====================
<H2>DESCRIPTION</H2>
<H2>SUPPORTED RASTER FORMATS</H2>
<H2>NOTES</H2>
<H2>EXAMPLES</H2>
<h4>Export the integer raster roads map to GeoTIFF format:</h4>
<h4>Export a DCELL raster map in GeoTIFF format suitable for ESRI software:</h4>
<h4>Export the floating point raster elevation map to ERDAS/IMG format:</h4>
<H2>GDAL RELATED ERROR MESSAGES</H2>
<H2>SEE ALSO</H2>
<H2>REFERENCES</H2>
<H2>AUTHOR</H2>


r.out.gridatb
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.mat
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>TODO</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.mpeg
====================
<H2>DESCRIPTION</H2>
<h2>Example:</h2>
<H2>BUGS</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.png
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.pov
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE</H2>
<H2>AUTHOR</H2>


r.out.ppm3
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.ppm
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>HINTS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.tiff
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.out.vrml
====================
<H2>DESCRIPTION</H2>
<H2>WARNING</H2>
<H2>NOTE</H2>
<H2>BUGS:</H2>
<H2>TODO</H2>
<H2>AUTHOR</H2>


r.out.vtk
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H3>Difference between point- and celldata</H3>
<H2>EXAMPLE</H2>
<H3>Simple Spearfish example</H3>
<H3>Spearfish example with RGB data</H3>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.param.scale
====================
<h2>DESCRIPTION</h2>
<h2>NOTES</h2>
<h2>Still to do</h2>
<h2>EXAMPLE</h2>
<h2>SEE ALSO</h2>
<h2>REFERENCE</h2>
<h2>AUTHOR</h2>


r.patch
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.profile
====================
<H2>DESCRIPTION</H2>
<H2>OUTPUT FORMAT</H2>
<H2>EXAMPLES</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.proj
====================
<H2>DESCRIPTION</H2>
<H4>Introduction</H4>
<H5>Map projections</H5>
<H5>Projecting vector maps within the GRASS GIS</H5>
<H4>Design of r.proj</H4>
<h2>NOTES</h2>
<h2>REFERENCES</h2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.proj.seg
====================
<H2>DESCRIPTION</H2>
<H4>Introduction</H4>
<H5>Map projections</H5>
<H5>Projecting vector maps within the GRASS GIS</H5>
<H4>Design of r.proj</H4>
<h2>NOTES</h2>
<h2>REFERENCES</h2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.quant
====================
<H2>DESCRIPTION</H2>
<H2> Quant rules </H2> 
<H2>NOTE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.random.cells
====================
<H2>DESCRIPTION</H2>
<H2>PARAMETERS</H2>
<H2>NOTES</H2>
<h2>REFERENCES</h2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.random
====================
<H2>DESCRIPTION</H2>
<H2>OPTIONS</H2>
<H3>Flags:</H3>
<H3>Parameters:</H3>
<H2>NOTES</H2>
<H2>EXAMPLES</H2>
<H2>BUGS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.random.surface
====================
<H2>DESCRIPTION</H2>
<H3>Parameters:</H3>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<h2>REFERENCES</h2>
<H2>AUTHORS</H2>


r.reclass
====================
<H2>DESCRIPTION</H2>
<H2>INTERACTIVE PROGRAM USE: EXAMPLE</H2>
<H2>NON-INTERACTIVE PROGRAM USE: RECLASS RULES</H2>
<H2>NON-INTERACTIVE PROGRAM USE: EXAMPLES</H2>
<H2>NOTES</H2>
<H2>BEWARE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.recode
====================
<H2>DESCRIPTION</H2>
<h2>EXAMPLES</H2>
<H2>AUTHOR</H2>


r.region
====================
<H2>DESCRIPTION</H2>
<H2>NOTE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.report
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE:</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.resamp.interp
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.resample
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.resamp.rst
====================
<H2>DESCRIPTION</H2>
<h2>NOTES</h2>
<h2>SEE ALSO</h2>
<h2>AUTHORS</h2>
<h2>REFERENCES</h2>


r.resamp.stats
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.rescale.eq
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.rescale
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLE</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.series
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.slope.aspect
====================
<h2>DESCRIPTION</h2>
<h2>NOTES</h2>
<h2>REFERENCE</h2>
<h2>SEE ALSO</h2>
<h2>AUTHORS</h2>


r.statistics
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.stats
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.sum
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.sun
====================
<h2>DESCRIPTION</h2>
<h2> OPTIONS</h2>
<h2>
<h3>Shadow maps</h3>
<H2>EXAMPLE</H2>
<h2>SEE ALSO</h2>
<h2>REFERENCES</h2>
<h2>AUTHORS</h2>


r.sunmask
====================
<H2>DESCRIPTION</H2>
<h2>Notes</h2>
<h2>Acknowledgements</h2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.support
====================


r.support_headers_listing.txt
====================


r.support.stats
====================
<h2>DESCRIPTION</h2>
<h2>NOTES</h2>
<h2>SEE ALSO</h2>
<h2>AUTHORS</h2>


r.surf.area
====================
<H2>DESCRIPTION</H2>
<H2>NOTE</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.surf.contour
====================
<H2>DESCRIPTION</H2>
<H3>Parameters:</H3>
<H2>NOTES</H2>
<H2>BUGS</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.surf.fractal
====================
<H2>DESCRIPTION</H2>
<H2>NOTE</H2>
<H2>REFERENCE</h2>
<H2>SEE ALSO</H2>


r.surf.gauss
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.surf.idw2
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.surf.idw
====================
<H2>DESCRIPTION</H2>
<A NAME="notes.html"><H2>NOTES</H2></A>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.surf.random
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.terraflow
====================
<H2>NAME</H2> <B><I>r.terraflow </I></B>- computation of <i>flow
<H2>SYNOPSIS</H2>
<H2>DESCRIPTION</H2>
<H2>OPTIONS</H2>
<H3>Flags:</H3>
<H3>Parameters:</H3>
<H3>Examples</H3>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>
<H2>REFERENCES</H2>


r.texture
====================
<H2>DESCRIPTION</H2>
<h2>NOTES</h2>
<h2>BUGS</h2>
<h2>REFERENCES</h2>
<h2>SEE ALSO</h2>
<h2>AUTHOR</h2>


r.thin
====================
<H2>DESCRIPTION</H2>
<H2>NOTE</H2>
<H2>NOTE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.timestamp
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLES</H2>
<H2>TIMESTAMP FORMAT</H2>
<h2>SEE ALSO</h2>
<H2>BUGS</H2>
<H2>AUTHOR</H2>


r.topidx
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<h2>REFERENCE</h2>
<H2>AUTHORS</H2>


r.topmodel
====================
<H2>DESCRIPTION</H2>
<H3>Selected Parameters:</H3>
<H2>SEE ALSO</H2>
<H2>AUTHORS</H2>


r.to.rast3elev
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<h2>Example</h2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.to.rast3
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<h2>EXAMPLES</h2>
<h3>EXAMPLE 1</h3>
<h3>EXAMPLE 2</h3>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.to.vect
====================
<H2>DESCRIPTION</H2>
<H3>Points</H3>
<H3>Lines</H3>
<H3>Areas</H3>
<H2>BUGS</H2>
<H2>AUTHOR</H2>


r.transect
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.univar2
====================


r.univar_headers_listing.txt
====================


r.volume
====================
<H2>DESCRIPTION</H2>
<H2>NOTES</H2>
<H2>EXAMPLE OF REPORT</H2>
<h3>CENTROIDS</h3>
<h3>FORMAT OF CENTROIDS table<BR></h3>
<h3>APPLICATIONS</h3>
<H2>AUTHOR</H2>


r.walk
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>REFERENCES</H2>
<H2>AUTHORS</H2>


r.water.outlet
====================
<H2>DESCRIPTION</H2>
<H3>Selected Parameters</H3>
<H2>NOTES</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.watershed
====================


r.watershed_headers_listing.txt
====================


r.what.color
====================
<H2>DESCRIPTION</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>


r.what
====================
<H2>DESCRIPTION</H2>
<H2>EXAMPLES</H2>
<h4>Input from <tt>stdin</tt> on the command line</h4>
<h4>Input from a text file containing coordinates</h4>
<h4>Input coordinates given as a module option</h4>
<h4>Input coordinates piped from another program</h4>
<h4>Output containing raster map category labels</h4>
<H2>NOTE</H2>
<H2>SEE ALSO</H2>
<H2>AUTHOR</H2>
From hamish_nospam at yahoo.com  Thu Nov  8 02:27:17 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu Nov  8 02:27:22 2007
Subject: [GRASS-dev] Re: [GRASS-user] Re: Call for documentation help
In-Reply-To: <CA803441152AAE40935609509953BAD20F7260@s0-ott-x4.nrn.nrcan.gc.ca>
Message-ID: <102416.15721.qm@web52712.mail.re2.yahoo.com>

Eric wrote:
> WRT documentation standards, I ran a few small scripts on the source
> directory tree for the display, general, raster, and vector commands to see
> how much variation there is in the use of different headings and sections
> within the description.html pages.  
> 
> I've attached the listing for the raster commands; as you can see, there's a
> fair bit of variation in the wording of sections in the html pages. If the
> goal is to use a uniform documentation style, we should probably figure out
> which headings are going to be accepted. I know it's not the most pressing
> issue, but a common style could save a lot of work in re-writes in the
> future.
> 
> OTOH, it may be deemed more important to allow flexibility in the use of
> headings for each module's html page. 
> 
> Ideas?


Auto-generated (usually)
========================
<H2>NAME</H2>
<H2>KEYWORDS</H2>
<H2>SYNOPSIS</H2>



* = Required
! = Suggested
. = Optional

In recommended order
--------------------

* <H2>DESCRIPTION</H2>
! <H2>NOTE</H2>, <H2>NOTES</H2>
! <H2>EXAMPLE</H2>, <H2>EXAMPLES</H2>
. <H2>TODO</H2>
. <H2>BUGS</H2>
. <H2>REFERENCE</H2>, <H2>REFERENCES</H2>
* <H2>SEE ALSO</H2>
* <H2>AUTHOR</H2>, <H2>AUTHORS</H2>


more in this added to the wiki page:
 http://grass.gdf-hannover.de/wiki/Updating_GRASS_Documentation


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From hamish_nospam at yahoo.com  Thu Nov  8 09:04:42 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu Nov  8 09:04:22 2007
Subject: [GRASS-dev] r.in.xyz upgrade
In-Reply-To: <46A716F0.4080408@laserdata.at>
References: <46A716F0.4080408@laserdata.at>
Message-ID: <20071108210442.6a55a8df.hamish_nospam@yahoo.com>

[Back in July!] Volker Wichmann wrote:
> I have upgraded r.in.xyz to allow for the following aggregate functions:
> - skewness
> - median
> - percentile
> - trimmed mean
> 
> To make this possible, I created singly linked lists for all points 
> falling into a cell. I followed a suggestion of Glynn and used arrays 
> instead of pointers and stored the head of each list in a raster map 
> ([GRASS-dev] storing pointers in CELL_TYPE maps? (from April 2007)).
> The linked lists are then used to calculate the corresponding
> statistics before binning the values.
> So far we encountered no problems with this approach in our working 
> group, but I'm not sure about some details. Maybe there should be some 
> more checks, e.g. to prevent the index to overflow because of too many 
> cells.

[Gf patch #450]

After a long delay I have finally applied the patch in GRASS 6.3-CVS/HEAD.

I apologize to Volker for taking so long to deal with this, and congratulate him and his team on a job well done. It's a nice little bit of code.

The memory footprint seems to be about the same as for a stddev map.


Question for the LFS folks: if the region size is >2/4billion cells* will 
the num_nodes, max_nodes, and node.next variables want to be something larger than int? nb I expect there will be other memory issues in this case anyway, and multi-pass via the percent= option should be used.
* regions bigger than 45000x45000 / 63245x63245


aside:
I am finding the r.colors "-e" flag and the 'r.colors.stddev -z' add-on script very very useful these days. ('r.colors -e' for ignoring outliers and 'r.colors.stddev -z' for a proper differences map [method=skewness])


go forth and test it,
Hamish

From glynn at gclements.plus.com  Thu Nov  8 13:16:08 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu Nov  8 13:16:13 2007
Subject: [GRASS-user] Re: [GRASS-dev] r.in.xyz upgrade
In-Reply-To: <20071108210442.6a55a8df.hamish_nospam@yahoo.com>
References: <46A716F0.4080408@laserdata.at>
	<20071108210442.6a55a8df.hamish_nospam@yahoo.com>
Message-ID: <18226.65032.585903.837736@cerise.gclements.plus.com>


Hamish wrote:

> > I have upgraded r.in.xyz to allow for the following aggregate functions:
> > - skewness
> > - median
> > - percentile
> > - trimmed mean
> > 
> > To make this possible, I created singly linked lists for all points 
> > falling into a cell. I followed a suggestion of Glynn and used arrays 
> > instead of pointers and stored the head of each list in a raster map 
> > ([GRASS-dev] storing pointers in CELL_TYPE maps? (from April 2007)).
> > The linked lists are then used to calculate the corresponding
> > statistics before binning the values.
> > So far we encountered no problems with this approach in our working 
> > group, but I'm not sure about some details. Maybe there should be some 
> > more checks, e.g. to prevent the index to overflow because of too many 
> > cells.
> 
> [Gf patch #450]
> 
> After a long delay I have finally applied the patch in GRASS
> 6.3-CVS/HEAD.
> 
> I apologize to Volker for taking so long to deal with this, and
> congratulate him and his team on a job well done. It's a nice little
> bit of code.
> 
> The memory footprint seems to be about the same as for a stddev map.
> 
> 
> Question for the LFS folks: if the region size is >2/4billion cells*
> will the num_nodes, max_nodes, and node.next variables want to be
> something larger than int? nb I expect there will be other memory
> issues in this case anyway, and multi-pass via the percent= option
> should be used. * regions bigger than 45000x45000 / 63245x63245
> 
> 
> aside:
> I am finding the r.colors "-e" flag and the 'r.colors.stddev -z'
> add-on script very very useful these days. ('r.colors -e' for
> ignoring outliers and 'r.colors.stddev -z' for a proper differences
> map [method=skewness])
> 
> 
> go forth and test it,
> Hamish
> 
> _______________________________________________
> grassuser mailing list
> grassuser@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser

From landa.martin at gmail.com  Thu Nov  8 15:46:43 2007
From: landa.martin at gmail.com (Martin Landa)
Date: Thu Nov  8 15:49:22 2007
Subject: [GRASS-dev] grass cvs2svn migration status
Message-ID: <f8fe65c40711080646x3efee93bu809a5f9d57d96ffa@mail.gmail.com>

Hi all,

based on "Motion: migrate to SVN/trac on OSGeo infrastructure" [1] I
have been working on migration from the old GRASS CVS repository to
SVN. For details see the wiki-page [2,3].

Testing SVN repository [4] (see also [3]) has been created using
script (cvs2svn-s2.sh) [5]. Properties were added based on
propsfile-g[5|6]-2 (these files are still a bit messy...).

Any help, notes welcomed! (It is the first time I am doing such kind
of complex migration...).

Thanks a lot.

Regards Martin Landa

[1]
http://www.nabble.com/Motion%3A-migrate-to-SVN-trac-on-OSGeo-infrastructure-tf4629903.html#a13220358
[2] http://grass.gdf-hannover.de/wiki/Migration_from_CVS_to_SVN
[3] http://grass.gdf-hannover.de/wiki/Migration_from_CVS_to_SVN#Scenario_2_2
[4] http://josef.fsv.cvut.cz/cgi-bin/viewcvs.cgi/?root=grass-svn2
[5] http://josef.fsv.cvut.cz/~landa/grass-cvs2svn/

-- 
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

From epatton at nrcan.gc.ca  Thu Nov  8 15:56:32 2007
From: epatton at nrcan.gc.ca (Patton, Eric)
Date: Thu Nov  8 16:01:02 2007
Subject: [GRASS-dev] RE: [GRASS-user] Re: Call for documentation help
References: <102416.15721.qm@web52712.mail.re2.yahoo.com>
Message-ID: <CA803441152AAE40935609509953BAD20F7261@s0-ott-x4.nrn.nrcan.gc.ca>

Eric:
>> If the goal is to use a uniform documentation style, we should probably figure out
>> which headings are going to be accepted. I know it's not the most pressing
>> issue, but a common style could save a lot of work in re-writes in the
>> future.

Hamish:
>Auto-generated (usually)
>========================
><H2>NAME</H2>
><H2>KEYWORDS</H2>
><H2>SYNOPSIS</H2>
>
>* = Required
>! = Suggested
>. = Optional
>
>In recommended order
>--------------------
>
>* <H2>DESCRIPTION</H2>
>! <H2>NOTE</H2>, <H2>NOTES</H2>
>! <H2>EXAMPLE</H2>, <H2>EXAMPLES</H2>
>. <H2>TODO</H2>
>. <H2>BUGS</H2>
>. <H2>REFERENCE</H2>, <H2>REFERENCES</H2>
>* <H2>SEE ALSO</H2>
>* <H2>AUTHOR</H2>, <H2>AUTHORS</H2>
>
>more in this added to the wiki page:
>http://grass.gdf-hannover.de/wiki/Updating_GRASS_Documentation
>
>
>Hamish

Thanks for the feedback. This will form a good base to build on. The wiki page is much improved, too!

~ Eric.

From grass-dev at grass.itc.it  Thu Nov  8 19:32:44 2007
From: grass-dev at grass.itc.it (grass-dev@grass.itc.it)
Date: Thu Nov  8 19:32:46 2007
Subject: [GRASS-dev] [grass-doc P][527] update to d.barscale;
	documents behavior of using both -s and -l flags
Message-ID: <20071108183244.284BF40402@pyrosoma.intevation.org>

doc P item #527, was opened at 2007-11-08 14:32
Status: Open
Priority: 3
Submitted By: Eric Patton (eric)
Assigned to: Nobody (None)
Summary: update to d.barscale; documents behavior of using both -s and -l flags 
Patch type: enhancement
Patch status: None
GRASS version: CVS HEAD
GRASS component: display
Doc timestamp (YYMMDD): 071108


Initial Comment:
Currently the -s flag (to draw a barscale only, no north arrow) overrides the -l flag to draw a line scale. Kind of odd behavior, maybe, but probably not a bug, just an idiosyncrasy. It was undocumented on the html page, and this patch corrects that.

~ Eric. 

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=208&aid=527&group_id=21

From michael.barton at asu.edu  Thu Nov  8 22:38:37 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Thu Nov  8 22:38:56 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <18224.36363.257444.442407@cerise.gclements.plus.com>
Message-ID: <C358CFED.34868%michael.barton@asu.edu>

Glynn, Moritz, and Benjamin,

Tried this and it worked fine. Downloaded and installed the current (2
November) binary and still have the same problem.

Now were are constantly getting an error with dbf.ext when we are trying to
create points from a DBF table (only 6 points). The table is fine (checked
in OpenOffice). 

If there is a problem with Javier's installation, what do we need to do to
completely clean it off and try again? (maybe keep TclTk since it seems to
be OK?). 

Michael


On 11/6/07 8:53 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> I agree that it certainly looks like the problem code is
>> 
>> glob -nocomplain $path/*
>> 
>> "glob" ought to work because it is pure TclTk in this case (although
>> identical to the unix command). What about the "*"?
>> 
>> I don't know how to test this on Windows. Suggestions?
> 
> Run tclsh in a console, and type e.g.:
> 
> glob -nocomplain C:/*

__________________________________________
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 neteler at fbk.eu  Fri Nov  9 01:29:00 2007
From: neteler at fbk.eu (Markus Neteler)
Date: Fri Nov  9 01:29:03 2007
Subject: [GRASS-dev] GRASS 6.2.3RC1 published
In-Reply-To: <473072F1.90105@club.worldonline.be>
References: <20071021164930.GA31121@bartok.fbk.eu>
	<473072F1.90105@club.worldonline.be>
Message-ID: <20071109002900.GA29631@fbk.eu>

I have backported this one.

Markus

On Tue, Nov 06, 2007 at 02:58:09PM +0100, Moritz Lennert wrote:
> On 21/10/07 18:49, Markus Neteler wrote:
> > GRASS 6.2.3RC1 has been published today:
> >  http://grass.itc.it/grass62/source/
> >
> > (on the mirrors soon).
> >
> > This is a release candidate for the 6.2.3 bugfix release.
> >
> > Bug fixes:
> >
> >     * gis.m: georectifier tool documented (Markus Neteler)
> >     * r.out.bin: fixed too short buffer which would sometimes crash R-GRASS interface (Roger Bivand)
> >     * v.db.update: backported fixes for numeric value types (Debian #434897) (Markus Neteler)
> >     * GUI crash of g.region with accented characters (non English locale) (Maris Nartis, Hamish Bowman)
> >     * gis.m: maptool crash fixed (Moritz Lennert)
> >     * silently ignore --quiet and --verbose command line switches (Hamish Bowman)
> >
> > Please add, if missing, more items at
> > http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#6.2.3cvs
> >
> > And please *test* this release candidate.
> 
> Another fix which should be backported to 6.2.3 IMHO:
> 
> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/tcltk/gis.m/gmtree.tcl.diff?r1=1.16&r2=1.17
> 
> At least the part concerning opening a Map Display automatically if none
> is open. AFAICT, this is just the following small change:
> 
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/gui/tcltk/gis.m/gmtree.tcl,v
> retrieving revision 1.16
> retrieving revision 1.17
> diff -u -r1.16 -r1.17
> --- grass6/gui/tcltk/gis.m/gmtree.tcl   2007/02/11 20:04:41     1.16
> +++ grass6/gui/tcltk/gis.m/gmtree.tcl   2007/02/19 00:07:45     1.17
> @@ -287,6 +287,10 @@
>       global new_root_node
>       global mon
> 
> +    # Create new tree, if none exists
> +    if { [array size GmTree::tree] < 1 } {
> +       Gm::startmon
> +    }
> 
>       if { [catch {match string {} $new_root_node}] } {
>       set new_root_node root
> 
> Moritz
> 

From hamish_nospam at yahoo.com  Fri Nov  9 04:27:29 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri Nov  9 04:27:34 2007
Subject: [GRASS-dev] RE: [GRASS-user] Re: Call for documentation help
In-Reply-To: <CA803441152AAE40935609509953BAD20F7261@s0-ott-x4.nrn.nrcan.gc.ca>
Message-ID: <24698.46752.qm@web52712.mail.re2.yahoo.com>

Hi,

I am a bit out of the loop and don't know what is going on for translations of
the help pages .. the task seems to me too huge + a moving target to worry
about doing formally with our available peoplepower. They'd always be a little
out of date.


I don't know how AltaVista feels about live linking, but on the wiki I've added
experimental links to the Babelfish translator for the 6.3 online help pages:

  http://grass.gdf-hannover.de/wiki/Updating_GRASS_Documentation#Translations

They support the following languages:

Chinese - Simplified
Chinese - Traditional
Dutch
French
German
Greek
Italian
Japanese
Korean
Portuguese
Russian
Spanish


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From benjamin.ducke at ufg.uni-kiel.de  Fri Nov  9 11:34:56 2007
From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke)
Date: Fri Nov  9 11:35:43 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C358CFED.34868%michael.barton@asu.edu>
References: <C358CFED.34868%michael.barton@asu.edu>
Message-ID: <473437D0.50707@ufg.uni-kiel.de>



Michael Barton wrote:
> Glynn, Moritz, and Benjamin,
> 
> Tried this and it worked fine. Downloaded and installed the current (2
> November) binary and still have the same problem.

To re-iterate Moritz's line of thought: were is the data stored? Are you
accessing it over the network? Could there be a permissions problem with
Javier's user account? Is he allowed to look into the folders for the
mapsets?

> 
> Now were are constantly getting an error with dbf.ext when we are trying to
> create points from a DBF table (only 6 points). The table is fine (checked
> in OpenOffice). 

Some troubles with the DBF driver on Win have been reported on the QGIS
mailing list as well, but this seems to be a separate issue. What
exactly is the error message?

> 
> If there is a problem with Javier's installation, what do we need to do to
> completely clean it off and try again? (maybe keep TclTk since it seems to
> be OK?). 

WinGRASS does no tinker with any system files. Simply delete the whole
installation folder and you are rid of it.

Benjamin

> 
> Michael
> 
> 
> On 11/6/07 8:53 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
> 
>> Michael Barton wrote:
>>
>>> I agree that it certainly looks like the problem code is
>>>
>>> glob -nocomplain $path/*
>>>
>>> "glob" ought to work because it is pure TclTk in this case (although
>>> identical to the unix command). What about the "*"?
>>>
>>> I don't know how to test this on Windows. Suggestions?
>> Run tclsh in a console, and type e.g.:
>>
>> glob -nocomplain C:/*
> 
> __________________________________________
> 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 
> 
> 
> 

-- 
Benjamin Ducke, M.A.
Arch?oinformatik
(Archaeoinformation Science)
Institut f?r Ur- und Fr?hgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universit?t zu Kiel
Johanna-Mestorf-Stra?e 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

From mlennert at club.worldonline.be  Fri Nov  9 15:10:03 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Nov  9 15:15:24 2007
Subject: [GRASS-dev] RE: [GRASS-user] Re: Call for documentation help
In-Reply-To: <24698.46752.qm@web52712.mail.re2.yahoo.com>
References: <24698.46752.qm@web52712.mail.re2.yahoo.com>
Message-ID: <47346A3B.4040700@club.worldonline.be>

On 09/11/07 04:27, Hamish wrote:
> Hi,
> 
> I am a bit out of the loop and don't know what is going on for translations of
> the help pages .. the task seems to me too huge + a moving target to worry
> about doing formally with our available peoplepower. They'd always be a little
> out of date.

I agree, but I think that even a man page slightly out of date can be of 
use to someone who really doesn't understand the English version.

> 
> 
> I don't know how AltaVista feels about live linking, but on the wiki I've added
> experimental links to the Babelfish translator for the 6.3 online help pages:
> 
>   http://grass.gdf-hannover.de/wiki/Updating_GRASS_Documentation#Translations


Nice idea, with some interesting results (e.g. postscript becomes 
post-scriptum in the French version and - my favourite - GEM becomes 
"Directeur De Prolongements d'HERBE", meaning something like the 
director for the extension of grass/herbs ;-)).

One more serious issue though: the different options to commands are 
also translated, making them more or less useless:

v.clean [ -b] entr?=outil nomm?de rendement= de nom[type=corde 
[,corde... ] ][erreur=nom ]=corde[,corde... ] 
[battez=flotteur[,flotteur... ] ] [ - -recouvrez] [ - -bavard] [ - 
-tranquillit?]

and the choice of tools:

outil=string[,corde... ]
     Outil de nettoyage
     Options : coupure, rupture, rmdangle, chdangle, rmbridge, chbridge, 
rmdupl, rmdac, bpol, pruneau, rmarea, rmline, rmsa
     coupure: lignes de coupure ? chaque intersection
     rupture: lignes instantan?es au sommet dans le seuil
     rmdangle: enlevez balance, seuil ignor? si < 0
     chdangle: changez le type de fronti?re balancent pour rayer, seuil 
ignor? si < 0, input line type is ignored

[...]

Moritz

From michael.barton at asu.edu  Fri Nov  9 15:32:19 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Nov  9 15:32:29 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <473437D0.50707@ufg.uni-kiel.de>
Message-ID: <C359BD83.282CE%michael.barton@asu.edu>

Hi Benjamin,

On 11/9/07 3:34 AM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de> wrote:

> 
> 
> Michael Barton wrote:
>> Glynn, Moritz, and Benjamin,
>> 
>> Tried this and it worked fine. Downloaded and installed the current (2
>> November) binary and still have the same problem.
> 
> To re-iterate Moritz's line of thought: were is the data stored? Are you
> accessing it over the network? Could there be a permissions problem with
> Javier's user account? Is he allowed to look into the folders for the
> mapsets?

Sorry. Forgot to mention. All are in C:/grassdata. We've checked permissions
and even copied files locally to make sure of ownership. There no problem
USING the maps as long as we type their names into the GUI entry boxes.
There is simply the problem of SEEING the maps in the TclTk directory
listing. 

I simply have no idea where this problem is localized. If someone can
install the new binaries from scratch and test it would be helpful (I'll try
to find someone here to do that too).

I don't know whether it is a particular problem with Javi's machine or a
general problem that binary maintainers can't see because you've installed a
lot of stuff to compile GRASS.

> 
>> 
>> Now were are constantly getting an error with dbf.ext when we are trying to
>> create points from a DBF table (only 6 points). The table is fine (checked
>> in OpenOffice). 
> 
> Some troubles with the DBF driver on Win have been reported on the QGIS
> mailing list as well, but this seems to be a separate issue. What
> exactly is the error message?

Javi will email me this and I'll forward it on. When we look at details, it
claims a problem with a dll (don't remember which one).

Also getting an error on gdal import complainging about a gcs.cvs file

=====

ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.

=====

But we have a LOT of these and they seem to be in the right places.

=====

gcs   grass/share/gdal
gcs   grass/grass-6.3.csv/etc/ogr_csv
gcs   C:\Program Files\Quantum GIS
gcs   C:\Program Files\Data Interoperability Extensions\Reproject\epsg

=====


> 
>> 
>> If there is a problem with Javier's installation, what do we need to do to
>> completely clean it off and try again? (maybe keep TclTk since it seems to
>> be OK?). 
> 
> WinGRASS does no tinker with any system files. Simply delete the whole
> installation folder and you are rid of it.

Thanks!

Michael

> 
> Benjamin
> 
>> 
>> Michael
>> 
>> 
>> On 11/6/07 8:53 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
>> 
>>> Michael Barton wrote:
>>> 
>>>> I agree that it certainly looks like the problem code is
>>>> 
>>>> glob -nocomplain $path/*
>>>> 
>>>> "glob" ought to work because it is pure TclTk in this case (although
>>>> identical to the unix command). What about the "*"?
>>>> 
>>>> I don't know how to test this on Windows. Suggestions?
>>> Run tclsh in a console, and type e.g.:
>>> 
>>> glob -nocomplain C:/*
>> 
>> __________________________________________
>> 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
>> 
>> 
>> 

__________________________________________
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  Fri Nov  9 15:44:57 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Nov  9 15:50:25 2007
Subject: [GRASS-dev] [Fwd: [winGRASS] Logging errors in GRASS WIN]
Message-ID: <47347269.1060703@club.worldonline.be>

Forwarding this to grass-dev as it is not specific to wingrass:

-------- Original Message --------
Subject: 	[winGRASS] Logging errors in GRASS WIN
Date: 	Fri, 9 Nov 2007 09:24:46 -0500
From: 	Sampson, David <dsampson@nrcan.gc.ca>
To: 	<wingrass@grass.itc.it>



Is there a way to keep a logfile of errors running for the dialogues
that pop up?

I would realy like to copy/paste text from the dialogues instead of
retyping? is this a limitation of TCL?

Cheers

-------------- next part --------------
_______________________________________________
winGRASS mailing list
winGRASS@grass.itc.it
http://grass.itc.it/mailman/listinfo/wingrass

From mlennert at club.worldonline.be  Fri Nov  9 16:01:04 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Nov  9 16:06:23 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C359BD83.282CE%michael.barton@asu.edu>
References: <C359BD83.282CE%michael.barton@asu.edu>
Message-ID: <47347630.6060508@club.worldonline.be>

On 09/11/07 15:32, Michael Barton wrote:
> Hi Benjamin,
> 
> On 11/9/07 3:34 AM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de> wrote:
> 
>>
>> Michael Barton wrote:
>>> Glynn, Moritz, and Benjamin,
>>>
>>> Tried this and it worked fine. Downloaded and installed the current (2
>>> November) binary and still have the same problem.
>> To re-iterate Moritz's line of thought: were is the data stored? Are you
>> accessing it over the network? Could there be a permissions problem with
>> Javier's user account? Is he allowed to look into the folders for the
>> mapsets?
> 
> Sorry. Forgot to mention. All are in C:/grassdata. We've checked permissions
> and even copied files locally to make sure of ownership. There no problem
> USING the maps as long as we type their names into the GUI entry boxes.
> There is simply the problem of SEEING the maps in the TclTk directory
> listing. 


Could you also tell us which version of windows this is ?

> 
> I simply have no idea where this problem is localized. If someone can
> install the new binaries from scratch and test it would be helpful (I'll try
> to find someone here to do that too).

I'll try that as soon as I have the time, but that won't be before next 
Wednesday or Thursday.

> 
> I don't know whether it is a particular problem with Javi's machine or a
> general problem that binary maintainers can't see because you've installed a
> lot of stuff to compile GRASS.

One of our students has been testing wingrass and hasn't reported this 
issue.

> 
>>> Now were are constantly getting an error with dbf.ext when we are trying to
>>> create points from a DBF table (only 6 points). The table is fine (checked
>>> in OpenOffice). 
>> Some troubles with the DBF driver on Win have been reported on the QGIS
>> mailing list as well, but this seems to be a separate issue. What
>> exactly is the error message?
> 
> Javi will email me this and I'll forward it on. When we look at details, it
> claims a problem with a dll (don't remember which one).

The problems reported with the dbf driver recently are due to some bug 
in the driver which keep inserts and updates from working. But I have 
not had any reports about a dll issue.

How are you creating the points ?


> 
> Also getting an error on gdal import complainging about a gcs.cvs file

Haven't used gdal import for a while in wingrass, so will test that.

> 
> =====
> 
> ERROR 4: Unable to open EPSG support file gcs.csv.
> Try setting the GDAL_DATA environment variable to point to the
> directory containing EPSG csv files.

Have you tried setting this ?

Just to be sure: could you tell us how exactly Javi launches wingrass 
and what is the content of his grass63.bat file ?

Moritz

From michael.barton at asu.edu  Fri Nov  9 16:25:24 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Nov  9 16:25:33 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <47347630.6060508@club.worldonline.be>
Message-ID: <C359C9F4.282D2%michael.barton@asu.edu>

Hi Moritz,

See some answers below. I'm copying Javi so that he can respond directly
too.


On 11/9/07 8:01 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> On 09/11/07 15:32, Michael Barton wrote:
> 
> Could you also tell us which version of windows this is ?

Windows XP (I don't know if there is a specific version number or not. I can
ask him in the lab later this morning). It is an English-language version of
XP, so there are not undetected issues with languages and translations.

> 
>> 
>> I simply have no idea where this problem is localized. If someone can
>> install the new binaries from scratch and test it would be helpful (I'll try
>> to find someone here to do that too).
> 
> I'll try that as soon as I have the time, but that won't be before next
> Wednesday or Thursday.

Thanks.

> 
>> 
>> I don't know whether it is a particular problem with Javi's machine or a
>> general problem that binary maintainers can't see because you've installed a
>> lot of stuff to compile GRASS.
> 
> One of our students has been testing wingrass and hasn't reported this
> issue.

This is a help. I'm going to try to get a student in my lab to try it too.

> 
>> 
>>>> Now were are constantly getting an error with dbf.ext when we are trying to
>>>> create points from a DBF table (only 6 points). The table is fine (checked
>>>> in OpenOffice).
>>> Some troubles with the DBF driver on Win have been reported on the QGIS
>>> mailing list as well, but this seems to be a separate issue. What
>>> exactly is the error message?
>> 
>> Javi will email me this and I'll forward it on. When we look at details, it
>> claims a problem with a dll (don't remember which one).
> 
> The problems reported with the dbf driver recently are due to some bug
> in the driver which keep inserts and updates from working. But I have
> not had any reports about a dll issue.
> 
> How are you creating the points ?

v.in.db. We are using a dbf file that we've created in OpenOffice (to avoid
Excel issues). It certainly looks perfectly good.

> 
> 
>> 
>> Also getting an error on gdal import complainging about a gcs.cvs file
> 
> Haven't used gdal import for a while in wingrass, so will test that.
> 
>> 
>> =====
>> 
>> ERROR 4: Unable to open EPSG support file gcs.csv.
>> Try setting the GDAL_DATA environment variable to point to the
>> directory containing EPSG csv files.
> 
> Have you tried setting this ?

How would we go about setting this?

> 
> Just to be sure: could you tell us how exactly Javi launches wingrass
> and what is the content of his grass63.bat file

He launches it from a shortcut on the desktop to the grass63.bat file (I
don't know where the original is, but will ask him). I can ask him to send
you his bat file too. I think he got it from your site.

Thanks for all the help.

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  Fri Nov  9 18:59:41 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Nov  9 19:05:00 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <20071109094136.6r92lfr94bsookow@secure.lsit.ucsb.edu>
References: <C359C9F4.282D2%michael.barton@asu.edu>
	<20071109094136.6r92lfr94bsookow@secure.lsit.ucsb.edu>
Message-ID: <4734A00D.7040509@club.worldonline.be>

On 09/11/07 18:41, Javier Fernandez wrote:
> Hi all, I have attached a word file with the problems that I find when I 
> work with wingrass,

Thank you. Could you give the precise commands/actions you take to see 
these errors ?

e.g.:
> Problem 2: Unable to create points from a dbf. File: because a dbf error
> 
> 
> Output GIS
> 
> 
> NG: GRASS_TRUECOLOR status: TRUE
> 
> PNG: collecting to file: C:\grassdata/Spain_utm_30n/PERMANENT/.tmp/928.0.ppm,
> 
>      GRASS_WIDTH=575, GRASS_HEIGHT=484
> 
> Unable to open vector map <Yaci@PERMANENT> on topology level 0

and then you show a screenshot of the windows error message. But what do 
you do to get this result ? The above error message ("Unable to 
open...") seems to be related to displaying a map, whereas you say it is 
linked to v.to.db ?


> Problem 2: Unable to import a shapefile using OGR

What is the exact command you use to import it ?

And for
> 1. Is not possible select  in the Select Item window?s. 

Could you try to see if you have the same problem with the spearfish60 
demo location ?

Moritz

From mlennert at club.worldonline.be  Fri Nov  9 19:04:40 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Nov  9 19:10:00 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C359C9F4.282D2%michael.barton@asu.edu>
References: <C359C9F4.282D2%michael.barton@asu.edu>
Message-ID: <4734A138.8010903@club.worldonline.be>

On 09/11/07 16:25, Michael Barton wrote:
> Hi Moritz,
> 
> See some answers below. I'm copying Javi so that he can respond directly
> too.
> 
> 
> On 11/9/07 8:01 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
> 
>> On 09/11/07 15:32, Michael Barton wrote:
>>
>> Could you also tell us which version of windows this is ?
> 
> Windows XP (I don't know if there is a specific version number or not. I can
> ask him in the lab later this morning). 

I don't think this is necessary.

>>> I don't know whether it is a particular problem with Javi's machine or a
>>> general problem that binary maintainers can't see because you've installed a
>>> lot of stuff to compile GRASS.
>> One of our students has been testing wingrass and hasn't reported this
>> issue.
> 
> This is a help. I'm going to try to get a student in my lab to try it too.

Please also try it with the spearfish demo location.


>> How are you creating the points ?
> 
> v.in.db. We are using a dbf file that we've created in OpenOffice (to avoid
> Excel issues). It certainly looks perfectly good.

It is quite probable that this will probably not work because of the 
current bug in the dbf driver. Although AFAICT this should not cause a 
windows dll error...

Could you try creating an sqlite table with the same data and use 
v.in.db on that ?
You have to make sure that the sqlite executable (and I think library) 
are in your path.
You can set the PATH in the grass63.bat file:
set PATH=%PATH%;PathToSqliteBin;PathToSqliteLib


>>
>>> Also getting an error on gdal import complainging about a gcs.cvs file
>> Haven't used gdal import for a while in wingrass, so will test that.
>>
>>> =====
>>>
>>> ERROR 4: Unable to open EPSG support file gcs.csv.
>>> Try setting the GDAL_DATA environment variable to point to the
>>> directory containing EPSG csv files.
>> Have you tried setting this ?
> 
> How would we go about setting this?


Try setting it in the grass63.bat file:

set GDAL_DATA=

But is this a GRASS variable or a GDAL variable ?

Moritz

From michael.barton at asu.edu  Fri Nov  9 19:19:33 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Nov  9 19:19:43 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <4734A138.8010903@club.worldonline.be>
Message-ID: <C359F2C5.348E3%michael.barton@asu.edu>




On 11/9/07 11:04 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> On 09/11/07 16:25, Michael Barton wrote:

>> 
>> This is a help. I'm going to try to get a student in my lab to try it too.
> 
> Please also try it with the spearfish demo location.

Did this.

> 
> 
>>> How are you creating the points ?
>> 
>> v.in.db. We are using a dbf file that we've created in OpenOffice (to avoid
>> Excel issues). It certainly looks perfectly good.
> 
> It is quite probable that this will probably not work because of the
> current bug in the dbf driver. Although AFAICT this should not cause a
> windows dll error...
> 
> Could you try creating an sqlite table with the same data and use
> v.in.db on that ?
> You have to make sure that the sqlite executable (and I think library)
> are in your path.
> You can set the PATH in the grass63.bat file:
> set PATH=%PATH%;PathToSqliteBin;PathToSqliteLib

Can do that. But the issue is simply trying create points from a DBF. This
is important for my teaching next semester too. Insisting that students try
to figure out SQLite isn't very feasible.

I thought that the dbf error was fixed. If not, it is good to know that
v.in.db doesn't work currently. We can just use v.in.ascii instead.


> 
> 
>>> 
>>>> Also getting an error on gdal import complainging about a gcs.cvs file
>>> Haven't used gdal import for a while in wingrass, so will test that.

Got this dealt with. Interestingly, trying to import a file with an
incorrect format with v.in.ascii gives the same error as trying to import a
dbf file with v.in db, using dbf format. I don't know if this helps debug,
but maybe it is a clue.

>>> 
>>>> =====
>>>> 
>>>> ERROR 4: Unable to open EPSG support file gcs.csv.
>>>> Try setting the GDAL_DATA environment variable to point to the
>>>> directory containing EPSG csv files.
>>> Have you tried setting this ?
>> 
>> How would we go about setting this?
> 
> 
> Try setting it in the grass63.bat file:
> 
> set GDAL_DATA=

You mean leave this blank/empty? Or do you mean to point this variable to a
valid location?

> 
> But is this a GRASS variable or a GDAL variable ?

I have absolutely no idea.

> 
> Moritz


Thanks for the help.

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 michael.barton at asu.edu  Fri Nov  9 19:27:51 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Nov  9 19:27:57 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <4734A00D.7040509@club.worldonline.be>
Message-ID: <C359F4B7.348E8%michael.barton@asu.edu>




On 11/9/07 10:59 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> On 09/11/07 18:41, Javier Fernandez wrote:
>> Hi all, I have attached a word file with the problems that I find when I
>> work with wingrass,
> 
> Thank you. Could you give the precise commands/actions you take to see
> these errors ?
> 
> e.g.:
>> Problem 2: Unable to create points from a dbf. File: because a dbf error
>> 
>> 
>> Output GIS
>> 
>> 
>> NG: GRASS_TRUECOLOR status: TRUE
>> 
>> PNG: collecting to file: C:\grassdata/Spain_utm_30n/PERMANENT/.tmp/928.0.ppm,
>> 
>>      GRASS_WIDTH=575, GRASS_HEIGHT=484
>> 
>> Unable to open vector map <Yaci@PERMANENT> on topology level 0
> 
> and then you show a screenshot of the windows error message. But what do
> you do to get this result ? The above error message ("Unable to
> open...") seems to be related to displaying a map, whereas you say it is
> linked to v.to.db ?

The screenshot is an error caused by v.in.db.

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 michael.barton at asu.edu  Fri Nov  9 19:37:05 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Nov  9 19:37:41 2007
Subject: [GRASS-dev] help file incorrect for v.in.ascii
Message-ID: <C359F6E1.348E9%michael.barton@asu.edu>

I just tested something and found out that the helpfile is incorrect for
v.in.ascii (although  my often faulty memory was correct).

The helpfile says that you can specify which columns are used for the x and
y coordinates. However, this generates an error.

I remembered that in the past, the x and y columns MUST be the the first 2.
When we changed our text file to have x and y in columns 1 and 2, it reads
the file fine.

We?re doing this with GRASS 6.3 on Windows AND Mac.

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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://grass.itc.it/pipermail/grass-dev/attachments/20071109/08a26c62/attachment.html
From mlennert at club.worldonline.be  Fri Nov  9 19:41:52 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Nov  9 19:47:12 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C359F2C5.348E3%michael.barton@asu.edu>
References: <C359F2C5.348E3%michael.barton@asu.edu>
Message-ID: <4734A9F0.6010509@club.worldonline.be>

On 09/11/07 19:19, Michael Barton wrote:
> 
> 
> On 11/9/07 11:04 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:


>>
>> Could you try creating an sqlite table with the same data and use
>> v.in.db on that ?
>> You have to make sure that the sqlite executable (and I think library)
>> are in your path.
>> You can set the PATH in the grass63.bat file:
>> set PATH=%PATH%;PathToSqliteBin;PathToSqliteLib
> 
> Can do that. But the issue is simply trying create points from a DBF. This
> is important for my teaching next semester too. Insisting that students try
> to figure out SQLite isn't very feasible.

The idea is not to tell you to use sqlite from now on, just to test 
whether the problem really is with the dbf driver or whether it is 
something else. Trying it with a different database backend helps 
narrowing down the issue.

Could you also send me the dbf so that I can try ?


> I thought that the dbf error was fixed. If not, it is good to know that
> v.in.db doesn't work currently. We can just use v.in.ascii instead.

Glynn rewrote a section of the dbmi library, i.e. the one treating all 
database interaction (not only dbf), but recently a new bug was 
discovered and I have been able to narrow it down to the dbf driver, but 
not have had more time to work on it since. However, this did not 
involve a windows error message such as you have...

> 
> 
>>
>>>>> Also getting an error on gdal import complainging about a gcs.cvs file
>>>> Haven't used gdal import for a while in wingrass, so will test that.
> 
> Got this dealt with. Interestingly, trying to import a file with an
> incorrect format with v.in.ascii gives the same error as trying to import a
> dbf file with v.in db, using dbf format. I don't know if this helps debug,
> but maybe it is a clue.

Quite probably. What is the incorrect format ?


> 
>>>>> =====
>>>>>
>>>>> ERROR 4: Unable to open EPSG support file gcs.csv.
>>>>> Try setting the GDAL_DATA environment variable to point to the
>>>>> directory containing EPSG csv files.
>>>> Have you tried setting this ?
>>> How would we go about setting this?
>>
>> Try setting it in the grass63.bat file:
>>
>> set GDAL_DATA=
> 
> You mean leave this blank/empty? Or do you mean to point this variable to a
> valid location?

The latter.


>> But is this a GRASS variable or a GDAL variable ?
> 
> I have absolutely no idea.

This questions was directed more to Glynn than to you ;-)

Moritz

From mlennert at club.worldonline.be  Fri Nov  9 19:43:33 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Nov  9 19:48:53 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C359F4B7.348E8%michael.barton@asu.edu>
References: <C359F4B7.348E8%michael.barton@asu.edu>
Message-ID: <4734AA55.1060300@club.worldonline.be>

On 09/11/07 19:27, Michael Barton wrote:
> 
> 
> On 11/9/07 10:59 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
> 
>> On 09/11/07 18:41, Javier Fernandez wrote:
>>> Hi all, I have attached a word file with the problems that I find when I
>>> work with wingrass,
>> Thank you. Could you give the precise commands/actions you take to see
>> these errors ?
>>
>> e.g.:
>>> Problem 2: Unable to create points from a dbf. File: because a dbf error
>>>
>>>
>>> Output GIS
>>>
>>>
>>> NG: GRASS_TRUECOLOR status: TRUE
>>>
>>> PNG: collecting to file: C:\grassdata/Spain_utm_30n/PERMANENT/.tmp/928.0.ppm,
>>>
>>>      GRASS_WIDTH=575, GRASS_HEIGHT=484
>>>
>>> Unable to open vector map <Yaci@PERMANENT> on topology level 0
>> and then you show a screenshot of the windows error message. But what do
>> you do to get this result ? The above error message ("Unable to
>> open...") seems to be related to displaying a map, whereas you say it is
>> linked to v.to.db ?
> 
> The screenshot is an error caused by v.in.db.


Could you send the content of the 'technical information' (link in the 
error window) of the error reports ? I'm not sure I'll understand these 
(MS does not have the reputation of creating useful error messages...), 
but it's worth a try.

Moritz

From mlennert at club.worldonline.be  Fri Nov  9 19:53:22 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Nov  9 19:58:42 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <4734A138.8010903@club.worldonline.be>
References: <C359C9F4.282D2%michael.barton@asu.edu>
	<4734A138.8010903@club.worldonline.be>
Message-ID: <4734ACA2.5050807@club.worldonline.be>

On 09/11/07 19:04, Moritz Lennert wrote:
> On 09/11/07 16:25, Michael Barton wrote:
>> Hi Moritz,
>>
>> See some answers below. I'm copying Javi so that he can respond directly
>> too.
>>
>>
>> On 11/9/07 8:01 AM, "Moritz Lennert" <mlennert@club.worldonline.be> 
>> wrote:
>>
>>> On 09/11/07 15:32, Michael Barton wrote:
>>>
>>> Could you also tell us which version of windows this is ?
>>
>> Windows XP (I don't know if there is a specific version number or not. 
>> I can
>> ask him in the lab later this morning). 
> 
> I don't think this is necessary.
> 

Correcting myself: maybe it actually is as I imagine that there could be 
  a conflict between different versions of msvcrt.dll

Moritz

From hamish_nospam at yahoo.com  Fri Nov  9 20:43:50 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri Nov  9 20:43:52 2007
Subject: [GRASS-dev] help file incorrect for v.in.ascii
In-Reply-To: <C359F6E1.348E9%michael.barton@asu.edu>
Message-ID: <218300.61553.qm@web52709.mail.re2.yahoo.com>

Michael Barton wrote:

> I just tested something and found out that the helpfile is incorrect for
> v.in.ascii (although  my often faulty memory was correct).
> 
> The helpfile says that you can specify which columns are used for the x and
> y coordinates.

this is correct.

> However, this generates an error.

what's the error? sample input file?
 
> I remembered that in the past, the x and y columns MUST be the the first 2.

nope, I've never heard of that. I ran it with x&y as columns 2&3  yesterday.

> When we changed our text file to have x and y in columns 1 and 2, it reads
> the file fine.
> 
> We?re doing this with GRASS 6.3 on Windows AND Mac.


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From hamish_nospam at yahoo.com  Sat Nov 10 00:45:13 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Sat Nov 10 00:45:17 2007
Subject: [GRASS-dev] [Fwd: [winGRASS] Logging errors in GRASS WIN]
In-Reply-To: <47347269.1060703@club.worldonline.be>
Message-ID: <28717.31749.qm@web52708.mail.re2.yahoo.com>

David Sampson wrote:

> Is there a way to keep a logfile of errors running for the dialogues
> that pop up?

the typical way to collect WARNING: and ERROR:s from running modules and
libraries is to create a file called GIS_ERROR_LOG in your user's home
directory. Messages get logged to that. I would expect that Tcl specific errors
do not get logged there. This is generally used for GRASS scripts where you may
not be monitoring the scrolls of output in real time.

nb, this may be a good tool to see which/if a module/library error triggered
the Tcl error though.

> I would realy like to copy/paste text from the dialogues instead of
> retyping
 is this a limitation of TCL?

Not a limitation of Tcl, in Linux you can cut and paste that text just fine.
(ISTR on Debian the tcl module gui command line compose string wouldn't copy
before we changed a switch in the tcl code)
I've no idea what happens on MS Windows though.


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From hamish_nospam at yahoo.com  Sat Nov 10 01:00:17 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Sat Nov 10 01:00:22 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C359F2C5.348E3%michael.barton@asu.edu>
Message-ID: <985899.29868.qm@web52703.mail.re2.yahoo.com>

> >>>> ERROR 4: Unable to open EPSG support file gcs.csv.
> >>>> Try setting the GDAL_DATA environment variable to point to the
> >>>> directory containing EPSG csv files.
> >>> Have you tried setting this ?
..
> > Try setting it in the grass63.bat file:
> > 
> > set GDAL_DATA=
> 
> You mean leave this blank/empty? Or do you mean to point this variable to a
> valid location?

point it to the relevant C:\... path
 
> > But is this a GRASS variable or a GDAL variable ?
> 
> I have absolutely no idea.

it is an enviroment variable used by GDAL.


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From michael.barton at asu.edu  Sat Nov 10 07:33:51 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sat Nov 10 07:34:03 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <4734ACA2.5050807@club.worldonline.be>
Message-ID: <C35A9EDF.283C0%michael.barton@asu.edu>

Moritz,

At least some of this was solved this afternoon by my very enterprising RA.
It turns out that Javi was following the installation directions too
closely. 

He simply opened the zip file (in WinZip I think), and dragged the grass
folder onto his C: drive.

This won't produce a complete working GRASS (though very confusing, it will
produce an ALMOST working GRASS).

Isaac, had Javi reinstall by expanding EVERYTHING in the zip file into C:.
Apparently, there are some hidden files that also need to get onto the C:
drive, and that don't get there by just dragging the grass folder from zip
file. 

Ultimately, the most reliable thing, I guess, would be to create a
self-extracting archive (*.exe). But maybe you understand what when wrong (I
still don't know what is missing with the other installation method).

Still haven't tested everything, but the file selection and some other
things work now (as of 3pm when I had to leave the lab). Hope to find out if
v.in.db works too. 

Thanks for working with us on this.

Michael


On 11/9/07 11:53 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> On 09/11/07 19:04, Moritz Lennert wrote:
>> On 09/11/07 16:25, Michael Barton wrote:
>>> Hi Moritz,
>>> 
>>> See some answers below. I'm copying Javi so that he can respond directly
>>> too.
>>> 
>>> 
>>> On 11/9/07 8:01 AM, "Moritz Lennert" <mlennert@club.worldonline.be>
>>> wrote:
>>> 
>>>> On 09/11/07 15:32, Michael Barton wrote:
>>>> 
>>>> Could you also tell us which version of windows this is ?
>>> 
>>> Windows XP (I don't know if there is a specific version number or not.
>>> I can
>>> ask him in the lab later this morning).
>> 
>> I don't think this is necessary.
>> 
> 
> Correcting myself: maybe it actually is as I imagine that there could be
>   a conflict between different versions of msvcrt.dll
> 
> Moritz

__________________________________________
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 Nov 10 07:43:36 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sat Nov 10 07:43:44 2007
Subject: [GRASS-dev] help file incorrect for v.in.ascii
In-Reply-To: <218300.61553.qm@web52709.mail.re2.yahoo.com>
Message-ID: <C35AA128.283C6%michael.barton@asu.edu>




On 11/9/07 12:43 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

> Michael Barton wrote:
> 
>> I just tested something and found out that the helpfile is incorrect for
>> v.in.ascii (although  my often faulty memory was correct).
>> 
>> The helpfile says that you can specify which columns are used for the x and
>> y coordinates.
> 
> this is correct.
> 
>> However, this generates an error.
> 
> what's the error? sample input file?

The error is something about an incorrect number of columns. The file was a
very simple one for just 2 points

Originally

cat, x, y, string

When changed to 

x, y, cat, string

it worked fine.

This was compiled from cvs 6.3 last week.

Michael

>  
>> I remembered that in the past, the x and y columns MUST be the the first 2.
> 
> nope, I've never heard of that. I ran it with x&y as columns 2&3  yesterday.
> 
>> When we changed our text file to have x and y in columns 1 and 2, it reads
>> the file fine.
>> 
>> We?re doing this with GRASS 6.3 on Windows AND Mac.
> 
> 
> Hamish
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



From mlennert at club.worldonline.be  Sat Nov 10 11:18:05 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sat Nov 10 11:11:02 2007
Subject: [GRASS-dev] help file incorrect for v.in.ascii
In-Reply-To: <C35AA128.283C6%michael.barton@asu.edu>
References: <C35AA128.283C6%michael.barton@asu.edu>
Message-ID: <4735855D.6010609@club.worldonline.be>

Michael Barton wrote:
> 
> 
> On 11/9/07 12:43 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
> 
>> Michael Barton wrote:
>>
>>> I just tested something and found out that the helpfile is incorrect for
>>> v.in.ascii (although  my often faulty memory was correct).
>>>
>>> The helpfile says that you can specify which columns are used for the x and
>>> y coordinates.
>> this is correct.
>>
>>> However, this generates an error.
>> what's the error? sample input file?
> 
> The error is something about an incorrect number of columns. The file was a
> very simple one for just 2 points

Are you sure the column separator was defined correctly ? Whenever I got 
this error this was always the problem.

Moritz

From mlennert at club.worldonline.be  Sat Nov 10 12:31:57 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sat Nov 10 12:37:20 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C35A9EDF.283C0%michael.barton@asu.edu>
References: <C35A9EDF.283C0%michael.barton@asu.edu>
Message-ID: <1232.85.10.67.126.1194694317.squirrel@geog-pc40.ulb.ac.be>

On Sat, November 10, 2007 07:33, Michael Barton wrote:
> Moritz,
>
> At least some of this was solved this afternoon by my very enterprising
> RA.
> It turns out that Javi was following the installation directions too
> closely.
>
> He simply opened the zip file (in WinZip I think), and dragged the grass
> folder onto his C: drive.
>
> This won't produce a complete working GRASS (though very confusing, it
> will
> produce an ALMOST working GRASS).
>
> Isaac, had Javi reinstall by expanding EVERYTHING in the zip file into C:.
> Apparently, there are some hidden files that also need to get onto the C:
> drive, and that don't get there by just dragging the grass folder from zip
> file.
>
> Ultimately, the most reliable thing, I guess, would be to create a
> self-extracting archive (*.exe). But maybe you understand what when wrong
> (I
> still don't know what is missing with the other installation method).

I don't either. I tried both and the size of the two directories is
exactly the same. And I don't see the error. Can Javie reproduce the
problems by reinstalling via dragging from the zip ? Or maybe it was just
something that went wrong during the install...

> Still haven't tested everything, but the file selection and some other
> things work now (as of 3pm when I had to leave the lab). Hope to find out
> if
> v.in.db works too.

Ok, keep me posted. If it still causes problems, let me know (and send me
a sample dbf file to test).

The dbf bug mentioned earlier seems to be solved and will be in a new
binary which I hope to put on the site today or tomorrow.

Thanks,

Moritz

From hamish_nospam at yahoo.com  Sat Nov 10 12:44:39 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Sat Nov 10 12:44:41 2007
Subject: [GRASS-dev] help file incorrect for v.in.ascii
In-Reply-To: <C35AA128.283C6%michael.barton@asu.edu>
Message-ID: <340853.65474.qm@web52705.mail.re2.yahoo.com>

Michael Barton wrote:
> which columns are used for the x and y coordinates.
..
> >> However, this generates an error.
> > 
> > what's the error? sample input file?
> 
> The error is something about an incorrect number of columns. The file was a
> very simple one for just 2 points
> 
> Originally
> 
> cat, x, y, string
> 
> When changed to 
> 
> x, y, cat, string
> 
> it worked fine.
> 
> This was compiled from cvs 6.3 last week.

It is hard to know why without seeing a sample of the file that fails and the
exact command line used.

perhaps a stray extra or missing fs after the data on some line?

blank-but-for-fs line at the end of the file?


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From glynn at gclements.plus.com  Sat Nov 10 14:54:59 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sat Nov 10 14:55:15 2007
Subject: [GRASS-dev] Re: [Qgis-developer] [patch] MSVC patch (less warnings
	and GRASS)
In-Reply-To: <20071110011406.GA14689@norbit.de>
References: <20071104205432.GB12370@norbit.de>
	<d368056f0711041723m3b9df218jfe5b2592d854061c@mail.gmail.com>
	<20071106001452.GA15263@norbit.de> <20071107031023.GF8866@fbk.eu>
	<20071107083415.GA21382@norbit.de> <20071107102204.GA13398@fbk.eu>
	<18225.39192.84242.412031@cerise.gclements.plus.com>
	<20071110011406.GA14689@norbit.de>
Message-ID: <18229.47155.938532.808969@cerise.gclements.plus.com>


J?rgen E. Fischer wrote:

> > AFAICT, GRASS uses __STDC__ in a small number of headers to decide
> > whether to use ANSI-style prototypes. This is pointless; if you have a
> > compiler which doesn't understand them, you aren't going to be able to
> > compile GRASS.
>  
> > I'll fix both of these issues today.
> 
> Thanks.
> 
> Unfortunatley the MinGW DLLs didn't seem to work as well as I hoped.  I
> decided to build them with MSVC - with CMake out of the QGIS sources.
> To do that I had to modify the libs a bit.
> 
> The patch isn't probably of any use to GRASS itself, but AFAICS it
> doesn't do any harm either (not sure about the __BEGIN_DECLS/__END_DECLS
> stuff).
> 
> What do you think?

I've committed all the "harmless" changes, i.e. removing the
__{BEGIN,END}_DECLS and C99 variable declarations, and changing
strcasecmp() to G_strcasecmp().

I'm not keen on some of the other changes. I'd rather keep portability
issues in specific library functions than sprinkled around.

E.g. the S_ISDIR() stuff suggessts that we need a G_is_directory()
function. Similarly, a G_rmdir() function.

I'm not sure about the rewinddir() issue:

> Index: lib/db/dbmi_base/dirent.c
> Index: lib/gis/list.c

> +#ifndef _MSC_VER
>      rewinddir(dp);
> +#else
> +    closedir(dp);
> +    dp = opendir(dirname);
> +#endif

AFAICT, Windows itself doesn't have any of the dirent functions;
they're normally provided by some form of compatibility layer. In that
case, it would be preferable to use a library which supports
rewinddir().

Or failing that, just unconditionally re-open the directory rather
than only doing so on Windows; I doubt that efficiency is that great a
priority.

Both re-opening the directory and rewinddir() create a race condition,
i.e. you could get more entries on the second pass. G_list() will
typically segfault if this happens. It would be better to change the
code to dynamically re-allocate the array, eliminating the need to
re-scan the directory.

The chmod() call in lib/db/dbmi_base/login.c should probably just be
skipped on Windows. The purpose is to prevent other users from reading
the password stored in that file, so the Windows version is rather
pointless:

> +#ifdef _MSC_VER
> +    _chmod( file, S_IREAD | S_IWRITE );
> +#else
>      chmod ( file, S_IRUSR | S_IWUSR );
> +#endif

Creating a proper ACL for that file would be better, but I don't know
how to do that.

Regarding the DBMI RPC mechanism:

> Index: lib/db/dbmi_base/xdr.c

> -#ifdef __MINGW32__
> +#if defined(__MINGW32__) && !defined(_MSC_VER)
>  #define USE_STDIO 0
>  #define USE_READN 1
>  #else

This change was made because the MSVCRT fread() and fwrite() functions
didn't seem to work on pipes. We observed data corruption, which went
away when switching to read() and write(). I have no idea why this
would be any different when compiling with MSVC; have you checked that
using stdio actually works?

This:

> Index: lib/gis/G.h

> +#ifdef _MSC_VER
> +#include <basetsd.h>
> +typedef SSIZE_T ssize_t;
> +#endif //_MSC_VER
> +

doesn't belong in G.h, as that file doesn't reference ssize_t.

AFAICT, it's only used in get_row.c. The MSDN documentation says that
their read() returns "int", so we should probably use that:

	http://msdn2.microsoft.com/en-us/library/wyssk1bs(VS.80).aspx

> Index: lib/gis/error.c
> Index: lib/gis/tempfile.c

> +#ifdef _MSC_VER
> +#include <windows.h>
> +#define getpid() GetCurrentProcessId()
> +#endif

This suggests a need for a G_getpid() function.

> Index: lib/gis/parser.c

What about G_parser() is causing problems with MSVC? Obviously, we
can't disable that function in GRASS itself.

> Index: lib/gis/spawn.c
> Index: lib/gis/system.c

>  #ifndef __MINGW32__
>  #include <sys/wait.h>
> +#else
> +#include <process.h>
>  #endif

For legibility, the sense should probably be switched, i.e.:

	#ifdef __MINGW32__
	#include <process.h>
	#else
	#include <sys/wait.h>
	#endif

Or the tests should be separated, i.e.:

	#ifndef __MINGW32__
	#include <sys/wait.h>
	#endif
	#ifdef __MINGW32__
	#include <process.h>
	#endif

-- 
Glynn Clements <glynn@gclements.plus.com>

From michael.barton at asu.edu  Sat Nov 10 17:33:24 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sat Nov 10 17:33:33 2007
Subject: [GRASS-dev] help file incorrect for v.in.ascii
In-Reply-To: <4735855D.6010609@club.worldonline.be>
Message-ID: <C35B2B64.283E9%michael.barton@asu.edu>




On 11/10/07 3:18 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> Michael Barton wrote:
>> 
>> 
>> On 11/9/07 12:43 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
>> 
>>> Michael Barton wrote:
>>> 
>>>> I just tested something and found out that the helpfile is incorrect for
>>>> v.in.ascii (although  my often faulty memory was correct).
>>>> 
>>>> The helpfile says that you can specify which columns are used for the x and
>>>> y coordinates.
>>> this is correct.
>>> 
>>>> However, this generates an error.
>>> what's the error? sample input file?
>> 
>> The error is something about an incorrect number of columns. The file was a
>> very simple one for just 2 points
> 
> Are you sure the column separator was defined correctly ? Whenever I got
> this error this was always the problem.

Absolutely. We used the same column separator and same way of specifying it
in both cases.

Michael

> 
> Moritz
> 

__________________________________________
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 Nov 10 17:37:53 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sat Nov 10 17:38:14 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <1232.85.10.67.126.1194694317.squirrel@geog-pc40.ulb.ac.be>
Message-ID: <C35B2C71.283EC%michael.barton@asu.edu>




On 11/10/07 4:31 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> On Sat, November 10, 2007 07:33, Michael Barton wrote:
>> Moritz,
>> 
>> At least some of this was solved this afternoon by my very enterprising
>> RA.
>> It turns out that Javi was following the installation directions too
>> closely.
>> 
>> He simply opened the zip file (in WinZip I think), and dragged the grass
>> folder onto his C: drive.
>> 
>> This won't produce a complete working GRASS (though very confusing, it
>> will
>> produce an ALMOST working GRASS).
>> 
>> Isaac, had Javi reinstall by expanding EVERYTHING in the zip file into C:.
>> Apparently, there are some hidden files that also need to get onto the C:
>> drive, and that don't get there by just dragging the grass folder from zip
>> file.
>> 
>> Ultimately, the most reliable thing, I guess, would be to create a
>> self-extracting archive (*.exe). But maybe you understand what when wrong
>> (I
>> still don't know what is missing with the other installation method).
> 
> I don't either. I tried both and the size of the two directories is
> exactly the same. And I don't see the error. Can Javie reproduce the
> problems by reinstalling via dragging from the zip ? Or maybe it was just
> something that went wrong during the install...

We tried installing twice the old way. Then when Isaac had him install the
other way, it worked. Isaac said that there were some files preceded by 2
dots (i.e., ..file) that *didn't* get copied the first times. He is guessing
that there are some Unix files that don't get installed properly under XP by
simply opening the zip file and dragging the content. It needs to be
completely unzipped.

> 
>> Still haven't tested everything, but the file selection and some other
>> things work now (as of 3pm when I had to leave the lab). Hope to find out
>> if
>> v.in.db works too.
> 
> Ok, keep me posted. If it still causes problems, let me know (and send me
> a sample dbf file to test).
> 

Sure. Hope it's fixed.

> The dbf bug mentioned earlier seems to be solved and will be in a new
> binary which I hope to put on the site today or tomorrow.

That's great. Thanks. I'll if Javi wants to risk another installation ;-)

Michael

> 
> Thanks,
> 
> Moritz
> 

__________________________________________
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 Nov 10 17:38:34 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sat Nov 10 17:38:40 2007
Subject: [GRASS-dev] help file incorrect for v.in.ascii
In-Reply-To: <340853.65474.qm@web52705.mail.re2.yahoo.com>
Message-ID: <C35B2C9A.283ED%michael.barton@asu.edu>

We'll test some more just to be sure.

Michael


On 11/10/07 4:44 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

> Michael Barton wrote:
>> which columns are used for the x and y coordinates.
> ..
>>>> However, this generates an error.
>>> 
>>> what's the error? sample input file?
>> 
>> The error is something about an incorrect number of columns. The file was a
>> very simple one for just 2 points
>> 
>> Originally
>> 
>> cat, x, y, string
>> 
>> When changed to 
>> 
>> x, y, cat, string
>> 
>> it worked fine.
>> 
>> This was compiled from cvs 6.3 last week.
> 
> It is hard to know why without seeing a sample of the file that fails and the
> exact command line used.
> 
> perhaps a stray extra or missing fs after the data on some line?
> 
> blank-but-for-fs line at the end of the file?
> 
> 
> Hamish
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


From woklist at kyngchaos.com  Sat Nov 10 21:21:52 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Sat Nov 10 21:22:13 2007
Subject: [GRASS-dev] X11 trouble on OSX 10.5
Message-ID: <D51640E5-AE28-4535-9DC5-2FDDD3A9E52E@kyngchaos.com>

This seems to be an OSX 10.5 Leopard problem, so this is a heads-up,  
but maybe something similar has been seen on other platforms?

-----
some background:

Leopard updated to X11R7 - Tiger, Panther have R6.

Apple dropped the "Rn" part of the name, so it's just /usr/X11 now.   
The side effect makes new X11-linked software incompatible with  
Tiger.  There is also a symlink from X11R6 to X11 so old Tiger X11  
software can run on Leopard (assuming they're compatible).

It looks like Tiger's default is to build multi-module libraries (one  
for each object file), while now it's single-module libraries.
-----

First, linking -L/usr/X11/lib -lGL on OSX causes a weird link problem:

ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib

After some digging around, this appears to be a common problem on  
Leopard, and the workaround is to use the -dylib_file flag:

-dylib_file /usr/X11/lib/libGL.dylib:/usr/X11/lib/libGL.dylib

So, this works for GRASS/NVIZ.  But now there is another problem -  
maybe OSX-specific. Togl can't find ANY _glX* symbols in libGL:

Undefined symbols for architecture i386:
   "_glViewport", referenced from:
       _Togl_EventProc in togl.o
       _Togl_EventProc in togl.o
   "_glXChooseVisual", referenced from:
       _Togl_CreateWindow in togl.o
   "_glPixelStorei", referenced from:
       _Togl_DumpToEpsFile in togl.o
       _Togl_DumpToEpsFile in togl.o
...
...
...

Linking with -undefined dynamic_lookup solves the build problem.  NVIZ  
also runs, so it's finding those symbols at runtime.  Though there are  
some visual glitches in the view pane that are mostly cleared up by  
resizing the window.


Another issue with X11/Tcltk in Leopard - gis.m won't run.  I get an  
error:

GRASS 6.3.cvs (spearfish60):~ > X Error of failed request:  BadMatch  
(invalid parameter attributes)
   Major opcode of failed request:  70 (X_PolyFillRectangle)
   Serial number of failed request:  2296
   Current serial number in output stream:  2337

Maybe this is a problem with Tcltk 8.5?  Or the newer X11?  or both?   
The error is meaningless to me, and there is no crash+crashlog to help  
figure it out.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

The equator is so long, it could encircle the earth completely once.

From glynn at gclements.plus.com  Sun Nov 11 00:12:08 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Nov 11 00:12:10 2007
Subject: [GRASS-dev] X11 trouble on OSX 10.5
In-Reply-To: <D51640E5-AE28-4535-9DC5-2FDDD3A9E52E@kyngchaos.com>
References: <D51640E5-AE28-4535-9DC5-2FDDD3A9E52E@kyngchaos.com>
Message-ID: <18230.15048.182647.628316@cerise.gclements.plus.com>


William Kyngesburye wrote:

> But now there is another problem -  
> maybe OSX-specific. Togl can't find ANY _glX* symbols in libGL:
> 
> Undefined symbols for architecture i386:
>    "_glViewport", referenced from:
>        _Togl_EventProc in togl.o
>        _Togl_EventProc in togl.o
>    "_glXChooseVisual", referenced from:
>        _Togl_CreateWindow in togl.o
>    "_glPixelStorei", referenced from:
>        _Togl_DumpToEpsFile in togl.o
>        _Togl_DumpToEpsFile in togl.o

The first and last ones aren't GLX functions, they're standard OpenGL
functions, so it isn't just GLX that's the problem.

> Another issue with X11/Tcltk in Leopard - gis.m won't run.  I get an  
> error:
> 
> GRASS 6.3.cvs (spearfish60):~ > X Error of failed request:  BadMatch  
> (invalid parameter attributes)
>    Major opcode of failed request:  70 (X_PolyFillRectangle)
>    Serial number of failed request:  2296
>    Current serial number in output stream:  2337
> 
> Maybe this is a problem with Tcltk 8.5?  Or the newer X11?  or both?   
> The error is meaningless to me, and there is no crash+crashlog to help  
> figure it out.

That can only be a Tk error. It's almost impossible to say what the
problem is; BadMatch can mean just about anything:

       BadMatch  Some argument or pair of arguments has the correct type and
                 range but fails to match in some other way required by the
                 request.

IIRC, X_PolyFillRectangle corresponds to XFillRectangles, which most
GUI toolkits use extensively.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Sun Nov 11 00:38:54 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Nov 11 00:38:57 2007
Subject: [GRASS-dev] Re: [Qgis-developer] [patch] MSVC patch (less warnings
	and GRASS)
In-Reply-To: <20071110210447.GA21078@norbit.de>
References: <20071104205432.GB12370@norbit.de>
	<d368056f0711041723m3b9df218jfe5b2592d854061c@mail.gmail.com>
	<20071106001452.GA15263@norbit.de> <20071107031023.GF8866@fbk.eu>
	<20071107083415.GA21382@norbit.de> <20071107102204.GA13398@fbk.eu>
	<18225.39192.84242.412031@cerise.gclements.plus.com>
	<20071110011406.GA14689@norbit.de>
	<18229.47155.938532.808969@cerise.gclements.plus.com>
	<20071110210447.GA21078@norbit.de>
Message-ID: <18230.16654.502064.296467@cerise.gclements.plus.com>


J?rgen E. Fischer wrote:

> > E.g. the S_ISDIR() stuff suggessts that we need a G_is_directory()
> > function. Similarly, a G_rmdir() function.
> 
> lib/db/dbmi_base/isdir.c doesn't include unistd.h, so I still need to
> define S_ISDIR there as long as there is no G_is_directory()

The Linux stat(2) manpage implies that <unistd.h> should be included
for stat(), so I'll add that.

> > I'm not sure about the rewinddir() issue:
> > > Index: lib/db/dbmi_base/dirent.c
> > > Index: lib/gis/list.c
> 
> dirent.h is a wrapper I found that maps opendir/readdir/closedir to
> FindFirstFile/FindNextFile/FindClose.  It used to have no rewinddir(), which
> I've added now.

The dirent stuff is about the only actual code which is part of MinGW. 
It provides a fair amount of Unix compatibility in its headers, but it
relies upon MSVCRT for the actual functions.

> > Regarding the DBMI RPC mechanism:
> > > Index: lib/db/dbmi_base/xdr.c
> 
> I compile lib/db/dbmi_base/xdr.c without __MINGW32__ now.  I didn't check if
> fread() works, I'm not even sure the QGIS uses that at all.  I'll keep you
> posted if I run into trouble.

It's fundamental to the DBMI subsystem. The individual DB drivers
(PostgreSQL, MySQL, DBF, SQLite, ODBC) are separate processes. When a
db.* or v.* module initialises DBMI, the driver is spawned as a child
process with its stdin/stdout connected via pipes.

The various DBMI functions call the driver via a home-grown RPC
mechanism. This used to use XDR, but we ran into problems with the
xdrstdio_* not working, apparently due to fread/fwrite not working
with pipes. When the sunrpc library was hacked to use read/write, the
problem went away.

Rather than requiring a hacked sunrpc library, we just eliminated the
use of XDR. As both the client and the driver run on the same system,
there's no need for the RPC protocol to be portable.

> > > Index: lib/gis/parser.c
> > What about G_parser() is causing problems with MSVC? Obviously, we
> > can't disable that function in GRASS itself.
> 
> No, that was to avoid additional dependencies - at least I thought so.
> But replacing popen/pclose with G_popen and G_pclose is enough to get
> the DLL build with G_parser().

Right. Although that should probably be changed, I'm not especially
confident in GRASS' G_popen() implementation, and that code is
relatively important.

[FWIW, GRASS uses G_popen() in two files, lib/gis/error.c and
lib/gis/list.c, versus 27 files for popen(). Although more than half
of those are accounted for by i.ortho.photo (6 files) and (10 files).]

It's unfortunate that all of this has arisen right now, as:

a) We've recently started preparing for a 6.3.0 release, and
b) my Windows XP system is (still) out of commission due to a dead motherboard.

> So following is what's left of the "not so keen" part of the patch . The first
> part would be replaced by G_is_directory() later and the second looks ok as it
> is, I suppose.
> 
> Index: lib/db/dbmi_base/isdir.c

Hopefully this should be fixed by including <unistd.h>.

> Index: lib/gis/parser.c

I think that I'll change this to G_popen() and see how it goes.

-- 
Glynn Clements <glynn@gclements.plus.com>

From mlennert at club.worldonline.be  Sun Nov 11 01:10:29 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sun Nov 11 01:16:00 2007
Subject: [GRASS-dev] select issue with wingrass
Message-ID: <2234.85.10.67.126.1194739829.squirrel@geog-pc40.ulb.ac.be>

On Sat, November 10, 2007 17:37, Michael Barton wrote:
> We tried installing twice the old way. Then when Isaac had him install the
> other way, it worked. Isaac said that there were some files preceded by 2
> dots (i.e., ..file) that *didn't* get copied the first times. He is
> guessing
> that there are some Unix files that don't get installed properly under XP
> by
> simply opening the zip file and dragging the content. It needs to be
> completely unzipped.
>

Today, I suddenly have seen the problem appear and I don't really
understand where this comes from:

The only situation where I get the select window to work, is when I launch
grass via a shortcut to the grass63.bat and this shortcut is configured to
use c:\ as the working directory. Any other working directory (including
the default of the shortcut which is c:\grass\bin) gives me the empty
select window Javi as been seeing. The same when I click directly on
c:\grass\bin\grass63.bat. When I start grass in text mode and then launch
gis.m from the command line, it is exactly the same: I can only see the
maps in the select window if the current directory is c:\ when I launch
gis.m.

So it seems to be linked to gis.m. Have there been any changes recently
that might explain this ? I have never even worried about the working
directory before, except for testing whether setting %USERPROFILE% in the
shortcut properties works and it did at the time. Now it doesn't
anymore...

Javi and Michael, could you also test whether this corresponds to what is
happening in your case ?

Moritz

From woklist at kyngchaos.com  Sun Nov 11 02:32:09 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Sun Nov 11 02:33:38 2007
Subject: [GRASS-dev] X11 trouble on OSX 10.5
In-Reply-To: <18230.15048.182647.628316@cerise.gclements.plus.com>
References: <D51640E5-AE28-4535-9DC5-2FDDD3A9E52E@kyngchaos.com>
	<18230.15048.182647.628316@cerise.gclements.plus.com>
Message-ID: <C580DF6E-4376-45EC-A846-81A52A5AC6C6@kyngchaos.com>

On Nov 10, 2007, at 5:12 PM, Glynn Clements wrote:

> William Kyngesburye wrote:
>
>> But now there is another problem -
>> maybe OSX-specific. Togl can't find ANY _glX* symbols in libGL:
>>
>> Undefined symbols for architecture i386:
>>   "_glViewport", referenced from:
>>       _Togl_EventProc in togl.o
>>       _Togl_EventProc in togl.o
>>   "_glXChooseVisual", referenced from:
>>       _Togl_CreateWindow in togl.o
>>   "_glPixelStorei", referenced from:
>>       _Togl_DumpToEpsFile in togl.o
>>       _Togl_DumpToEpsFile in togl.o
>
> The first and last ones aren't GLX functions, they're standard OpenGL
> functions, so it isn't just GLX that's the problem.
>
Tired brain.  I saw a lot of glx in there (about a dozen or so more  
that I didn't copy-n-paste).

>> Another issue with X11/Tcltk in Leopard - gis.m won't run.  I get an
>> error:
>>
>> GRASS 6.3.cvs (spearfish60):~ > X Error of failed request:  BadMatch
>> (invalid parameter attributes)
>>   Major opcode of failed request:  70 (X_PolyFillRectangle)
>>   Serial number of failed request:  2296
>>   Current serial number in output stream:  2337
>>
>> Maybe this is a problem with Tcltk 8.5?  Or the newer X11?  or both?
>> The error is meaningless to me, and there is no crash+crashlog to  
>> help
>> figure it out.
>
> That can only be a Tk error. It's almost impossible to say what the
> problem is; BadMatch can mean just about anything:
>
>       BadMatch  Some argument or pair of arguments has the correct  
> type and
>                 range but fails to match in some other way required  
> by the
>                 request.
>
> IIRC, X_PolyFillRectangle corresponds to XFillRectangles, which most
> GUI toolkits use extensively.
>
More info, I forgot: the GUI splash displays just before this error.

Definitely something wrong in TclTk 8.5.  The GUI runs with 8.4  
(32bits).

The reason I tried 8.5 is that 8.4 does not build 64bits on OSX  
(configure actually removes any 64bit flags you try to add).  I  
suppose the GUI itself doesn't need to run in 64bits, as long as the  
modules are 64bits they will run as such.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying,  
fighting, and all for things that the beasts of the jungle would not  
deign to possess - money to purchase the effeminate pleasures of  
weaklings.  And yet withal bound down by silly customs that make them  
slaves to their unhappy lot while firm in the belief that they be the  
lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan


From michael.barton at asu.edu  Mon Nov 12 06:56:15 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Nov 12 06:56:32 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <2234.85.10.67.126.1194739829.squirrel@geog-pc40.ulb.ac.be>
Message-ID: <C35D390F.28421%michael.barton@asu.edu>

Moritz,

I'm glad that you've been able to verify the select issue and find out more
about how it happens.

There have been no changes to gis.m that might cause this as far as I know.
I made some changes to select.tcl several months back to fix the
multi-select option that had been broken by updates several months before
that. In the part that I changed, I replaced unix-based regexp statements
with pure TclTk list parsing. If anything, this should make the selection
tools work better with Windows. But this all was some time ago. If there
have been any changes by others that might cause this, I'm not aware of
them.

We've now encountered a couple of other items, even though select is
working, at least in some settings.

It appears that r.mapcalc is NOT working. We get an error with even the
simplest of mapcalc statements. Javi will send the error message tonight or
tomorrow, but it is a red herring IMHO, stating that it is missing an "=".
We have the same error if we run r.mapcalc via the TclTk interface
(r.mapcalculator) or run it from the console command line. Other commands
work find from the console command line. This is *critical*, of course, as
r.mapcalc is very important to GRASS analysis and map management.

Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
anything from the error message box or even make the box bigger so as to
show more of the error details. Is there a way to log this to send to you,
as it is quite long?

Interestingly, we are getting the *same* error produced by v.in.db when
running r.contour. 

We did NOT get an error running r.to.vect, v.in.region, or v.random. So it
is not just something that happens anytime we try to create a vector. Maybe
this is helpful.

Thanks for taking the time to help troubleshoot this.

Michael


On 11/10/07 5:10 PM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

> On Sat, November 10, 2007 17:37, Michael Barton wrote:
>> We tried installing twice the old way. Then when Isaac had him install the
>> other way, it worked. Isaac said that there were some files preceded by 2
>> dots (i.e., ..file) that *didn't* get copied the first times. He is
>> guessing
>> that there are some Unix files that don't get installed properly under XP
>> by
>> simply opening the zip file and dragging the content. It needs to be
>> completely unzipped.
>> 
> 
> Today, I suddenly have seen the problem appear and I don't really
> understand where this comes from:
> 
> The only situation where I get the select window to work, is when I launch
> grass via a shortcut to the grass63.bat and this shortcut is configured to
> use c:\ as the working directory. Any other working directory (including
> the default of the shortcut which is c:\grass\bin) gives me the empty
> select window Javi as been seeing. The same when I click directly on
> c:\grass\bin\grass63.bat. When I start grass in text mode and then launch
> gis.m from the command line, it is exactly the same: I can only see the
> maps in the select window if the current directory is c:\ when I launch
> gis.m.
> 
> So it seems to be linked to gis.m. Have there been any changes recently
> that might explain this ? I have never even worried about the working
> directory before, except for testing whether setting %USERPROFILE% in the
> shortcut properties works and it did at the time. Now it doesn't
> anymore...
> 
> Javi and Michael, could you also test whether this corresponds to what is
> happening in your case ?
> 
> Moritz
> 

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


From hamish_nospam at yahoo.com  Mon Nov 12 09:26:20 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Nov 12 09:26:22 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C35D390F.28421%michael.barton@asu.edu>
Message-ID: <828576.63912.qm@web52710.mail.re2.yahoo.com>

Michael Barton wrote:
> Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
> anything from the error message box or even make the box bigger so as to
> show more of the error details. Is there a way to log this to send to you,
> as it is quite long?

create a screenshot with Alt-PrintScreen then paste into a paint program?


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From glynn at gclements.plus.com  Mon Nov 12 12:14:56 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Nov 12 12:15:31 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C35D390F.28421%michael.barton@asu.edu>
References: <2234.85.10.67.126.1194739829.squirrel@geog-pc40.ulb.ac.be>
	<C35D390F.28421%michael.barton@asu.edu>
Message-ID: <18232.13744.216637.461647@cerise.gclements.plus.com>


Michael Barton wrote:

> It appears that r.mapcalc is NOT working. We get an error with even the
> simplest of mapcalc statements. Javi will send the error message tonight or
> tomorrow, but it is a red herring IMHO, stating that it is missing an "=".
> We have the same error if we run r.mapcalc via the TclTk interface
> (r.mapcalculator) or run it from the console command line. Other commands
> work find from the console command line. This is *critical*, of course, as
> r.mapcalc is very important to GRASS analysis and map management.

FWIW, the only r.mapcalc files which have changed in the last three
months are:

	Makefile
	map3.c
	r.mapcalc.html
	r3.mapcalc.html

The Makefile changes were part of the parallel build effort, and don't
change what is compiled or which switches are used. The map3.c changes
are just standardisation of messages, and only affect r3.mapcalc.

I presume that this is related to your local environment; otherwise, I
would expect to see other people reporting it.

-- 
Glynn Clements <glynn@gclements.plus.com>

From michael.barton at asu.edu  Mon Nov 12 16:49:54 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Nov 12 16:50:02 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <828576.63912.qm@web52710.mail.re2.yahoo.com>
Message-ID: <C35DC432.28430%michael.barton@asu.edu>




On 11/12/07 1:26 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

> Michael Barton wrote:
>> Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
>> anything from the error message box or even make the box bigger so as to
>> show more of the error details. Is there a way to log this to send to you,
>> as it is quite long?
> 
> create a screenshot with Alt-PrintScreen then paste into a paint program?

We've done that, but it's not very helpful. It is a very long error message
and Windows only presents a small, non-resizable window.

Michael

> 
> 
> Hamish
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


From michael.barton at asu.edu  Mon Nov 12 17:04:59 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Nov 12 17:05:41 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <18232.13744.216637.461647@cerise.gclements.plus.com>
Message-ID: <C35DC7BB.28432%michael.barton@asu.edu>




On 11/12/07 4:14 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> It appears that r.mapcalc is NOT working. We get an error with even the
>> simplest of mapcalc statements. Javi will send the error message tonight or
>> tomorrow, but it is a red herring IMHO, stating that it is missing an "=".
>> We have the same error if we run r.mapcalc via the TclTk interface
>> (r.mapcalculator) or run it from the console command line. Other commands
>> work find from the console command line. This is *critical*, of course, as
>> r.mapcalc is very important to GRASS analysis and map management.
> 
> FWIW, the only r.mapcalc files which have changed in the last three
> months are:
> 
> Makefile
> map3.c
> r.mapcalc.html
> r3.mapcalc.html
> 
> The Makefile changes were part of the parallel build effort, and don't
> change what is compiled or which switches are used. The map3.c changes
> are just standardisation of messages, and only affect r3.mapcalc.
> 
> I presume that this is related to your local environment; otherwise, I
> would expect to see other people reporting it.

Unfortunately, not many people testing new WinGRASS alpha builds yet I fear.

I did some more tests this morning, this time on my Mac and may have
discovered the cause of the error.

For the current WinGRASS binary, it is necessary to use the command console
for command-line use of GRASS.

We received an error with the following simple mapcalc statements

r.mapcalc 'frict=1'
r.mapcalc 'test=pendiente*2'

It turns out that you cannot use single quotes in this context. You need to
use regular quotes. So the way to specify the same mapcalc statements from
the GUI command console is...

r.mapcalc "frict=1"
r.mapcalc "test=pendiente*2"

I thought we had tried double quotes too, but maybe we didn't. I'll wait for
Javi to check email and test. The worrisome thing is that we initially used
the GUI map calculator from the menu and got an error. I tried it this
morning on my Mac and did not get an error.

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 Nov 12 17:13:40 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Nov 12 17:13:51 2007
Subject: [GRASS-dev] X11 trouble on OSX 10.5
In-Reply-To: <C580DF6E-4376-45EC-A846-81A52A5AC6C6@kyngchaos.com>
Message-ID: <C35DC9C4.28437%michael.barton@asu.edu>

This sounds like sort of good news. No reason for the GUI to run in 64 bit
mode AFAICT. It might make the displays run a tiny bit faster, but most of
any display delay is on the GRASS side rendering the PPM to display in
TclTk. 

One Mac issue I need to mention. In the current cvs version (on 10.4) GRASS
help no longer is listed in my Help Library, although the GRASS addons help
IS listed. It's not a huge issue as help comes up OK from within GRASS, but
it was handy having it in the library listing too.

Michael


On 11/10/07 6:32 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

> On Nov 10, 2007, at 5:12 PM, Glynn Clements wrote:
> 
>> William Kyngesburye wrote:
>> 
>>> But now there is another problem -
>>> maybe OSX-specific. Togl can't find ANY _glX* symbols in libGL:
>>> 
>>> Undefined symbols for architecture i386:
>>>   "_glViewport", referenced from:
>>>       _Togl_EventProc in togl.o
>>>       _Togl_EventProc in togl.o
>>>   "_glXChooseVisual", referenced from:
>>>       _Togl_CreateWindow in togl.o
>>>   "_glPixelStorei", referenced from:
>>>       _Togl_DumpToEpsFile in togl.o
>>>       _Togl_DumpToEpsFile in togl.o
>> 
>> The first and last ones aren't GLX functions, they're standard OpenGL
>> functions, so it isn't just GLX that's the problem.
>> 
> Tired brain.  I saw a lot of glx in there (about a dozen or so more
> that I didn't copy-n-paste).
> 
>>> Another issue with X11/Tcltk in Leopard - gis.m won't run.  I get an
>>> error:
>>> 
>>> GRASS 6.3.cvs (spearfish60):~ > X Error of failed request:  BadMatch
>>> (invalid parameter attributes)
>>>   Major opcode of failed request:  70 (X_PolyFillRectangle)
>>>   Serial number of failed request:  2296
>>>   Current serial number in output stream:  2337
>>> 
>>> Maybe this is a problem with Tcltk 8.5?  Or the newer X11?  or both?
>>> The error is meaningless to me, and there is no crash+crashlog to
>>> help
>>> figure it out.
>> 
>> That can only be a Tk error. It's almost impossible to say what the
>> problem is; BadMatch can mean just about anything:
>> 
>>       BadMatch  Some argument or pair of arguments has the correct
>> type and
>>                 range but fails to match in some other way required
>> by the
>>                 request.
>> 
>> IIRC, X_PolyFillRectangle corresponds to XFillRectangles, which most
>> GUI toolkits use extensively.
>> 
> More info, I forgot: the GUI splash displays just before this error.
> 
> Definitely something wrong in TclTk 8.5.  The GUI runs with 8.4
> (32bits).
> 
> The reason I tried 8.5 is that 8.4 does not build 64bits on OSX
> (configure actually removes any 64bit flags you try to add).  I
> suppose the GUI itself doesn't need to run in 64bits, as long as the
> modules are 64bits they will run as such.
> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
> 
> "Mon Dieu! but they are all alike.  Cheating, murdering, lying,
> fighting, and all for things that the beasts of the jungle would not
> deign to possess - money to purchase the effeminate pleasures of
> weaklings.  And yet withal bound down by silly customs that make them
> slaves to their unhappy lot while firm in the belief that they be the
> lords of creation enjoying the only real pleasures of existence....
> 
> - the wisdom of Tarzan
> 
> 
> 

__________________________________________
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 benjamin.ducke at ufg.uni-kiel.de  Mon Nov 12 17:42:12 2007
From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke)
Date: Mon Nov 12 17:43:00 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C35DC7BB.28432%michael.barton@asu.edu>
References: <C35DC7BB.28432%michael.barton@asu.edu>
Message-ID: <47388264.2070207@ufg.uni-kiel.de>

> 
> We received an error with the following simple mapcalc statements
> 
> r.mapcalc 'frict=1'
> r.mapcalc 'test=pendiente*2'
> 
> It turns out that you cannot use single quotes in this context. You need to
> use regular quotes. So the way to specify the same mapcalc statements from
> the GUI command console is...
> 
> r.mapcalc "frict=1"
> r.mapcalc "test=pendiente*2"

I can confirm this behaviour using Windows' cmd.exe shell. It does not
seem to be able to handle single quotes correctly. But then again,
cmd.exe is sth. very different from your regular unixish shell.
If I run MSYS' sh.exe in the Windows console, things tend to work fine
for me.

Benjamin


-- 
Benjamin Ducke, M.A.
Arch?oinformatik
(Archaeoinformation Science)
Institut f?r Ur- und Fr?hgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universit?t zu Kiel
Johanna-Mestorf-Stra?e 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

From woklist at kyngchaos.com  Mon Nov 12 17:50:50 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Mon Nov 12 17:50:55 2007
Subject: [GRASS-dev] X11 trouble on OSX 10.5
In-Reply-To: <C35DC9C4.28437%michael.barton@asu.edu>
References: <C35DC9C4.28437%michael.barton@asu.edu>
Message-ID: <E862011E-8CF4-425C-B2C7-60CD5C3E537C@kyngchaos.com>

On Nov 12, 2007, at 10:13 AM, Michael Barton wrote:

> One Mac issue I need to mention. In the current cvs version (on  
> 10.4) GRASS
> help no longer is listed in my Help Library, although the GRASS  
> addons help
> IS listed. It's not a huge issue as help comes up OK from within  
> GRASS, but
> it was handy having it in the library listing too.
>
The install puts a symlink in /Library/Documentation/Help.  If you  
move or rename the GRASS app after install, this will break, but as  
you found g.manual still knows where the files are.

One idea that's been pushed to the back of my brain is to install the  
actual help files in the Documentation folder.  But this would  
complicate g.manual and GUI help references, and the bindist installer  
package setup.

> Michael
>
>> More info, I forgot: the GUI splash displays just before this error.
>>
>> Definitely something wrong in TclTk 8.5.  The GUI runs with 8.4
>> (32bits).
>>
>> The reason I tried 8.5 is that 8.4 does not build 64bits on OSX
>> (configure actually removes any 64bit flags you try to add).  I
>> suppose the GUI itself doesn't need to run in 64bits, as long as the
>> modules are 64bits they will run as such.
>>

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy


From paul-grass at stjohnspoint.co.uk  Mon Nov 12 20:48:00 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Mon Nov 12 20:48:16 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <47388264.2070207@ufg.uni-kiel.de>
References: <C35DC7BB.28432%michael.barton@asu.edu>
	<47388264.2070207@ufg.uni-kiel.de>
Message-ID: <Pine.LNX.4.62.0711121944180.12658@vortex.ukshells.co.uk>

On Mon, 12 Nov 2007, Benjamin Ducke wrote:

>>
>> We received an error with the following simple mapcalc statements
>>
>> r.mapcalc 'frict=1'
>> r.mapcalc 'test=pendiente*2'
>>
>> It turns out that you cannot use single quotes in this context. You need to
>> use regular quotes. So the way to specify the same mapcalc statements from
>> the GUI command console is...
>>
>> r.mapcalc "frict=1"
>> r.mapcalc "test=pendiente*2"
>
> I can confirm this behaviour using Windows' cmd.exe shell. It does not
> seem to be able to handle single quotes correctly. But then again,
> cmd.exe is sth. very different from your regular unixish shell.

Yes it's nothing new. You need to know a bit more about Windows than just 
how to point and click to be able to get the most out of GRASS I 
suppose---we're moving away from that obviously - but it still helps.

ISTR around this time last year when we were fixing a lot of tedious 
little things to improve Windows compatibility, having to change commands 
run with system() or similar from within C programs to use double instead 
of single quotes was quite a common problem. Hopefully most occurences 
within C programs have been caught now but perhaps there are still some in 
gis.m?

Paul

From neteler at fbk.eu  Mon Nov 12 23:48:28 2007
From: neteler at fbk.eu (Markus Neteler)
Date: Mon Nov 12 23:48:30 2007
Subject: [GRASS-dev] 6.3.0 backport question
Message-ID: <20071112224828.GE6067@fbk.eu>

Hi,

I have seen a set of fixes in the CVS which haven't been backported
yet. So far I didn't figure out the magic line to push a fix
from HEAD to release branch.

Anyone who can teach me? Glynn once posted it but it didn't
seem to work for me. 
Certainly it would be better is *all* developers made use of
the magic push line to avoid that others accidentally port
irrelevant stuff or simply to save us/me time.

Markus

From hamish_nospam at yahoo.com  Tue Nov 13 01:55:29 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Nov 13 01:55:38 2007
Subject: [GRASS-dev] 6.3.0 backport question
In-Reply-To: <20071112224828.GE6067@fbk.eu>
Message-ID: <531222.79450.qm@web52702.mail.re2.yahoo.com>

Markus Neteler wrote:
> I have seen a set of fixes in the CVS which haven't been backported
> yet.

Is there a policy for 6.3.0 backports? Bugfixes only? Minor fixes? New
features? Cool stuff? Everything?

> So far I didn't figure out the magic line to push a fix
> from HEAD to release branch.
> 
> Anyone who can teach me? Glynn once posted it but it didn't
> seem to work for me. 

Perhaps not the perfect way, but

- commit change in HEAD
- cd releasebranch_6_3/
- cvs co -r releasebranch_6_3 grass6/file/to/change
# IFF there has not been previous changes to the file in the branch
- cvs up -j HEAD grass6/file/to/change
- cvs diff grass6/file/to/change
- cvs commit grass6/file/to/change

If there have been prior changes to the branch you need to also specify the
release branch revision, as detailed in Glynn's prior post. Otherwise you get
conflicts during the merge. In those cases I admit that I usually revert to
doing a surgical edit in vi + cvs diff rather than try to make sense of the
mixed lineage. The downside is this requires a human & thus some level of human
error may be introduces.


> Certainly it would be better is *all* developers made use of
> the magic push line to avoid that others accidentally port
> irrelevant stuff or simply to save us/me time.

FWIW, my strategy has been to backport bug fixes only and if there are a series
of changes wait for the dust to settle and backport all the changes at once
instead of for each of a series of refinements. The downside is sometimes after
a couple of days of settled dust I forget about it...


For recent MS Windows fixes, I think it is ok for 6.3.0 to be considered alpha1
release, and 6.3.1 can be alpha2. Do we backport all DOS changes or split off
6.3.1(MS-alpha2) as another branch from HEAD?
 

Hamish



      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

From michael.barton at asu.edu  Tue Nov 13 02:38:13 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Nov 13 02:38:28 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <20071112150707.nyj17tkgs3dc0wws@secure.lsit.ucsb.edu>
Message-ID: <C35E4E15.28452%michael.barton@asu.edu>




On 11/12/07 4:07 PM, "Javier Fernandez" <javierfernandez@anth.ucsb.edu>
wrote:

> 
> Hi all sorry for the delay,
> 
> I have problems each time that I manage operations with vector layers
> as import vector points from dbf and ascii files or  create contour
> lines from a dem. Also if I work with map calculator.
> 
> Error reports:
> 
> 1. Map Calculator
> 
> r.mapcalc 'test=pendiente*1'


Javi,

Try it with normal (double) quotes.

r.mapcalc "test=pendiente*1"

Let me know what happens.


> 
> syntax error, unexpected $end, expecting '='
> Parse error
> 
> 2. r.contour
> 
> 
> dbf.exe has encountered a problem and needs to close.  We are sorry
> for the inconvenience.
> 
> AppName: dbf.exe  AppVer: 0.0.0.0  ModName: msvcrt.dll
> ModVer: 7.0.2600.2180  Offset: 000360cb
> 
> 
> 3. v.in.ascii input
> 
> v.in.ascii input=C:/grassdata/MR.csv output=MR format=point fs=,
> skip=0 x=1 y=2 z=0 cat=0 --overwrite

What is the error here?

> 
> Javi
> 
> 
> 
> 
> Quoting Michael Barton <michael.barton@asu.edu>:
> 
>> 
>> 
>> 
>> On 11/12/07 4:14 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
>> 
>>> 
>>> Michael Barton wrote:
>>> 
>>>> It appears that r.mapcalc is NOT working. We get an error with even the
>>>> simplest of mapcalc statements. Javi will send the error message tonight or
>>>> tomorrow, but it is a red herring IMHO, stating that it is missing an "=".
>>>> We have the same error if we run r.mapcalc via the TclTk interface
>>>> (r.mapcalculator) or run it from the console command line. Other commands
>>>> work find from the console command line. This is *critical*, of course, as
>>>> r.mapcalc is very important to GRASS analysis and map management.
>>> 
>>> FWIW, the only r.mapcalc files which have changed in the last three
>>> months are:
>>> 
>>> Makefile
>>> map3.c
>>> r.mapcalc.html
>>> r3.mapcalc.html
>>> 
>>> The Makefile changes were part of the parallel build effort, and don't
>>> change what is compiled or which switches are used. The map3.c changes
>>> are just standardisation of messages, and only affect r3.mapcalc.
>>> 
>>> I presume that this is related to your local environment; otherwise, I
>>> would expect to see other people reporting it.
>> 
>> Unfortunately, not many people testing new WinGRASS alpha builds yet I fear.
>> 
>> I did some more tests this morning, this time on my Mac and may have
>> discovered the cause of the error.
>> 
>> For the current WinGRASS binary, it is necessary to use the command console
>> for command-line use of GRASS.
>> 
>> We received an error with the following simple mapcalc statements
>> 
>> r.mapcalc 'frict=1'
>> r.mapcalc 'test=pendiente*2'
>> 
>> It turns out that you cannot use single quotes in this context. You need to
>> use regular quotes. So the way to specify the same mapcalc statements from
>> the GUI command console is...
>> 
>> r.mapcalc "frict=1"
>> r.mapcalc "test=pendiente*2"
>> 
>> I thought we had tried double quotes too, but maybe we didn't. I'll wait for
>> Javi to check email and test. The worrisome thing is that we initially used
>> the GUI map calculator from the menu and got an error. I tried it this
>> morning on my Mac and did not get an error.
>> 
>> 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 paul-grass at stjohnspoint.co.uk  Tue Nov 13 11:45:45 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Tue Nov 13 11:46:06 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <C35E4E15.28452%michael.barton@asu.edu>
References: <C35E4E15.28452%michael.barton@asu.edu>
Message-ID: <Pine.LNX.4.62.0711131042560.31398@vortex.ukshells.co.uk>

On Mon, 12 Nov 2007, Michael Barton wrote:

>> 3. v.in.ascii input
>>
>> v.in.ascii input=C:/grassdata/MR.csv output=MR format=point fs=,
>> skip=0 x=1 y=2 z=0 cat=0 --overwrite
>
> What is the error here?

Are you running that from the command console? If so I think it is a 
similar problem of needing to use Windows rather than Unix syntax. Try 
c:\grassdata\MR.csv for the pathname (backslashes instead of forward 
slashes). Would also (obviously) help to see the error message but at a 
first glance that's what I can see is wrong with it.

Paul

From glynn at gclements.plus.com  Tue Nov 13 15:39:59 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed Nov 14 02:04:28 2007
Subject: [GRASS-dev] 6.3.0 backport question
In-Reply-To: <20071112224828.GE6067@fbk.eu>
References: <20071112224828.GE6067@fbk.eu>
Message-ID: <18233.46911.948591.251656@cerise.gclements.plus.com>


Markus Neteler wrote:

> I have seen a set of fixes in the CVS which haven't been backported
> yet. So far I didn't figure out the magic line to push a fix
> from HEAD to release branch.

This normally works (from the branch):

	cvs update -j HEAD <filename>
	cvs commit <filename>

There can be problems if you want to merge a file more than once after
it has been branched, but I don't recall whether it affects the case
of merging from the trunk to a branch (the CVS documentation only
covers merging a branch into the trunk).

Using two -j flags with explicit revision numbers will always work,
but that's awkward for changes which span multiple files. I have had
problems with the "-j branch:date" form; an alternative is to tag by
date then merge using the tag.

As a fallback, you can use "cvs diff" to extract the changes as a
patch, then manually apply it to the branch.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Tue Nov 13 15:12:47 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed Nov 14 02:04:35 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <Pine.LNX.4.62.0711121944180.12658@vortex.ukshells.co.uk>
References: <C35DC7BB.28432%michael.barton@asu.edu>
	<47388264.2070207@ufg.uni-kiel.de>
	<Pine.LNX.4.62.0711121944180.12658@vortex.ukshells.co.uk>
Message-ID: <18233.45279.800756.615319@cerise.gclements.plus.com>


Paul Kelly wrote:

> ISTR around this time last year when we were fixing a lot of tedious 
> little things to improve Windows compatibility, having to change commands 
> run with system() or similar from within C programs to use double instead 
> of single quotes was quite a common problem. Hopefully most occurences 
> within C programs have been caught now but perhaps there are still some in 
> gis.m?

gis.m shouldn't be using a shell to execute commands, so shell syntax
shouldn't come into it.

BTW, if anyone wants to take another stab at eliminating shell usage
in C modules, I've added G_vspawn_ex() and SF_ARGVEC since the last
attempt. This should solve the problems with passing variable argument
lists. See the thread "testing native winGRASS" from March for context
(no URL as the web site seems to be down right now).

-- 
Glynn Clements <glynn@gclements.plus.com>

From neteler at fbk.eu  Wed Nov 14 11:02:04 2007
From: neteler at fbk.eu (Markus Neteler)
Date: Wed Nov 14 11:09:07 2007
Subject: [GRASS-dev] Test mail to grass.itc.it + migration news
Message-ID: <86782b610711140202t62d30949x40e9078bb6af7d71@mail.gmail.com>

Dear all,

there seems to be a DNS mess which renders grass.itc.it to be unreachable
for many users. Not sure about email but it seems to affected, too.
Hope that the DNS caches update soon.

Along with the migration to OSGeo, I also plan to migrate the
mailing lists in the near future. It should be rather transparent
for you (just change of the domain name to osgeo.org then).
We should use that occasion to "normalize" some list names:

grass-abm
grass-announce
grass-commit
grass-commit-addons
grass-dev
grass-es
grass-psc
grass-qa
grassgui -> grass-gui
grassuser -> grass-user
statsgrass -> grass-stats
translations -> grass-translations
weblist -> grass-weblist
winGRASS -> grass-windows

Using aliases (as we already do for the old grass5), the old names will
keep working and will be auto-forwarded to the new list names.
The OSGeo system is Mailman as well, so it works as you know it.

Markus

From neteler at fbk.eu  Wed Nov 14 11:37:47 2007
From: neteler at fbk.eu (Markus Neteler)
Date: Wed Nov 14 11:37:55 2007
Subject: [GRASS-dev] Test mail to grass.itc.it + migration news
Message-ID: <20071114103747.GB24338@fbk.eu>

Dear all,

[second try to send this out!]

there seems to be a DNS mess which renders grass.itc.it to be unreachable
for many users. Not sure about email but it seems to affected, too.
Hope that the DNS caches update soon. grass.fbk.eu responds.

Along with the migration to OSGeo, I also plan to migrate the
mailing lists in the near future. It should be rather transparent
for you (just change of the domain name to osgeo.org then).
We should use that occasion to "normalize" some list names:

 grass-abm
 grass-announce
 grass-commit
 grass-commit-addons
 grass-dev
 grass-es
 grass-psc
 grass-qa
 grassgui -> grass-gui
 grassuser -> grass-user
 statsgrass -> grass-stats
 translations -> grass-translations
 weblist -> grass-weblist
 winGRASS -> grass-windows

Using aliases (as we already do for the old grass5), the old names will
keep working and will be auto-forwarded to the new list names.
The OSGeo system is Mailman as well, so it works as you know it.

Markus

-- 
Markus Neteler  <neteler fbk eu>  http://mpa.fbk.eu/markus/
FBK-irst -  Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy

From michael.barton at asu.edu  Wed Nov 14 08:21:53 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 16:11:20 2007
Subject: [GRASS-dev] Re: [GRASS-user] Call for documentation help
In-Reply-To: <4739A9FF.9020903@uni-trier.de>
Message-ID: <C35FF021.284D4%michael.barton@asu.edu>




On 11/13/07 6:43 AM, "Dr. Manuel Seeger" <seeger@uni-trier.de> wrote:

> Hello,
> I'm now using GRASS for a while and try to introduce it to the students'
> education. So I think I could try to help with the enhancement of the
> documentation. But I am not a native english speaker. Extending, I could
> offer my support for german and spanish documentation.
> Unfortunately, I do not feel able to coordinate this..;-)
> 
> Please let me know, where you could need my help!
> 
> Manuel

Manuel,

Thanks for your kind offer. I think that Markus is collecting information at
present and has posted a number of general guidelines on the WIKI.

Eric Patton has volunteered to coordinate the documentation effort and so
far has no competition for the job ;-)

(I'm copying both Markus and Eric)

We certainly need documentation in other languages besides English.

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 michael.barton at asu.edu  Tue Nov 13 16:06:02 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 16:21:08 2007
Subject: [GRASS-dev] Re: [GRASS-user] NVIZ and 3D polygon
In-Reply-To: <2e7973150711121810m359f7bd8mf4b19b7e50071b92@mail.gmail.com>
Message-ID: <C35F0B6A.2846C%michael.barton@asu.edu>




On 11/12/07 7:10 PM, "aswin indraprastha" <aswinindra@gmail.com> wrote:

> Is it something with OpenGL setting? I am using Grass 6.3 in Leopard.


Judging from posts by Willaim Kyngesbury over the weekend, I'd say the
chances are good that this is the problem.

He's running into difficulties compiling aspects of OpenGL in GRASS. Does
NVIZ work otherwise (i.e., for 2D maps)? Or is it stuck with everything?

I wouldn't be surprised if there needs to be a special Leopard binary for
GRASS.

I know that this won't help you a lot, but for anyone else using GRASS on a
Mac, it might be wise to NOT upgrade to OS X 10.5 (aka Leopard) until this
is sorted out.

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 Nov 14 07:17:37 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 16:25:33 2007
Subject: [GRASS-dev] select issue with wingrass
In-Reply-To: <Pine.LNX.4.62.0711131042560.31398@vortex.ukshells.co.uk>
Message-ID: <C35FE111.284D0%michael.barton@asu.edu>

We've run into more issues with the dbf.exe.

The same error reported before happens with v.surf.bspline. However,
v.surf.rst works *fine*, even though both commands use a column from a
vector attribute table.

Whatever is causing this problem resides in a library used by v.in.db,
r.contour, and v.surf.bspline, but NOT used by r.to.vect, v.area, or
v.surf.rst.

Michael


On 11/13/07 3:45 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

> On Mon, 12 Nov 2007, Michael Barton wrote:
> 
>>> 3. v.in.ascii input
>>> 
>>> v.in.ascii input=C:/grassdata/MR.csv output=MR format=point fs=,
>>> skip=0 x=1 y=2 z=0 cat=0 --overwrite
>> 
>> What is the error here?
> 
> Are you running that from the command console? If so I think it is a
> similar problem of needing to use Windows rather than Unix syntax. Try
> c:\grassdata\MR.csv for the pathname (backslashes instead of forward
> slashes). Would also (obviously) help to see the error message but at a
> first glance that's what I can see is wrong with it.
> 
> 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 tutey at o2.pl  Wed Nov 14 18:48:15 2007
From: tutey at o2.pl (Maciej Sieczka)
Date: Wed Nov 14 18:48:22 2007
Subject: [GRASS-dev] Test mail to grass.itc.it + migration news
In-Reply-To: <20071114103747.GB24338@fbk.eu>
References: <20071114103747.GB24338@fbk.eu>
Message-ID: <473B34DF.1030909@o2.pl>

Markus Neteler wrote:

> [second try to send this out!]

Received it twice.

> there seems to be a DNS mess which renders grass.itc.it to be unreachable
> for many users. Not sure about email but it seems to affected, too.
> Hope that the DNS caches update soon. grass.fbk.eu responds.
> 
> Along with the migration to OSGeo, I also plan to migrate the
> mailing lists in the near future. It should be rather transparent
> for you (just change of the domain name to osgeo.org then).
> We should use that occasion to "normalize" some list names:

Very good idea IMHO.

<snip>
>  weblist -> grass-weblist
</snip>

May I suggest grass-web instead? "list" seems redundant to me.

Maciek

From michael.barton at asu.edu  Wed Nov 14 18:56:26 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 18:57:19 2007
Subject: [GRASS-dev] Re: [GRASS-user] Instability of r.param.scale tcl-tk
	dialog
In-Reply-To: <473B09BD.4070300@amu.edu.pl>
Message-ID: <C36084DA.284FB%michael.barton@asu.edu>

This is probably caused by the dialog opening up to excactly the pixel size
between 2 stable sizes. The dialog is oscillating back and forth between 2
sizes a pixel apart. I've seen it on a couple dialogs.

The solution is to resize the dialog a little.

AFAIK, there is no way around it. The script that automatically creates the
dialogs (gui.tcl) tries to find an optimal size for each command, based on
the number of entries in its first tab. If this happens to be a size that is
unstable in another tab, there is no way that *I* know of to check for this.
It's rare, but happens once in awhile.

Michael


On 11/14/07 7:44 AM, "Jaros?aw Jasiewicz" <jarekj@amu.edu.pl> wrote:

> Maris Nartiss pisze:
>> Hi,
>> first - You are talking about CVS HEAD?
>>   
> yes
>> Your locale (UI messages are in English)?
>>   
> PL (polish)
>> Precise location of problem (I was unable to reproduce it).
>>   
> second tab of r.slope.aspect, dialog run from gis.m manager (not from
> g.m or command line, in these cases all work OK!)
>> This problem is caused by some not so clever wrapping/scrollbar code,
>> that fails on edge cases and needs to be fixed - only where?
>> 
>> Maris.
>> 
>> 2007/11/14, Jaros?aw Jasiewicz <jarekj@amu.edu.pl>:
>>   
>>> This strange situations occurs only on second tab of gui dialog or
>>> r.param.scale
>>> when entering to second tab (settings) the tab starts blink And takes
>>> all comuters resources . The only way to take back control over the
>>> grass gis.m is to kill wish manually and starts gis.m again
>>> I have relatively fresh compilation of cvs (probably from previous week)
>>> 
>>> Jarek
>>> 
>>> _______________________________________________
>>> grassuser mailing list
>>> grassuser@grass.itc.it
>>> http://grass.itc.it/mailman/listinfo/grassuser
>>> 
>>>     
> 
> 

__________________________________________
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