From michael.barton at asu.edu Tue Aug 1 00:10:57 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 1 00:07:01 2006 Subject: [GRASS-dev] startup In-Reply-To: <44CE394C.1020403@unity.ncsu.edu> Message-ID: I think tooltips, info buttons, and popup message dialogs are a good idea. The problem is that the TclTk code for the startup screen is perhaps a decade old and very primitive (at least from my perspective). It doesn't permit tooltips and new buttons are hard to add, especially formatted to look nice, be in the right place (next to or below titles, for example), and not take up an inordinate amount of room. The intro needs to be rewritten from scratch, with bwidgets added so that tooltips can be done and the code updated to make it look and function better. I've started messing with it a couple of times and realized what a chore it is and dropped it because of other more pressing concerns. After repeatedly having to explain what was needed to just start GRASS, however, I finally settled for spiffing up the existing screen as much as possible. But I'm starting to run short on time as the summer comes to a close, and don't know whether it's worth the investment to rewrite it from the ground up. However, if someone wants to take a crack at it... Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Helena Mitasova > Date: Mon, 31 Jul 2006 13:09:32 -0400 > To: GRASS developers list > Subject: Re: [GRASS-dev] startup > > Paul, > > you are right - I forgot about that text - it is a pretty good, brief > description > polished by years of use. Maybe it could be added like this > > Project Location > button ( named e.g. "info", "what it is", or something like that) > > and when you click on it - the text from the old interface could pop up > in a separate > window if it is possible to do in TclTK, it can even be a more detailed > description > if needed. > I too find the new wording somewhat confusing, that is why I asked Markus > to post it for more feedback (it may be just me). > > But there may be new users who have a completely different opinion so it > would be good > to hear from them. > > Helena > > > > > > Paul Kelly wrote: >> Hello everyone >> To be honest I think the wording still confuses things a little. >> Simply because it takes more than 2 or 3 words to explain the concepts >> of location, mapset, region, co-ordinate system and GIS database. >> Perhaps better to have minimal wording in the start-up screen and a >> more detailed explanation in tool-tip help? >> >> When I started using GRASS I hated how complicated it all was and how >> much >> it made me think about my data and co-ordinate systems but now I >> really appreciate that---because a thorough understanding of >> locations, regions etc. is essential to ensuring you get meaningful >> results out of your GIS analyses. >> >> FWIW I don't think the text in the text-based start-up screen is too >> bad. Here is my slightly improved version of it: >> >> LOCATION: This is the name of a geographic location. It is defined by a >> co-ordinate system and a rectangular boundary. -spearfish- is >> the sample LOCATION provided with GRASS. >> >> MAPSET: Every GRASS session runs under a particular MAPSET. Associated >> with each MAPSET is a rectangular REGION and a set of maps. >> >> DATABASE: This is the unix directory containing all the GRASS locations. >> >> The REGION defaults to the entire area of the chosen LOCATION. >> You may change it later with the command: g.region >> >> >> Paul >> >> On Mon, 31 Jul 2006, Markus Neteler wrote: >> >>> Hi, >>> >>> Michael has made updates to the startup screen. >>> The current state of the entrance screen can be seen >>> here: >>> http://mpa.itc.it/markus/tmp/new_grass61_startup_2.jpg >>> (also valid for the release branch). >>> >>> Please comment on further modifications. >>> >>> Markus >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev@grass.itc.it >>> http://grass.itc.it/mailman/listinfo/grass-dev >>> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > > > -- > Helena Mitasova > Department of Marine, Earth and Atmospheric Sciences > North Carolina State University > 1125 Jordan Hall > NCSU Box 8208 > Raleigh, NC 27695-8208 > http://skagit.meas.ncsu.edu/~helena/ > > email: hmitaso@unity.ncsu.edu > ph: 919-513-1327 (no voicemail) > fax 919 515-7802 > > From paul-grass at stjohnspoint.co.uk Tue Aug 1 00:09:04 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Aug 1 00:09:09 2006 Subject: [GRASS-dev] Re: [GRASS-user] RE: PSC: Nominations In-Reply-To: <2FAA57395C1F914DB27CAA4C376058F22CB061@S0-OTT-X2.nrn.nrcan.gc.ca> References: <2FAA57395C1F914DB27CAA4C376058F22CB061@S0-OTT-X2.nrn.nrcan.gc.ca> Message-ID: <44CE7F80.7050904@stjohnspoint.co.uk> Hello David (CC to grass-dev as I feel the discussion is more relevant there; feel free to move back to user list if you have relevant follow-up comments) There was a lot of very good discussion about the PSC on the grass-dev list around the end of April. Unfortunately I didn't get a chance to contribute then as I was very busy with other work. But a lot of very sensible and meaningful contributions were made to the discussion at that stage by everyone and they don't need to be repeated. The stumbling block as I see it is disagreement over the meaning of the concentric decision-making proposal with PSC at the centre, surrounded by developers with CVS write access, surrounded by users. This seems to assume that the PSC are all major contributors with CVS write access, which (a) doesn't look like it's going to happen and (b) may not even be the best way anyway; I'm not sure. What I do think needs serious clarification is the voting or other means of making decisions on the proposals put forward by the PSC. There are a few options for this: Glynn proposed that developers who understand certain areas of the code better than others should have more authority over changes made it that area. This sounds good and is very like the way we work at present, but of course there are always bits that aren't maintained from time to time and bits that nobody really understands! But I would strongly hope that the "moral authority" certain developers have over certain bits of the code will not be undermined by the new decision making mechanism, whatever it is. Markus's proposal is the +1, 0-, 0+ etc. voting system on proposals put forward by the PSC. I think this could be workable, but the following two points need to be addressed: * Only decisions that have a relatively clear resultant course of action should be voted on like this (i.e. not hazy or vague issues were we aren't totally sure what the decision actually means in practice) * Who gets a vote needs a lot of clarification. I like Radim's idea that anybody who has made a subtantial contribution to the code has a voice here. I think it would be very important to incorporate something like that to prevent people feeling disenfranchised. FWIW I am certainly Willing to do the +1 -0 +0 etc. voting thing, and would try my best to read proposals in the time available. At this time I'm not willing to commit to a lot more time (although I *may* be able to; it just depends on circumstances). So there you go - no yes or no on the PSC nomination from me, and just more questions really :/ Sorry... :) Paul From muzafferayvaz at yahoo.com Tue Aug 1 00:20:31 2006 From: muzafferayvaz at yahoo.com (Muzaffer Ayvaz) Date: Tue Aug 1 00:20:34 2006 Subject: [GRASS-dev] error about "Floating point exception" Message-ID: <20060731222031.14805.qmail@web53415.mail.yahoo.com> Skipped content of type multipart/alternative-------------- next part -------------- An embedded message was scrubbed... From: Muzaffer Ayvaz Subject: Re: [GRASS-dev] error about "Floating point exception" Date: Mon, 31 Jul 2006 05:33:03 -0700 (PDT) Size: 3184 Url: http://grass.itc.it/pipermail/grass-dev/attachments/20060731/c8085ba6/attachment.mht From epatton at nrcan.gc.ca Tue Aug 1 04:23:45 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Aug 1 04:23:51 2006 Subject: [GRASS-dev] gis.m: cannot get profile from profile tool Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55B07@s5-dar-r1.nrn.nrcan.gc.ca> Michael, I'm confused; I selected a raster via the first button from the left on the profiling GUI (See the image on my ftp site); in the bottom left corner of the profiling GUI, the text reads "Profile for CheticampAll_Aug2005_10m" (the bathymetry raster I'm profiling.) I'm at home now so I can't use Grass until tomorrow morning, but just to make sure I'm using it correctly, you click the first button on the left to load a raster to profile, the second to draw a profile in the profile window, and the third to render the profile graph? ~ Eric. -----Original Message----- From: Michael Barton To: Patton, Eric; Moritz Lennert Cc: 'Grass Developers List '; Markus Neteler Sent: 7/31/2006 3:17 PM Subject: Re: [GRASS-dev] gis.m: cannot get profile from profile tool Eric, You failed to select a raster map to profile. I just committed an update which does a better job of trapping this kind of error and giving you a more meaningful error message. I also made the profiler default to the currently selected raster map to profile and also found a way of making the elevation ranges calculated within the currently displayed region, using r.univar. The primary drawback of this is that it is a bit slow to get started with enormous maps. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: "Patton, Eric" > Date: Mon, 31 Jul 2006 12:52:01 -0300 > To: 'Moritz Lennert ' , 'Michael Barton ' > > Cc: 'Grass Developers List ' > Subject: RE: [GRASS-dev] gis.m: cannot get profile from profile tool > > Hi guys, > > I tried the porfiling tool with July 31 cvs, and I can't get it to work. The > y-axis gets assigned correct values for the profile I've drawn, but no lines > get drawn in the profile window. A tcltk window reports "Error: can't read > "cumdist": no such variable" > > You can view the output on my ftp site: > > ftp://agc.bio.ns.ca/outgoing/Patton/Grass/Bug%20Reports/ > > ~ Eric. > > > -----Original Message----- > From: grass-dev-bounces@grass.itc.it > To: Michael Barton > Cc: Grass Developers List > Sent: 7/27/2006 2:33 AM > Subject: Re: [GRASS-dev] gis.m: cannot get profile from profile tool > > Michael Barton wrote: >> Hi Moritz, >> >> Did you select a raster to profile? > > Yes, as you can see in the screenshot, it says in the bottom left: > "Profile for srtm_be". > > >> Third button from the left on the >> profiler toolbar. >> Rather like d.profile, the profiler differentiates between >> a map you use as a background to the profiling line (what is shown in > the >> map display) and the map that you actually use to compute profile > values. > > > I understand that, but I still don't get a profile. Actually, I > sometimes do not even get the straight blue line you see in the > screenshot (http://moritz.homelinux.org/grass/gism_profile.png), just an > > empty graph. > > The min and max of the heights on the y axis seem correct, though. > > Moritz > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From michael.barton at asu.edu Tue Aug 1 04:43:04 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 1 04:43:13 2006 Subject: [GRASS-dev] gis.m: cannot get profile from profile tool In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55B07@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: Eric, It sounds like you are doing this correctly. I think in the version you are using (check the tooltips), the 1st button on the left sets the raster you want to profile. In that version, it uses r.info to set the elevation range. A problem with this is that it can only determine the total range for the entire map, which may be much greater than the range of the area you are profiling. This is changed in the version I just committed today. The new version uses r.univar, which honors the displayed region in calculating elevation range. The elevation range is used to set the vertical scale, and the conversion between elevation units and screen units. The second button from the left lets you draw a transect line to profile. The third button runs r.profile twice. The first time it simply get's the max distance along the line reported by r.profile and stores it to the variable cumdist (cumulative distance). It then uses this to value to set the horizontal scale and the conversion between horizontal map units and screen units. This is necessary to deal with latlon regions. It then runs r.profile again to generate the actual profile values, as a list of distance, elevation. These are converted to screen values and plotted to the profile graph. This was having some issues with negative values, giving unexpected results. I also fixed that today. So I'm not sure what the problem is for you. You might run r.profile on the same set of end coordinates and see what it produces. If you have negative elevation values, it might be problematic in the version you have. If r.profile is choking for some reason, that would also be a cause. If you want to try out the new one, simply use the web access to the cvs, go to grass6/gui/tcltk/gis.m/profile.tcl and download it. Then move it into your $GISBASE/etc/gm folder. It's just a text file, so it should not be a problem. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: "Patton, Eric" > Date: Mon, 31 Jul 2006 23:23:45 -0300 > To: 'Michael Barton ' , 'Moritz Lennert ' > > Cc: ''Grass Developers List ' ' , 'Markus Neteler ' > > Subject: RE: [GRASS-dev] gis.m: cannot get profile from profile tool > > Michael, > > I'm confused; I selected a raster via the first button from the left on the > profiling GUI (See the image on my ftp site); in the bottom left corner of > the profiling GUI, the text reads "Profile for CheticampAll_Aug2005_10m" > (the bathymetry raster I'm profiling.) > > I'm at home now so I can't use Grass until tomorrow morning, but just to > make sure I'm using it correctly, you click the first button on the left to > load a raster to profile, the second to draw a profile in the profile > window, and the third to render the profile graph? > > ~ Eric. > > -----Original Message----- > From: Michael Barton > To: Patton, Eric; Moritz Lennert > Cc: 'Grass Developers List '; Markus Neteler > Sent: 7/31/2006 3:17 PM > Subject: Re: [GRASS-dev] gis.m: cannot get profile from profile tool > > Eric, > > You failed to select a raster map to profile. > > I just committed an update which does a better job of trapping this kind > of > error and giving you a more meaningful error message. I also made the > profiler default to the currently selected raster map to profile and > also > found a way of making the elevation ranges calculated within the > currently > displayed region, using r.univar. The primary drawback of this is that > it is > a bit slow to get started with enormous maps. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: "Patton, Eric" >> Date: Mon, 31 Jul 2006 12:52:01 -0300 >> To: 'Moritz Lennert ' , 'Michael Barton > ' >> >> Cc: 'Grass Developers List ' >> Subject: RE: [GRASS-dev] gis.m: cannot get profile from profile tool >> >> Hi guys, >> >> I tried the porfiling tool with July 31 cvs, and I can't get it to > work. The >> y-axis gets assigned correct values for the profile I've drawn, but no > lines >> get drawn in the profile window. A tcltk window reports "Error: can't > read >> "cumdist": no such variable" >> >> You can view the output on my ftp site: >> >> ftp://agc.bio.ns.ca/outgoing/Patton/Grass/Bug%20Reports/ >> >> ~ Eric. >> >> >> -----Original Message----- >> From: grass-dev-bounces@grass.itc.it >> To: Michael Barton >> Cc: Grass Developers List >> Sent: 7/27/2006 2:33 AM >> Subject: Re: [GRASS-dev] gis.m: cannot get profile from profile tool >> >> Michael Barton wrote: >>> Hi Moritz, >>> >>> Did you select a raster to profile? >> >> Yes, as you can see in the screenshot, it says in the bottom left: >> "Profile for srtm_be". >> >> >>> Third button from the left on the >>> profiler toolbar. >>> Rather like d.profile, the profiler differentiates between >>> a map you use as a background to the profiling line (what is shown in >> the >>> map display) and the map that you actually use to compute profile >> values. >> >> >> I understand that, but I still don't get a profile. Actually, I >> sometimes do not even get the straight blue line you see in the >> screenshot (http://moritz.homelinux.org/grass/gism_profile.png), just > an >> >> empty graph. >> >> The min and max of the heights on the y axis seem correct, though. >> >> Moritz >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > From landa.martin at gmail.com Tue Aug 1 09:56:07 2006 From: landa.martin at gmail.com (Martin Landa) Date: Tue Aug 1 09:56:11 2006 Subject: [GRASS-dev] Re: [GRASS-user] RE: PSC: Nominations In-Reply-To: <200607311951.46356.pnaciona@gis.umn.edu> References: <5FA22789-2422-4A0A-AE66-639C1035E2CD@shaw.ca> <200607311951.46356.pnaciona@gis.umn.edu> Message-ID: Hi, I would like to vote, but I am slightly confused about the current PSC nominations. Maybe it would be good to vote (or just publish the current list of nominations) using the wiki...(?) - or just update the page http://grass.gdf-hannover.de/wiki/GRASS_Project_Steering_Commitee#Nominations Best, Martin 2006/8/1, Pericles S. Nacionales : > Me 3! :) > > -Perry > > On Monday 31 July 2006 17:24, Tyler Mitchell wrote: > > Me too... > > > > On 31-Jul-06, at 2:56 PM, Michael Barton wrote: > > > I'll second that > > > > > > Dylan Beaudette +1 > > _______________________________________________ > grassuser mailing list > grassuser@grass.itc.it > http://grass.itc.it/mailman/listinfo/grassuser > From neteler at itc.it Tue Aug 1 10:00:25 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 1 10:00:28 2006 Subject: [GRASS-dev] Re: [GRASS-user] RE: PSC: Nominations In-Reply-To: References: <5FA22789-2422-4A0A-AE66-639C1035E2CD@shaw.ca> <200607311951.46356.pnaciona@gis.umn.edu> Message-ID: <20060801080025.GG4691@bartok.itc.it> On Tue, Aug 01, 2006 at 09:56:07AM +0200, Martin Landa wrote: > Hi, > > I would like to vote, but I am slightly confused about the current PSC > nominations. Maybe it would be good to vote (or just publish the > current list of nominations) using the wiki...(?) - or just update the > page > http://grass.gdf-hannover.de/wiki/GRASS_Project_Steering_Commitee#Nominations I agree - this would render it more transparent. Markus From mlennert at club.worldonline.be Tue Aug 1 11:01:10 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Aug 1 11:01:08 2006 Subject: [GRASS-dev] gis.m: cannot get profile from profile tool In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55B05@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C26208C55B05@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <44CF1856.4070603@club.worldonline.be> Patton, Eric wrote: > Hi guys, > > I tried the porfiling tool with July 31 cvs, and I can't get it to work. The > y-axis gets assigned correct values for the profile I've drawn, but no lines > get drawn in the profile window. A tcltk window reports "Error: can't read > "cumdist": no such variable" > > You can view the output on my ftp site: > > ftp://agc.bio.ns.ca/outgoing/Patton/Grass/Bug%20Reports/ I actually got a similar error at one point, but then couldn't reproduce it... Moritz > > ~ Eric. > > > -----Original Message----- > From: grass-dev-bounces@grass.itc.it > To: Michael Barton > Cc: Grass Developers List > Sent: 7/27/2006 2:33 AM > Subject: Re: [GRASS-dev] gis.m: cannot get profile from profile tool > > Michael Barton wrote: >> Hi Moritz, >> >> Did you select a raster to profile? > > Yes, as you can see in the screenshot, it says in the bottom left: > "Profile for srtm_be". > > >> Third button from the left on the >> profiler toolbar. >> Rather like d.profile, the profiler differentiates between >> a map you use as a background to the profiling line (what is shown in > the >> map display) and the map that you actually use to compute profile > values. > > > I understand that, but I still don't get a profile. Actually, I > sometimes do not even get the straight blue line you see in the > screenshot (http://moritz.homelinux.org/grass/gism_profile.png), just an > > empty graph. > > The min and max of the heights on the y axis seem correct, though. > > Moritz > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From mlennert at club.worldonline.be Tue Aug 1 11:14:01 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Aug 1 11:13:58 2006 Subject: [GRASS-dev] GRASS 6.1.0beta2 preparation In-Reply-To: <20060731202545.GF8229@bartok.itc.it> References: <20060715155932.GD9134@bartok.itc.it> <20060720210141.GH21897@bartok.itc.it> <20060722103753.GA12264@bartok.itc.it> <20060731202545.GF8229@bartok.itc.it> Message-ID: <44CF1B59.3050200@club.worldonline.be> Markus Neteler wrote: > - debian control files still outdated (since there is low > interest, just remove them?) > What is outdated about them ? I'd like for them to stay since I use them to recompile the Debian way. Moritz From jachym.cepicky at centrum.cz Tue Aug 1 11:19:11 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Aug 1 11:19:18 2006 Subject: [GRASS-dev] GRASS 6.1.0beta2 preparation In-Reply-To: <44CF1B59.3050200@club.worldonline.be> References: <20060715155932.GD9134@bartok.itc.it> <20060720210141.GH21897@bartok.itc.it> <20060722103753.GA12264@bartok.itc.it> <20060731202545.GF8229@bartok.itc.it> <44CF1B59.3050200@club.worldonline.be> Message-ID: <20060801091909.GA13557@localdomain> On Tue, Aug 01, 2006 at 11:14:01AM +0200, Moritz Lennert wrote: > Markus Neteler wrote: > > >- debian control files still outdated (since there is low > > interest, just remove them?) > > > > What is outdated about them ? > just the versions of suggested libraries and external programs are too old (tk 8.3 -> 8.4, ...) jachym > I'd like for them to stay since I use them to recompile the Debian way. > > Moritz > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060801/c818a7f9/attachment.bin From neteler at itc.it Tue Aug 1 11:41:55 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 1 11:41:56 2006 Subject: [GRASS-dev] GRASS 6.1.0beta2 preparation In-Reply-To: <20060801091909.GA13557@localdomain> References: <20060715155932.GD9134@bartok.itc.it> <20060720210141.GH21897@bartok.itc.it> <20060722103753.GA12264@bartok.itc.it> <20060731202545.GF8229@bartok.itc.it> <44CF1B59.3050200@club.worldonline.be> <20060801091909.GA13557@localdomain> Message-ID: <20060801094155.GI4691@bartok.itc.it> On Tue, Aug 01, 2006 at 11:19:11AM +0200, Jachym Cepicky wrote: > On Tue, Aug 01, 2006 at 11:14:01AM +0200, Moritz Lennert wrote: > > Markus Neteler wrote: > > > > >- debian control files still outdated (since there is low > > > interest, just remove them?) > > > > > > > What is outdated about them ? > > > > just the versions of suggested libraries and external programs are too > old (tk 8.3 -> 8.4, ...) Right. But I guess that we want tk >= 8.3 etc here. The idea is to *not* hardcode the version any longer if not needed. Since I am no debian user I dunno how to fix the control file. Markus From mlennert at club.worldonline.be Tue Aug 1 12:24:44 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Aug 1 12:24:41 2006 Subject: [GRASS-dev] Re: d.vect.thematic creates outtxt.txt file which is not erased In-Reply-To: References: Message-ID: <44CF2BEC.9030507@club.worldonline.be> Michael Barton wrote: > I can't see any reason for this line. So I commented it out and committed > the change to the cvs. Let me know if it messes up anything I didn't see. I now get the following error, but only in a new location, not in already existing ones. Strange... couldn't open "/home/mlennert/GRASS/DATA/BE/mlennert/.tmp/geog-pc40/gismlegend.txt": no such file or directory couldn't open "/home/mlennert/GRASS/DATA/BE/mlennert/.tmp/geog-pc40/gismlegend.txt": no such file or directory while executing "open $legfile r" (procedure "GmThematic::tleg_item" line 12) invoked from within "GmThematic::tleg_item $mon $id" (procedure "GmThematic::display" line 78) invoked from within "GmThematic::display $node $mod" ("thematic" arm line 2) invoked from within "switch $type { group { GmGroup::display $node $mod } raster { GmRaster::display $node $mod } labels { GmLabels::disp..." (procedure "GmTree::display_node" line 7) invoked from within "GmTree::display_node $n $mod" (procedure "GmGroup::display" line 25) invoked from within "GmGroup::display "root" $mod" (procedure "MapCanvas::runprograms" line 30) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 43) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) From hem571 at gmail.com Tue Aug 1 12:27:56 2006 From: hem571 at gmail.com (Hel patel) Date: Tue Aug 1 12:27:58 2006 Subject: [GRASS-dev] Customization in GRASS Message-ID: <8389abf00608010327n3a37e8d3l6a96627b64bcd652@mail.gmail.com> I am student. We are trying to add a customization module in GRASS. if anyone could guide me on this. This is just like what we have in ESRI ArcGIS 9.1 through VBA. Please reply back to this id. Hemal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060801/c8a9ed80/attachment.html From mlennert at club.worldonline.be Tue Aug 1 14:03:49 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Aug 1 14:03:47 2006 Subject: [GRASS-dev] Re: d.vect.thematic creates outtxt.txt file which is not erased In-Reply-To: <44CF2BEC.9030507@club.worldonline.be> References: <44CF2BEC.9030507@club.worldonline.be> Message-ID: <44CF4325.2000108@club.worldonline.be> Moritz Lennert wrote: > Michael Barton wrote: >> I can't see any reason for this line. So I commented it out and committed >> the change to the cvs. Let me know if it messes up anything I didn't see. > > I now get the following error, but only in a new location, not in > already existing ones. Strange... Cannot reproduce this, so must have been some other problem. Now it seems to work fine. Moritz From glynn at gclements.plus.com Tue Aug 1 14:13:26 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 1 14:13:29 2006 Subject: [GRASS-dev] GRASS 6.1.0beta2 preparation In-Reply-To: <20060731202545.GF8229@bartok.itc.it> References: <20060715155932.GD9134@bartok.itc.it> <20060720210141.GH21897@bartok.itc.it> <20060722103753.GA12264@bartok.itc.it> <20060731202545.GF8229@bartok.itc.it> Message-ID: <17615.17766.8710.184537@cerise.gclements.plus.com> Markus Neteler wrote: > - Glynn's MingW fixes not ported (not sure if we want that) The changes to the raster library are too invasive for 6.1.0, but the old version won't compile on MinGW (no socket functions). Consequently, 6.1.0 won't be particularly usable on MinGW, so there probably isn't much point in backporting the various minor tweaks either. -- Glynn Clements From neteler at itc.it Tue Aug 1 14:27:30 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 1 14:27:32 2006 Subject: [GRASS-dev] GRASS 6.1.0beta2 preparation In-Reply-To: <17615.17766.8710.184537@cerise.gclements.plus.com> References: <20060715155932.GD9134@bartok.itc.it> <20060720210141.GH21897@bartok.itc.it> <20060722103753.GA12264@bartok.itc.it> <20060731202545.GF8229@bartok.itc.it> <17615.17766.8710.184537@cerise.gclements.plus.com> Message-ID: <44CF48B2.6040206@itc.it> Glynn Clements wrote on 08/01/2006 02:13 PM: > Markus Neteler wrote: > > >> - Glynn's MingW fixes not ported (not sure if we want that) >> > > The changes to the raster library are too invasive for 6.1.0, but the > old version won't compile on MinGW (no socket functions). > Consequently, 6.1.0 won't be particularly usable on MinGW, so there > probably isn't much point in backporting the various minor tweaks > either. > Right. Given this I suggest to get out GRASS 6.1.0 now and then branch it again later on or so. Markus From dsampson at NRCan.gc.ca Tue Aug 1 14:47:31 2006 From: dsampson at NRCan.gc.ca (Sampson, David) Date: Tue Aug 1 14:47:35 2006 Subject: [GRASS-dev] RE: [GRASS-user] RE: PSC: Nominations In-Reply-To: <44CE7F80.7050904@stjohnspoint.co.uk> Message-ID: <2FAA57395C1F914DB27CAA4C376058F23D389F@S0-OTT-X2.nrn.nrcan.gc.ca> I have forwarded this post to the grass-user list. Most PSC discussion is occuring on that list to include the widest variety of idea generators. Great points you brought us, perhaps the community can address them -----Original Message----- From: Paul Kelly [mailto:paul-grass@stjohnspoint.co.uk] Sent: July 31, 2006 18:09 To: Sampson, David Cc: grass-dev@grass.itc.it Subject: Re: [GRASS-user] RE: PSC: Nominations Hello David (CC to grass-dev as I feel the discussion is more relevant there; feel free to move back to user list if you have relevant follow-up comments) There was a lot of very good discussion about the PSC on the grass-dev list around the end of April. Unfortunately I didn't get a chance to contribute then as I was very busy with other work. But a lot of very sensible and meaningful contributions were made to the discussion at that stage by everyone and they don't need to be repeated. The stumbling block as I see it is disagreement over the meaning of the concentric decision-making proposal with PSC at the centre, surrounded by developers with CVS write access, surrounded by users. This seems to assume that the PSC are all major contributors with CVS write access, which (a) doesn't look like it's going to happen and (b) may not even be the best way anyway; I'm not sure. What I do think needs serious clarification is the voting or other means of making decisions on the proposals put forward by the PSC. There are a few options for this: Glynn proposed that developers who understand certain areas of the code better than others should have more authority over changes made it that area. This sounds good and is very like the way we work at present, but of course there are always bits that aren't maintained from time to time and bits that nobody really understands! But I would strongly hope that the "moral authority" certain developers have over certain bits of the code will not be undermined by the new decision making mechanism, whatever it is. Markus's proposal is the +1, 0-, 0+ etc. voting system on proposals put forward by the PSC. I think this could be workable, but the following two points need to be addressed: * Only decisions that have a relatively clear resultant course of action should be voted on like this (i.e. not hazy or vague issues were we aren't totally sure what the decision actually means in practice) * Who gets a vote needs a lot of clarification. I like Radim's idea that anybody who has made a subtantial contribution to the code has a voice here. I think it would be very important to incorporate something like that to prevent people feeling disenfranchised. FWIW I am certainly Willing to do the +1 -0 +0 etc. voting thing, and would try my best to read proposals in the time available. At this time I'm not willing to commit to a lot more time (although I *may* be able to; it just depends on circumstances). So there you go - no yes or no on the PSC nomination from me, and just more questions really :/ Sorry... :) Paul From neteler at itc.it Tue Aug 1 15:11:28 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 1 15:11:31 2006 Subject: [GRASS-dev] v.digit error when closing: region restoring Message-ID: <20060801131128.GV4691@bartok.itc.it> Hi, when closing v.digit, I get this error message: v.digit fields Building topology ... 271 primitives registered Building areas: 100% 65 areas built 11 isles built Attaching islands: 100% Attaching centroids: 100% Topology was built. Number of nodes : 217 Number of primitives: 271 Number of points : 0 Number of lines : 0 Number of boundaries: 208 Number of centroids : 63 Number of areas : 65 Number of isles : 11 Number of areas without centroid : 2 Region restored to original extent. Error in startup script: couldn't read file "fields": no such file or directory Interestingly, I cannot find 'Error in startup script' in the code. Any ideas? Must be a rather fresh bugfeature. Markus From grass-bugs at intevation.de Tue Aug 1 15:32:58 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Aug 1 15:33:00 2006 Subject: [GRASS-dev] [bug #4939] (grass) GRASS 6.0 on a MacBookPro Message-ID: <20060801133258.1D8CE101EF3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4939 ------------------------------------------------------------------------- Hi, I would like to use GRASS 6.0 on my MacBookPro laptop. I installed Grass6.0 from the Grass site and installed X11 from the MacOS X installation CD. Problems appear when I want to start Grass: - < double click on Grass6.0 icon > --> start window appears - < click on the start button > --> the xterm window appears --> after a while the following message appears:"X11 got an error: AppleEvent timed out. (-1712)" Thank you for your help Caroline --- Headers Follow --- >From caroline.roelandt@mac.com Tue Aug 1 15:32:57 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id DDF39101EEA for ; Tue, 1 Aug 2006 15:32:57 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 447A6195685 for ; Tue, 1 Aug 2006 15:32:58 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 0C2AB191738 for ; Tue, 1 Aug 2006 15:32:58 +0200 (CEST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by kolab.intevation.de (Postfix) with ESMTP id 17DBA1176E8 for ; Tue, 1 Aug 2006 15:32:56 +0200 (CEST) Received: from mac.com (webmail19-en1 [10.13.10.174]) by smtpout.mac.com (Xserve/8.12.11/smtpout10/MantshX 4.0) with ESMTP id k71DWttE021969 for ; Tue, 1 Aug 2006 06:32:55 -0700 (PDT) Received: from webmail19 (localhost [127.0.0.1]) by mac.com (Xserve/webmail19/MantshX 4.0) with ESMTP id k71DWsSY000316 for ; Tue, 1 Aug 2006 06:32:55 -0700 (PDT) Received: from [83.101.6.131] by webmail.mac.com with HTTP; Tue, 01 Aug 2006 15:32:54 +0200 Message-ID: <12236687.1154439174480.JavaMail.caroline.roelandt@mac.com> Date: Tue, 01 Aug 2006 15:32:54 +0200 From: Caroline Roelandt To: grass-bugs@intevation.de Subject: GRASS 6.0 on a MacBookPro MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 83.101.6.131/instID=283 X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=-3 tagged_above=-999 required=3 tests=[BAYES_05=-3] X-Spam-Level: -------------------------------------------- Managed by Request Tracker From holl at gdf-hannover.de Tue Aug 1 15:37:00 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Tue Aug 1 15:37:10 2006 Subject: [GRASS-dev] ANN: Simplified Chinese version of GRASS 6.0 V1.2 tutorial available. Message-ID: <20060801153700.75d7747d@butan.gdf-hannover.de> Dear List, [sorry for Crossposting] Zhang Jun has translated the GRASS 6.0 tutorial V.1.2 for simplified chinese. Congratulations! A HTML-version is provided here: http://www.gdf-hannover.de/lit_html/grass60_v1.2_zh_CN/index.html You can download a PDF here: http://www.gdf-hannover.de/dl.php?download=gdf_grass60_v1.2_zh_CN.pdf Have fun! Stephan -- GDF Hannover - Solutions for spatial data analysis and remote sensing Hannover Office - Mengendamm 16d - D-30177 Hannover Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 From grass-bugs at intevation.de Tue Aug 1 16:02:07 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Aug 1 16:02:09 2006 Subject: [GRASS-dev] [bug #4940] (grass) rebug report Message-ID: <20060801140207.ACB53101EF5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4940 ------------------------------------------------------------------------- Subject: rebug report Platform: WindowsNT/2000/XP grass obtained from: Other (CDROM etc) grass binary for platform: Compiled from Sources idris o. salako. error could be improved without necessarily interfreing with downloading -------------------------------------------- Managed by Request Tracker From epatton at nrcan.gc.ca Tue Aug 1 16:34:58 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Aug 1 16:35:03 2006 Subject: [GRASS-dev] gis.m: cannot get profile from profile tool Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55B0A@s5-dar-r1.nrn.nrcan.gc.ca> Michael, I updated to 2006-08-01 cvs and the profile tool works great! Thanks! ~ Eric. -----Original Message----- From: Michael Barton To: Patton, Eric; Moritz Lennert Cc: 'Grass Developers List '; Markus Neteler Sent: 7/31/2006 3:17 PM Subject: Re: [GRASS-dev] gis.m: cannot get profile from profile tool Eric, You failed to select a raster map to profile. I just committed an update which does a better job of trapping this kind of error and giving you a more meaningful error message. I also made the profiler default to the currently selected raster map to profile and also found a way of making the elevation ranges calculated within the currently displayed region, using r.univar. The primary drawback of this is that it is a bit slow to get started with enormous maps. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: "Patton, Eric" > Date: Mon, 31 Jul 2006 12:52:01 -0300 > To: 'Moritz Lennert ' , 'Michael Barton ' > > Cc: 'Grass Developers List ' > Subject: RE: [GRASS-dev] gis.m: cannot get profile from profile tool > > Hi guys, > > I tried the porfiling tool with July 31 cvs, and I can't get it to work. The > y-axis gets assigned correct values for the profile I've drawn, but no lines > get drawn in the profile window. A tcltk window reports "Error: can't read > "cumdist": no such variable" > > You can view the output on my ftp site: > > ftp://agc.bio.ns.ca/outgoing/Patton/Grass/Bug%20Reports/ > > ~ Eric. > > > -----Original Message----- > From: grass-dev-bounces@grass.itc.it > To: Michael Barton > Cc: Grass Developers List > Sent: 7/27/2006 2:33 AM > Subject: Re: [GRASS-dev] gis.m: cannot get profile from profile tool > > Michael Barton wrote: >> Hi Moritz, >> >> Did you select a raster to profile? > > Yes, as you can see in the screenshot, it says in the bottom left: > "Profile for srtm_be". > > >> Third button from the left on the >> profiler toolbar. >> Rather like d.profile, the profiler differentiates between >> a map you use as a background to the profiling line (what is shown in > the >> map display) and the map that you actually use to compute profile > values. > > > I understand that, but I still don't get a profile. Actually, I > sometimes do not even get the straight blue line you see in the > screenshot (http://moritz.homelinux.org/grass/gism_profile.png), just an > > empty graph. > > The min and max of the heights on the y axis seem correct, though. > > Moritz > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From mlennert at club.worldonline.be Tue Aug 1 16:56:04 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Aug 1 16:56:01 2006 Subject: [GRASS-dev] status of v.edit Message-ID: <44CF6B84.1050308@club.worldonline.be> Hi, What is the status of v.edit ? I thought that it was more or less complete, but see that it is not compiled by default. Why not ? Moritz From michael.barton at asu.edu Tue Aug 1 17:09:17 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 1 17:09:27 2006 Subject: [GRASS-dev] Re: d.vect.thematic creates outtxt.txt file which is not erased In-Reply-To: <44CF4325.2000108@club.worldonline.be> Message-ID: I just love the problems that solve themselves ;-) Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Moritz Lennert > Date: Tue, 01 Aug 2006 14:03:49 +0200 > To: Moritz Lennert > Cc: Michael Barton , Grass Developers List > > Subject: Re: [GRASS-dev] Re: d.vect.thematic creates outtxt.txt file which is > not erased > > Moritz Lennert wrote: >> Michael Barton wrote: >>> I can't see any reason for this line. So I commented it out and committed >>> the change to the cvs. Let me know if it messes up anything I didn't see. >> >> I now get the following error, but only in a new location, not in >> already existing ones. Strange... > > > Cannot reproduce this, so must have been some other problem. Now it > seems to work fine. > > Moritz From dsampson at NRCan.gc.ca Tue Aug 1 17:14:53 2006 From: dsampson at NRCan.gc.ca (Sampson, David) Date: Tue Aug 1 17:14:59 2006 Subject: [GRASS-dev] HOLD YOUR VOTES: Changes to the PSC process Message-ID: <2FAA57395C1F914DB27CAA4C376058F23D3948@S0-OTT-X2.nrn.nrcan.gc.ca> * PLEASE RESPOND TO GRASS USERS LIST* First, I have updated the nominees and votes to date below. I suggest we should hold off any further voting until issue 2 is solved. Second, it has been suggested to change the PSC nomination process. As any good democratic process I thought I would throw it back to the community. I don't like jumping to conclusions without support so I have compiled a list of some of the successes and challenges of the PSC process to date. This is a combination of what I have been experiencing and what GRASS community members have forwarded to me off-line. When the ball was started again concerning forming the PSC, after some time in the back drawers of the community brain, it was essentially started where it was thought (Where I thought perhaps) the process ended off. The approach was to get the group together and working. It was not known that various nominated people were not interested in participating in the PSC, despite documentation on the wiki. There were perhaps more questions that needed answering, and more and more of those questions are answered as we progress. The voting strategy was not intended necessarily as one of go/no-go acceptance into the PSC. It was more for a show of support by the community. Eg "the GRASS PSC was formed through minimum supportive votes in an open process". This was also to accommodate a less formal approach as was desired by many community members. However, there are some concerns this isn't structured enough. Perhaps we want a maximum number of people on the PSC (proposed 7 to 11). Perhaps we want a share of programmers / users / other stakeholders. So I open the process back up to the community. Third, it has also been suggested to gather some ideas of the voting system. E-mail to a single person may not be the best or most un-biased route. Some if people have an idea of how to go about voting would be great. Here are some other options 1. Users List. This is not anonymous and may not represent a true vote count for fear of offending friends or colleges. Someone needs to monitor. Easiest to implement 2. Wiki. Open and can be anonymous. Needing to create "yet another account" may deter participation. 3. Voting software: a. Java Voting System: http://www.free-project.org/download/ b. Mail based System: http://zvote.zsentry.com/zvote.htm c. Secure Democracy (Sede): http://www.xs4all.nl/~joshb/c/ If you have any other ideas on the voting system please let the community know. In short, if the community wants a change to the process, I am more than happy to help it happen. I am going on Vacation in August so the below dates have considered this. If these dates don't work, then perhaps someone with a more flexible schedule can accommodate. Or if we like where things are going we can just continue the current process. We could also extend the nominee process for all of August to allow other vacationers to accept nomination and commence the votes in September for two weeks for a goal of having the PSC formed by mid September. Just in time for those profs and students to get pumped for OSGEO and GRASS. So I'd like to have an idea of where the community would like to go. Lets hold our votes and discuss this process. We then decide on a move by Friday August 4. That gives a week for more nominations for the fast tracked approach. If the process needs more thinking then we push back the beginning date. I would suggest pushing back the date if, and only if, there is massive idea contribution to the process by the GRASS community. Otherwise we are waiting for those who will never act. But at the same time no everyone acts at break neck speed (right?). SO some thoughtful input into timing would be nice as well. Also, let's keep in mind the GRASS community as represented by the mailing list is currently 662 people strong as of today. So what do you think is an appropriate voter turn out to be fair? Successes: ----------- 1. We now have 7 people that have accepted their nomination to the PSC 2. There is momentum and commitment in making the GRASS PSC happen 3. The process is pretty open and dynamic. 4. new and old GRASS community members are stepping forward with interest to be a part of the PSC. * Familiar and new faces wanting to contribute to the community. 5. The GRASS community wants to address issues potentially deterring long time contributors from participating in the PSC. 6. nominations are still coming in as individuals are contacted. 7. Progress forward is happening and people are positive. Challenges: ------------ 1. As the nominations come in and votes are cast there might be an imbalance in favour of those who have been on the list longer 2. the process has no distinct END. Eg when do we have a complete PSC? 3. There is a large desire within the community for some major players to accept nominations to PSC. 4. Some feel the PSC nomination process may be moving a little fast, and conclusions made too early. 5. With various posting methods to show support for nominees some votes may have been missed 6. With the current process it is hard to track how many individual community members have cast a vote 7. Some potential nominees have not responded to the nominating individual, which means we may be missing potential individuals. 8. Some past (outstanding) nominees have not responded to direct e-mails so their status is unknown but presence still desired 9. Some extraordinary nominees may require more time to feel their concerns have been addressed before committing to the PSC. PROPOSED PROCESS ---------------- 1. Open a period of nominations. * These nominees have to accept their nomination before accepted to the list. * this period would last until August 9 (or September) * All Nominees are announced at closing of this period (we already have 7 and hopefully more soon) * The goal would be to have minimum 7 people maximum 11 (proposed limits) 2. Open a voting Period * voting would commence August 10 (or Early September) for Approx. two weeks * Votes would be sent to me directly off line (one or two other people I could CC to keep process open is recommended) * The number of voters would be documented (Names included or excluded?) 3. Close the Voting period * Successful nominees achieve minimum of 5 supporting votes (so we don't have accepted by default) * If more than the maximum number of nominees have the minimum votes required then the ones with most votes are accepted 4. Announce the new PSC * Successful nominees will have their number of votes documented * Do we publish unsuccessful members? ================================= BELOW IS FOR THE RECORD TO DATE. VOTES ON HOLD ================================= > Removed/Declined: > --------------- > > > > Newly Nominated: > ---------------- Remember that people have to agree to be nominated. Thanks to those in this list who have accepted Markus Neteler (12)1 (Accepted) Scott Mitchell (1) (Accepted) Dylan Beaudette (4) (Accepted) Massimiliano Cannata (1)(Accepted) > Accepted: > ------------ Michael Barton (12) (Accepted) Maciej Sieczka (5) (Accepted) Helena Mitasova (6) (Accepted) Markus Neteler (14) (Accepted) Scott Mitchell (1) (Accepted) Dylan Beaudette (1) (Accepted) Massimiliano Cannata(1) (Accepted) > Outstanding Nominations NAME (#) = nominations made > ------------- > > Hamish Bowman (11) (Pending) > Brad Douglas (11) (Pending) > Paul Kelly (11) (Pending) > Cedric Shock (11) (Pending) > Venkatesh Raghavan (9) (Pending) > Roger Bivand (7) (Pending) > NOMINATORS (18) > > NOMINATORS represents the approximate number of people having > submitted nominations. This is a rough estimate is to give us an idea > > of how many people are involving themselves in the process. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060801/5e730d1e/attachment-0001.html From epatton at nrcan.gc.ca Tue Aug 1 17:21:58 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Aug 1 17:22:03 2006 Subject: [GRASS-dev] d.grid is disabled in latest cvs Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55B0B@s5-dar-r1.nrn.nrcan.gc.ca> I'm unable to get to get the gis.m 'Overlay grids and lines' button to render either a utm or geographic grid. This was working in gis.m sometime last week. I've set the grid spacing to a wide range of values that ought to fit within my current region. Launching d.grid from the command line fails to draw the grid as well, but with the added error message: No socket to connect to for monitor . GRASS_INFO_ERROR(13002,1): No graphics device selected~ >No socket to connect to for monitor . Hmm...checking d.mon -L shows that gism is currently running. It seems that d.grid fails to catch my current graphics device. Any ideas? ~ Eric. From tutey at o2.pl Tue Aug 1 17:51:02 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Aug 1 17:51:09 2006 Subject: [GRASS-dev] v.digit: segfaullt at any attempt to run it! In-Reply-To: <20060731201509.GD8229@bartok.itc.it> References: <44C49F40.1090103@o2.pl> <44C4BDF8.9040901@o2.pl> <20060731201509.GD8229@bartok.itc.it> Message-ID: <44CF7866.10202@o2.pl> Markus Neteler napisa?(a): > On Mon, Jul 24, 2006 at 02:32:56PM +0200, Maciej Sieczka wrote: >> Maciej Sieczka napisa?(a): >>> Hi, >>> >>> In current Grass 6.1 CVS v.digit segfaults opening any existing or new >>> vector! >> To be more exact: it segfaults trying to open an existing vector, and >> also segfaults when exiting after called with 'v.digit -n map'. >> >> Maciek > > .. works for me. Probably 'make distclean' is your friend. I did make distclean that time, as well as I did it again this time, before buildidng Grass 6.1 CVS. Anyway, the good news is that now v.digit doesn't segfault anymore, great. Maciek From grass-bugs at intevation.de Tue Aug 1 18:20:31 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Aug 1 18:20:33 2006 Subject: [GRASS-dev] [bug #4944] (grass) d.vect.thematic: no lines displayed Message-ID: <20060801162031.22136101EF8@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4944 ------------------------------------------------------------------------- Subject: d.vect.thematic: no lines displayed Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: cvs_head_20060801 I am trying to display graduated lines (or lines with graduated colors) with d.vect.thematic. However, even though the legend displays the lines correctly, no lines are displayed in the display. Here's the command line that the GIS manager creates: d.vect.thematic -s map=test type=area column=FREQ layer=1 icon=basic/circle size=5 maxsize=20 nint=4 pointcolor=255:0:0 linecolor=0:0:0 startcolor=255:0:0 endcolor=0:0:255 themetype=graduated_lines monitor=none themecalc=interval colorscheme=blue-red -m Using individual d.vect commands such as d.vect map=test color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,centroid,area icon=basic/x size=5 width=5 layer=1 lsize=8 xref=left yref=center llayer=1 {where=FREQ>=50 and FREQ<=57.5} the lines display as expected. Moritz -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Tue Aug 1 18:24:41 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Aug 1 18:24:48 2006 Subject: [GRASS-dev] GRASS 6.1.0 branch status In-Reply-To: <20060731201944.GE8229@bartok.itc.it> References: <20060715155932.GD9134@bartok.itc.it> <20060720210141.GH21897@bartok.itc.it> <20060722103753.GA12264@bartok.itc.it> <20060722112533.GA12556@bartok.itc.it> <44C3DE3C.1020909@o2.pl> <20060731201944.GE8229@bartok.itc.it> Message-ID: <44CF8049.9040601@o2.pl> Markus Neteler napisa?(a): > On Sun, Jul 23, 2006 at 10:38:20PM +0200, Maciej Sieczka wrote: >> I did my best to pick only those which I know/strongly suspect that are >> still valid bugs; there are more grass6 bug reports for NVIZ and v.digit >> of unknown status (for me), worthy of having a a look at them though. >> > > Please keep in mind that (IMHO) > - we should follow a bit closer the "release often" paradigm That's OK with me. > - that we just want to get out 6.1.0 aka unstable Among those bugs listed (and the remaining ones in the BT) there are some which where reported when 5.7 and 6.0 where unstable, but they remain not fixed for stable 6.01, 6.02, nor in the 6.0 CVS branch. They aren't fixed in 6.1 branch too. Let's hope they will be fixed for 6.2 stable. > Of course I hope that bugs are fixed... I'm using an occasion to remind that there are bugs left. Not everybody is up to date with the BT; maybe a reminder will trigger developers' attention to the long forgotten problems. Maciek From cavallini at faunalia.it Tue Aug 1 18:45:10 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Tue Aug 1 18:45:20 2006 Subject: [GRASS-dev] HOLD YOUR VOTES: Changes to the PSC process In-Reply-To: <2FAA57395C1F914DB27CAA4C376058F23D3948@S0-OTT-X2.nrn.nrcan.gc.ca> References: <2FAA57395C1F914DB27CAA4C376058F23D3948@S0-OTT-X2.nrn.nrcan.gc.ca> Message-ID: <44CF8516.7010305@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I think we should do every possible effort to have Radim Blazek on board. We simply cannot afford missing him, as he's the author of most of the newest parts of GRASS: vectors, database, and qgis integration. All the best. pc Sampson, David ha scritto: > * PLEASE RESPOND TO GRASS USERS LIST* > > First, I have updated the nominees and votes to date below. I suggest we should hold off any further voting until issue 2 is solved. > Second, it has been suggested to change the PSC nomination process. As any good democratic process I thought I would throw it back to the community. I don't like jumping to conclusions without support so I have compiled a list of some of the successes and challenges of the PSC process to date. This is a combination of what I have been experiencing and what GRASS community members have forwarded to me off-line. > When the ball was started again concerning forming the PSC, after some time in the back drawers of the community brain, it was essentially started where it was thought (Where I thought perhaps) the process ended off. The approach was to get the group together and working. It was not known that various nominated people were not interested in participating in the PSC, despite documentation on the wiki. There were perhaps more questions that needed answering, and more and more of those questions are answered as we progress. > The voting strategy was not intended necessarily as one of go/no-go acceptance into the PSC. It was more for a show of support by the community. Eg "the GRASS PSC was formed through minimum supportive votes in an open process". This was also to accommodate a less formal approach as was desired by many community members. However, there are some concerns this isn't structured enough. Perhaps we want a maximum number of people on the PSC (proposed 7 to 11). Perhaps we want a share of programmers / users / other stakeholders. So I open the process back up to the community. > Third, it has also been suggested to gather some ideas of the voting system. E-mail to a single person may not be the best or most un-biased route. Some if people have an idea of how to go about voting would be great. Here are some other options ... - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEz4UW/NedwLUzIr4RArrIAJ0UzaHQPypgad5hJ++Yh+KCAsfCOQCffose ltDJPl4guI3lLeG8hHjlW38= =Gm0i -----END PGP SIGNATURE----- From mlennert at club.worldonline.be Tue Aug 1 18:47:31 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Aug 1 18:47:28 2006 Subject: [GRASS-dev] [bug #4944] (grass) d.vect.thematic: no lines displayed In-Reply-To: <20060801162031.22136101EF8@lists.intevation.de> References: <20060801162031.22136101EF8@lists.intevation.de> Message-ID: <44CF85A3.4030106@club.worldonline.be> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4944 > ------------------------------------------------------------------------- > > > Subject: d.vect.thematic: no lines displayed > > Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for > platform: Compiled from Sources GRASS Version: cvs_head_20060801 > > I am trying to display graduated lines (or lines with graduated > colors) with d.vect.thematic. However, even though the legend > displays the lines correctly, no lines are displayed in the display. > > Here's the command line that the GIS manager creates: > > d.vect.thematic -s map=test type=area column=FREQ layer=1 > icon=basic/circle size=5 maxsize=20 nint=4 pointcolor=255:0:0 > linecolor=0:0:0 startcolor=255:0:0 endcolor=0:0:255 > themetype=graduated_lines monitor=none themecalc=interval > colorscheme=blue-red -m Sorry, just noticed my own error: type obviously has to be set to line, not area ! So "bug" can be closed. Sorry. Moritz From dsampson at NRCan.gc.ca Tue Aug 1 19:17:57 2006 From: dsampson at NRCan.gc.ca (Sampson, David) Date: Tue Aug 1 19:18:01 2006 Subject: [GRASS-dev] HOLD YOUR VOTES: Changes to the PSC process In-Reply-To: <44CF8516.7010305@faunalia.it> Message-ID: <2FAA57395C1F914DB27CAA4C376058F23D39AB@S0-OTT-X2.nrn.nrcan.gc.ca> So would you feel comfortable approaching Radim to invite his acceptance of nomination. Saying that someone would be a good contribution is the first step. NEXT we need to get them onboard. I wish you well in attracting Radim's interest. Keep us posted -----Original Message----- From: Paolo Cavallini [mailto:cavallini@faunalia.it] Sent: August 1, 2006 12:45 To: Sampson, David Cc: grassuser@grass.itc.it; grass-dev@grass.itc.it Subject: Re: [GRASS-dev] HOLD YOUR VOTES: Changes to the PSC process -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I think we should do every possible effort to have Radim Blazek on board. We simply cannot afford missing him, as he's the author of most of the newest parts of GRASS: vectors, database, and qgis integration. All the best. pc Sampson, David ha scritto: > * PLEASE RESPOND TO GRASS USERS LIST* > > First, I have updated the nominees and votes to date below. I suggest we should hold off any further voting until issue 2 is solved. > Second, it has been suggested to change the PSC nomination process. As any good democratic process I thought I would throw it back to the community. I don't like jumping to conclusions without support so I have compiled a list of some of the successes and challenges of the PSC process to date. This is a combination of what I have been experiencing and what GRASS community members have forwarded to me off-line. > When the ball was started again concerning forming the PSC, after some time in the back drawers of the community brain, it was essentially started where it was thought (Where I thought perhaps) the process ended off. The approach was to get the group together and working. It was not known that various nominated people were not interested in participating in the PSC, despite documentation on the wiki. There were perhaps more questions that needed answering, and more and more of those questions are answered as we progress. > The voting strategy was not intended necessarily as one of go/no-go acceptance into the PSC. It was more for a show of support by the community. Eg "the GRASS PSC was formed through minimum supportive votes in an open process". This was also to accommodate a less formal approach as was desired by many community members. However, there are some concerns this isn't structured enough. Perhaps we want a maximum number of people on the PSC (proposed 7 to 11). Perhaps we want a share of programmers / users / other stakeholders. So I open the process back up to the community. > Third, it has also been suggested to gather some ideas of the voting > system. E-mail to a single person may not be the best or most > un-biased route. Some if people have an idea of how to go about voting > would be great. Here are some other options ... - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEz4UW/NedwLUzIr4RArrIAJ0UzaHQPypgad5hJ++Yh+KCAsfCOQCffose ltDJPl4guI3lLeG8hHjlW38= =Gm0i -----END PGP SIGNATURE----- From kwythers at umn.edu Tue Aug 1 19:57:55 2006 From: kwythers at umn.edu (Kirk R. Wythers) Date: Tue Aug 1 19:58:00 2006 Subject: [GRASS-dev] r.in.gdal and .ecw files on OS X In-Reply-To: References: <35469E27904CA04687795AF87D26930001CDFF@september.ecotrust.org> <437CC904-E231-4FD7-A04E-1BFCE57AFE5D@UMN.EDU> <7622FE34-A899-438A-A94F-053047CE76AF@kyngchaos.com> <66A3CAAD-5A59-46BE-957F-883CF4532A8C@umn.edu> Message-ID: <6D6C6DA1-DF6D-4590-B016-2E396F8BC508@umn.edu> William, I just finished compiling gdal with the ecw stuff. Is this the error you get when trying read an .ecw file: GRASS 6.1.cvs (cecr_utm):~ > r.in.gdal -oe input=~/Desktop/ farmservcolororthophoto2003/q0625k/q3334/img_fsa01aim4.ecw output=fsa01aim4 dyld: lazy symbol binding failed: Symbol not found: _FSFindFolder Referenced from: /usr/local/lib/libNCSUtil.0.dylib Expected in: flat namespace dyld: Symbol not found: _FSFindFolder Referenced from: /usr/local/lib/libNCSUtil.0.dylib Expected in: flat namespace ERROR 1: File is invalid or corrupt GRASS 6.1.cvs (cecr_utm):~ > Just wanted to run this by you to if I was hung up in the same place. Although I do get the ecw coming up as a readable file option with the -f option now: ECW (rw): ERMapper Compressed Wavelets thanks, Kirk On Aug 1, 2006, at 10:35 AM, William Kyngesburye wrote: > I tried both. By default, it builds shared with the old collection > of libraries, and static with the new single libecwj2. And yes, I > noticed the missing makefile-osx also. But they're moving away > from the fixed makefiles from qmake to the standard configure-make- > install. You're supposed to be able to create your own with qmake, > but in the past I haven't had that installed. I have it now, part > of the Qt stuff, but I'm not sure I want to mess with that. > > There is one change you need to make or it won't build: in Source/C/ > NCSnet/NCScnet3/NCSSocket.cpp, line 190, comment out or delete the > MACOSX ifdef block so just the NON-MACOSX line is used: > > //# ifdef MACOSX > // int tempSize = sizeof(struct sockaddr); > //# else > socklen_t tempSize = sizeof(struct sockaddr); > //# endif > > I don't think this has anything to do with the crashes - Tom Lynch > from ERMapper (hangs out on the GDAL list) suggested this, or at > least pointed out a thread in their forum about it. > > > Interesting - I was just poking around their forums to see if there > was any new info. Tom mentioned a final release at the end of > June. Indeed, the binary (Windoze only) is final, but the source > is still RC2. Soon, he says. Things move slow over there... I > hope they have OSX working. > > On Aug 1, 2006, at 9:39 AM, Kirk R. Wythers wrote: > >> I'll give it a go today William. >> >> Curiosity, did you build the static or the shared? Also, I am >> puzzled by the presence of Makefile-linux and Makefile-solaris, >> but no Makefile-osx >> >> Any thoughts? >> > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > First Pogril: Why is life like sticking your head in a bucket > filled with hyena offal? > Second Pogril: I don't know. Why IS life like sticking your head > in a bucket filled with hyena offal? > First Pogril: I don't know either. Wretched, isn't it? > > -HitchHiker's Guide to the Galaxy > From maris.gis at gmail.com Tue Aug 1 21:07:32 2006 From: maris.gis at gmail.com (=?utf-8?q?M=C4=81ris_Narti=C5=A1s?=) Date: Tue Aug 1 21:07:39 2006 Subject: [GRASS-dev] GRASS 6.1.0 branch status In-Reply-To: <44CF8049.9040601@o2.pl> References: <20060715155932.GD9134@bartok.itc.it> <20060731201944.GE8229@bartok.itc.it> <44CF8049.9040601@o2.pl> Message-ID: <200608012207.32674.maris.gis@gmail.com> Could we have some bugday? Or bugweek? It's when no new feature development occurs and all are trying to close as much bugs as possible. There could be work for all users - trying to reproduce bugs, giving aditional info, testing paches etc. Some older bugs IMHO could be closed as WONTFIX i.e. GUI related bugs for 5.x series. Just my 2c. On Tuesday 01 August 2006 19:24, Maciej Sieczka wrote: > > - that we just want to get out 6.1.0 aka unstable > > Among those bugs listed (and the remaining ones in the BT) there are > some which where reported when 5.7 and 6.0 where unstable, but they > remain not fixed for stable 6.01, 6.02, nor in the 6.0 CVS branch. They > aren't fixed in 6.1 branch too. Let's hope they will be fixed for 6.2 > stable. > > > Of course I hope that bugs are fixed... > > I'm using an occasion to remind that there are bugs left. Not everybody > is up to date with the BT; maybe a reminder will trigger developers' > attention to the long forgotten problems. > > Maciek From woklist at kyngchaos.com Tue Aug 1 21:26:51 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Aug 1 21:27:02 2006 Subject: [GRASS-dev] r.in.gdal and .ecw files on OS X In-Reply-To: <6D6C6DA1-DF6D-4590-B016-2E396F8BC508@umn.edu> References: <35469E27904CA04687795AF87D26930001CDFF@september.ecotrust.org> <437CC904-E231-4FD7-A04E-1BFCE57AFE5D@UMN.EDU> <7622FE34-A899-438A-A94F-053047CE76AF@kyngchaos.com> <66A3CAAD-5A59-46BE-957F-883CF4532A8C@umn.edu> <6D6C6DA1-DF6D-4590-B016-2E396F8BC508@umn.edu> Message-ID: <20C45D2A-1F59-48F9-9FF8-8680D68A4FFB@kyngchaos.com> I think you have two different problems there... On Aug 1, 2006, at 12:57 PM, Kirk R. Wythers wrote: > William, > > I just finished compiling gdal with the ecw stuff. Is this the > error you get when trying read an .ecw file: > > GRASS 6.1.cvs (cecr_utm):~ > r.in.gdal -oe input=~/Desktop/ > farmservcolororthophoto2003/q0625k/q3334/img_fsa01aim4.ecw > output=fsa01aim4 > dyld: lazy symbol binding failed: Symbol not found: _FSFindFolder > Referenced from: /usr/local/lib/libNCSUtil.0.dylib > Expected in: flat namespace > > dyld: Symbol not found: _FSFindFolder > Referenced from: /usr/local/lib/libNCSUtil.0.dylib > Expected in: flat namespace > This looks harmless. I don't think I had this one, it may be a difference in configuration when building. But I think it's getting past it. Since I didn't get this, I don't thik it has anything to do with the real problem below... > ERROR 1: File is invalid or corrupt This is the problem I have. All ECWs are flagged as corrupt. I hope ERMapper gets cracking on that source release, and that they have worked out the OSX problems. ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From rez at touchofmadness.com Tue Aug 1 21:27:53 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Aug 1 21:28:02 2006 Subject: [GRASS-dev] HOLD YOUR VOTES: Changes to the PSC process In-Reply-To: <2FAA57395C1F914DB27CAA4C376058F23D3948@S0-OTT-X2.nrn.nrcan.gc.ca> References: <2FAA57395C1F914DB27CAA4C376058F23D3948@S0-OTT-X2.nrn.nrcan.gc.ca> Message-ID: <1154460473.3013.161.camel@devel> On Tue, 2006-08-01 at 11:14 -0400, Sampson, David wrote: > * PLEASE RESPOND TO GRASS USERS LIST* It'll probably bounce, but here's trying... Why this is being discussed on the user list is a little beyond me, but I'm not complaining... > > Third, it has also been suggested to gather some ideas of the voting > system. E-mail to a single person may not be the best or most > un-biased route. Some if people have an idea of how to go about voting > would be great. Here are some other options I assumed that voting would take place on the list over a reasonable time and someone simply keeps tally. Not difficult. I don't like the idea of moving voting elsewhere. It's just another layer of confusion, IMHO. If people feel more "secure" with an outside voting system to get the PSC started, fine, but I don't envision it lasting any longer than that. > 1. Users List. This is not anonymous and may not represent a true > vote count for fear of offending friends or colleges. Someone needs to > monitor. Easiest to implement Is anonymity such a big deal, here? Is the human psyche really that frail? > In short, if the community wants a change to the process, I am more > than happy to help it happen. I am going on Vacation in August so the > below dates have considered this. If these dates don't work, then > perhaps someone with a more flexible schedule can accommodate. Or if > we like where things are going we can just continue the current > process. We could also extend the nominee process for all of August to > allow other vacationers to accept nomination and commence the votes in > September for two weeks for a goal of having the PSC formed by mid > September. Just in time for those profs and students to get pumped for > OSGEO and GRASS. Thanks for getting things rolling again. I don't know if voting should be extended an entire month, but we'll figure it out. I think two weeks should be a reasonable voting period for most people. > Successes: > ----------- > 1. We now have 7 people that have accepted their nomination to the PSC Make that 8. I accept...finally. ;) > Challenges: > ------------ > 1. As the nominations come in and votes are cast there might be an > imbalance in favour of those who have been on the list longer Rightly so, IMHO. It takes considerable time to wrap ones head around the entire project. > 2. the process has no distinct END. Eg when do we have a complete PSC? After the voting and positions have been filled? Speaking of which, what *are* the positions and how many? I believe those are more pressing challenges. > 4. Some feel the PSC nomination process may be moving a little fast, > and conclusions made too early. We've been talking about this for months, now. If it doesn't start picking up the pace, it will *never* happen. Let's not turn this into a bureaucracy. > 9. Some extraordinary nominees may require more time to feel their > concerns have been addressed before committing to the PSC. I thought most of this had been resolved? > PROPOSED PROCESS > ---------------- > 1. Open a period of nominations. > * These nominees have to accept their nomination before > accepted to the list. What is the "list"? A list of people? A mailing list? > * Votes would be sent to me directly off line (one or two > other people I could CC to keep process open is recommended) I prefer open voting on the list. Not that I have any distrust in anyone, but it's much easier to verify something everyone can see. > 4. Announce the new PSC > * Do we publish unsuccessful members? No. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From rez at touchofmadness.com Tue Aug 1 21:33:36 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Aug 1 21:33:44 2006 Subject: [GRASS-dev] GRASS 6.1.0 branch status In-Reply-To: <200608012207.32674.maris.gis@gmail.com> References: <20060715155932.GD9134@bartok.itc.it> <20060731201944.GE8229@bartok.itc.it> <44CF8049.9040601@o2.pl> <200608012207.32674.maris.gis@gmail.com> Message-ID: <1154460816.3013.163.camel@devel> On Tue, 2006-08-01 at 22:07 +0300, M?ris Narti?s wrote: > Could we have some bugday? Or bugweek? It's when no new feature development > occurs and all are trying to close as much bugs as possible. There could be > work for all users - trying to reproduce bugs, giving aditional info, testing > paches etc. That would be interesting. Get a bunch of people together via IRC and have a smashout day. I would participate if schedule allows. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From tutey at o2.pl Tue Aug 1 23:10:05 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Aug 1 23:10:14 2006 Subject: [GRASS-dev] GRASS 6.1.0 branch status In-Reply-To: <200608012207.32674.maris.gis@gmail.com> References: <20060715155932.GD9134@bartok.itc.it> <20060731201944.GE8229@bartok.itc.it> <44CF8049.9040601@o2.pl> <200608012207.32674.maris.gis@gmail.com> Message-ID: <44CFC32D.1010903@o2.pl> Ma-ris Narti?s napisa?(a): > Could we have some bugday? Or bugweek? It's when no new feature development > occurs and all are trying to close as much bugs as possible. There could be > work for all users - trying to reproduce bugs, giving aditional info, testing > paches etc. We should try that! I can help with testing. Until Sept 4 any days besides August 4-6, 11-13 and Aug 18-24 are OK with me. Hamish has been doing a great job sanitizing code, we shouldn't miss him. AFAIK he should be back for good about Aug 23. Are you reading this by any chance Hamish? Brad, what is your schedule? Who else wants to take a part? As soon as the schedule is settled I'd like to spread the news on mailing lists to ask all Grass bug reporters to take a look into their old BT tickets and update the information there if possible. I think we should give folks at least about 5 working days for this before the bug fiesta begins (it's summer time so we might not reach many people but anyway we should try to have as good background as possible). > Some older bugs IMHO could be closed as WONTFIX i.e. GUI related bugs for 5.x > series. Just ignore anything that is not assigned to area 'grass6'. There was a reasonable effort to assign 'grass6' to all bugs still relevant. Use the interface in the bottom of https://intevation.de/rt/webrt?logout=guest&q_queue=grass to filter the list. I wouldn't go closing old bug, grass5.4, wish etc. entries just to get rid of them not fixing them. Let's keep them open for knowledge about the old versions, they do no harm. Many grass6 bugs miss feedback from reporters and enough information to be able to reproduce them. OTW their status is uncertain, though I don't think it makes sense to close them only for that. So maybe I'll go and assign Current priority '0' to such tickets first, so we can easily ignore them but still have them open just in case? Cheers, Maciek P.S Please CC me doing any change in the BT. I don't want to miss anything. I asked Bernhard and there is no way to automate this with our current BT, so a manual CC is necessary for me to stay updated. From neteler at itc.it Tue Aug 1 23:31:17 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 1 23:31:19 2006 Subject: [GRASS-dev] Re: PNG/Display driver issue? In-Reply-To: <17615.50153.778595.571521@cerise.gclements.plus.com> References: <20060731170011.GA7058@bartok.itc.it> <17614.29707.533532.968495@cerise.gclements.plus.com> <20060731213750.GD8656@bartok.itc.it> <17615.18967.762384.841223@cerise.gclements.plus.com> <20060801125948.GM4691@bartok.itc.it> <17615.24024.841999.286437@cerise.gclements.plus.com> <20060801141200.GW4691@bartok.itc.it> <17615.50153.778595.571521@cerise.gclements.plus.com> Message-ID: <20060801213117.GA19768@bartok.itc.it> (cc'ing list for the sake of documenting the new gislib internals, hope that's ok) [@list: the problem was that d.rast recently started to segfault in a Apache-PHP environment. ] On Tue, Aug 01, 2006 at 10:13:13PM +0100, Glynn Clements wrote: > > Markus Neteler wrote: [ how to debug a process launched by Apache ] > > > Another possible option is to add a sleep() at the beginning of > > > d.rast, then attach to the running process. Debugging a running > > > process is often more reliable than using a core file. > > > > Cool. this works: > > > > ps -aef | grep d.rast > > apache 25804 25650 0 16:03 ? 00:00:00 d.rast BMNG_May.rgb > > > > [neteler@krokus d.rast]$ sudo gdb --pid=25804 > > GNU gdb Red Hat Linux (6.3.0.0-1.96rh) > > This GDB was configured as "x86_64-redhat-linux-gnu". > > Attaching to process 25804 > > Reading symbols from /hardmnt/krokus0/local/grass-6.1.cvs/bin/d.rast...done. > > Using host libthread_db library "/lib64/tls/libthread_db.so.1". > > ... > > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > > 0x0000003ae848f172 in __nanosleep_nocancel () from /lib64/tls/libc.so.6 > > (gdb) c > > Continuing. > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x0000002a95ab1f0e in G__read_row_ptrs (fd=29) at format.c:154 > > 154 fcb->row_ptr[row] = v; > > (gdb) bt full > > #0 0x0000002a95ab1f0e in G__read_row_ptrs (fd=29) at format.c:154 > > v = 4325 > > fcb = (struct fileinfo *) 0x550f50 > > nrows = 1080 > > nbytes = 4 '\004' > > buf = (unsigned char *) 0x550ee0 "" > > b = (unsigned char *) 0x550ee4 "" > > n = 4 > > row = 0 > > I'm pretty certain that this is down to this recent change to lib/gis/G.h: > > revision 2.2 > date: 2006/07/23 01:32:16; author: glynn; state: Exp; lines: +42 -41 > Eliminate use of FCB macro > Dynamically resize G__.fileinfo as required > > The code which resizes the fileinfo array does: > > static struct fileinfo *new_fileinfo(int fd) > { > int oldsize = G__.fileinfo_count; > int newsize = oldsize; > int i; > > if (fd < oldsize) > return &G__.fileinfo[fd]; > > if (!newsize) > newsize = 20; > else > newsize *= 2; > > The first time it's called, it allocates 20 slots, doubling > thereafter. But note that fd == 29; d.rast appears to be inheriting a > lot of descriptors from Apache, resulting in the initial array size of > 20 slots being too small. > > That explains why it doesn't happen when run from the command line, > where it will normally only inherit 3 descriptors (std{in,out,err}). > > The "newsize = 20" should be something like "newsize = fd + 20" > instead. > > [The "fd"s returned by G_open_cell() etc and passed to G_get_*_row() > etc are the actual Unix file descriptors for the [f]cell files, and > are used as indices into the fileinfo array, so you need one fileinfo > slot for every descriptor, regardless of whether those descriptors > correspond to raster maps or something else.] > > -- > Glynn Clements Great job, Glynn. http://grass.itc.it/spearfish/php_grass_earthquakes.php works again... thanks, Markus From holl at gdf-hannover.de Wed Aug 2 07:44:54 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Wed Aug 2 07:45:15 2006 Subject: [GRASS-dev] GRASS 6.1.0 branch status In-Reply-To: <200608012207.32674.maris.gis@gmail.com> References: <20060715155932.GD9134@bartok.itc.it> <20060731201944.GE8229@bartok.itc.it> <44CF8049.9040601@o2.pl> <200608012207.32674.maris.gis@gmail.com> Message-ID: <20060802074454.03ae0658@butan.gdf-hannover.de> Hello M?ris, On Tue, 1 Aug 2006 22:07:32 +0300 M?ris Narti?s wrote: > Could we have some bugday? Or bugweek? It's when no new feature > development occurs and all are trying to close as much bugs as > possible. There could be work for all users - trying to reproduce > bugs, giving aditional info, testing paches etc. Good Idea! I would participate too as tester too. Best Stephan -- GDF Hannover - Solutions for spatial data analysis and remote sensing Hannover Office - Mengendamm 16d - D-30177 Hannover Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 From cavallini at faunalia.it Wed Aug 2 09:00:02 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Wed Aug 2 09:00:22 2006 Subject: GRASS bugs (was: [GRASS-dev] GRASS 6.1.0 branch status) In-Reply-To: <44CFC32D.1010903@o2.pl> References: <20060715155932.GD9134@bartok.itc.it> <20060731201944.GE8229@bartok.itc.it> <44CF8049.9040601@o2.pl> <200608012207.32674.maris.gis@gmail.com> <44CFC32D.1010903@o2.pl> Message-ID: <44D04D72.5030307@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I have a slightly different view here: although it is agreed that the bug report is not an advertising tool, it is clear that new and institutional potential users, as well as potential bugfixers, are scared by very long queues of bugs, especially if: - - most of them do not have an owner (so one can expect they'll not be fixed soon) - - many are very old (> 1 yr, up to > 4yr!). I think the current approach mixes two different needs: - - a bug tracking system - - a knowledge base. I think it is better to separate more clearly the two. I would therefore suggest to close (as unreproducible/wontfix etc.) *all* old bugs; we should not worry about losing relevant info, because they stay on the database - they just don't show on the usual reports, but can be easily checked and reopened if necessary. The best bug reporting tool I'm using is Trac, used eg by qgis: http://svn.qgis.org/trac/report/ very easy to use, powerful, and reports can be customized easily. Could we move to this? Qgissers have done he transition not long ago, so they could give us hints if necessary. A trac package is present eg in Debian, so installation should pose no major problems. I think this should be done before the bugsquishing party, in order to have a more flexible tool and make the work more effective. I'm ready to cooperate on this. pc Maciej Sieczka ha scritto: > > As soon as the schedule is settled I'd like to spread the news on > mailing lists to ask all Grass bug reporters to take a look into their > old BT tickets and update the information there if possible. I think we > should give folks at least about 5 working days for this before the bug > fiesta begins (it's summer time so we might not reach many people but > anyway we should try to have as good background as possible). > >> Some older bugs IMHO could be closed as WONTFIX i.e. GUI related bugs for 5.x >> series. > > Just ignore anything that is not assigned to area 'grass6'. There was a > reasonable effort to assign 'grass6' to all bugs still relevant. Use the > interface in the bottom of > https://intevation.de/rt/webrt?logout=guest&q_queue=grass to filter the > list. > > I wouldn't go closing old bug, grass5.4, wish etc. entries just to get > rid of them not fixing them. Let's keep them open for knowledge about > the old versions, they do no harm. > > Many grass6 bugs miss feedback from reporters and enough information to > be able to reproduce them. OTW their status is uncertain, though I don't > think it makes sense to close them only for that. So maybe I'll go and > assign Current priority '0' to such tickets first, so we can easily > ignore them but still have them open just in case? - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0E1y/NedwLUzIr4RAvf3AJ4nvIDukMZ6KieWd9SeI9wllREV2ACgj8B6 cl/utIof5mdXGCJSdR1ow7g= =Rq2t -----END PGP SIGNATURE----- From dassau at gdf-hannover.de Wed Aug 2 09:29:08 2006 From: dassau at gdf-hannover.de (Otto Dassau) Date: Wed Aug 2 09:27:30 2006 Subject: [GRASS-dev] GRASS 6.1.0 branch status In-Reply-To: <20060802074454.03ae0658@butan.gdf-hannover.de> References: <20060715155932.GD9134@bartok.itc.it> <200608012207.32674.maris.gis@gmail.com> <20060802074454.03ae0658@butan.gdf-hannover.de> Message-ID: <200608020929.08906.dassau@gdf-hannover.de> Am Mittwoch, 2. August 2006 07:44 schrieb Stephan Holl: > Hello M?ris, > > On Tue, 1 Aug 2006 22:07:32 +0300 M?ris Narti?s > > wrote: > > Could we have some bugday? Or bugweek? It's when no new feature > > development occurs and all are trying to close as much bugs as > > possible. There could be work for all users - trying to reproduce > > bugs, giving aditional info, testing paches etc. > > Good Idea! > I would participate too as tester too. I also like the idea and could help testing, too. regards, Otto > Best > Stephan From holl at gdf-hannover.de Wed Aug 2 11:45:48 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Wed Aug 2 11:46:04 2006 Subject: [GRASS-dev] v.db.connect SEGFAULT Message-ID: <20060802114548.0ba1bfc5@butan.gdf-hannover.de> Dear developers, I have encountered a SEGFAULT using v.db.connect. To reproduce, do the following: grass6_cvs /grassdata/spearfish60/user1 v.db.connect -d soils@PERMANENT WARNING: A map which is not in the current mapset cannot be opened for update. Segmentation fault This should at least end without a segfault. gdb --arg v.db.connect -d soils@PERMANENT (gdb) run Starting program: /usr/lib/grass/bin/v.db.connect -d soils@PERMANENT [Thread debugging using libthread_db enabled] [New Thread 1104625824 (LWP 22589)] WARNING: A map which is not in the current mapset cannot be opened for update. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1104625824 (LWP 22589)] 0x40774bed in fflush () from /lib/tls/libc.so.6 (gdb) bt #0 0x40774bed in fflush () from /lib/tls/libc.so.6 #1 0x40030cf0 in Vect_hist_write (Map=0xbffff100, str=0x40049914 "COMMAND: ") at hist.c:64 #2 0x40030bce in Vect_hist_command (Map=0xbffff100) at hist.c:37 #3 0x0804978f in main (argc=3, argv=0xbffff644) at main.c:145 (gdb) If you want me to fill a bug in BT, please let me know. Thanks for looking into this. Best regards Stephan -- GDF Hannover - Solutions for spatial data analysis and remote sensing Hannover Office - Mengendamm 16d - D-30177 Hannover Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 From neteler at itc.it Wed Aug 2 12:00:53 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 12:00:55 2006 Subject: [GRASS-dev] v.db.connect SEGFAULT In-Reply-To: <20060802114548.0ba1bfc5@butan.gdf-hannover.de> References: <20060802114548.0ba1bfc5@butan.gdf-hannover.de> Message-ID: <20060802100053.GD24361@bartok.itc.it> Hi Stephan, fixed. v.db.connect -d soils@PERMANENT WARNING: A map which is not in the current mapset cannot be opened for update. ERROR: Cannot edit vector map stored in other mapset. Probably your soils map is damaged now (at least here it *was* deleting the connection even in another mapset). I simply extracted the new spearfish package over my local copy and restored stuff like this. cheers Markus On Wed, Aug 02, 2006 at 11:45:48AM +0200, Stephan Holl wrote: > Dear developers, > > I have encountered a SEGFAULT using v.db.connect. > > To reproduce, do the following: > > grass6_cvs /grassdata/spearfish60/user1 > v.db.connect -d soils@PERMANENT > WARNING: A map which is not in the current mapset cannot be opened for > update. > Segmentation fault > > This should at least end without a segfault. > > gdb --arg v.db.connect -d soils@PERMANENT > (gdb) run > Starting program: /usr/lib/grass/bin/v.db.connect -d soils@PERMANENT > [Thread debugging using libthread_db enabled] > [New Thread 1104625824 (LWP 22589)] > WARNING: A map which is not in the current mapset cannot be opened for > update. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1104625824 (LWP 22589)] > 0x40774bed in fflush () from /lib/tls/libc.so.6 > (gdb) bt > #0 0x40774bed in fflush () from /lib/tls/libc.so.6 > #1 0x40030cf0 in Vect_hist_write (Map=0xbffff100, str=0x40049914 > "COMMAND: ") at hist.c:64 > #2 0x40030bce in Vect_hist_command (Map=0xbffff100) at hist.c:37 > #3 0x0804978f in main (argc=3, argv=0xbffff644) at main.c:145 > (gdb) > > If you want me to fill a bug in BT, please let me know. > > Thanks for looking into this. > > Best regards > > Stephan > > -- > GDF Hannover - Solutions for spatial data analysis and remote sensing > Hannover Office - Mengendamm 16d - D-30177 Hannover > Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de > Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From holl at gdf-hannover.de Wed Aug 2 12:07:17 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Wed Aug 2 12:07:28 2006 Subject: [GRASS-dev] v.db.connect SEGFAULT In-Reply-To: <20060802100053.GD24361@bartok.itc.it> References: <20060802114548.0ba1bfc5@butan.gdf-hannover.de> <20060802100053.GD24361@bartok.itc.it> Message-ID: <20060802120717.7d713d5e@butan.gdf-hannover.de> Hello Markus, On Wed, 2 Aug 2006 12:00:53 +0200 Markus Neteler wrote: > Hi Stephan, > > fixed. Thank you. Update from CVS solves this? > > v.db.connect -d soils@PERMANENT > WARNING: A map which is not in the current mapset cannot be opened for > update. > ERROR: Cannot edit vector map stored in other mapset. > > Probably your soils map is damaged now (at least here it > *was* deleting the connection even in another mapset). > I simply extracted the new spearfish package over my > local copy and restored stuff like this. OK, mine is still showing up fine. Note, that our PERMANENT-mapset is only readonly for me, so damageing should be hard?! Best Stephan -- GDF Hannover - Solutions for spatial data analysis and remote sensing Hannover Office - Mengendamm 16d - D-30177 Hannover Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 From grass-bugs at intevation.de Wed Aug 2 12:37:32 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Aug 2 12:37:34 2006 Subject: [GRASS-dev] [bug #4947] (grass) ps.map vlegend(border), text(fontsize) doesn't work Message-ID: <20060802103732.AFED9101EE6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4947 ------------------------------------------------------------------------- Subject: ps.map vlegend(border), text(fontsize) doesn't work Platform: GNU/Linux/x86_64 grass obtained from: Other (CDROM etc) grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.0.0 Hallo, I actually don't know if it is a bug. However I didn't find an example in the WWW (forums, etc.) where those options had actually been used. Just found it in the manual. I didn't tried a newer GRASS version yet, also because I couldn't find anything in the change logs of the version 6.0.x concerning this. Here my problem in detail [statement1] vlegend ... border black end [/statement1] [statement2] text ... fontsize 8 end [/statement2] the above statements give the following result ERROR: boarder black : illegal vlegend sub-request ERROR: fontsize 8 : illegal request Any help is apprichiated Sascha -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Aug 2 12:38:32 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Aug 2 12:38:34 2006 Subject: [GRASS-dev] [bug #4948] (grass) ps.map vlegend(border), text(fontsize) doesn't work Message-ID: <20060802103832.12387101EE6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4948 ------------------------------------------------------------------------- Subject: ps.map vlegend(border), text(fontsize) doesn't work Platform: GNU/Linux/x86_64 grass obtained from: Other (CDROM etc) grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.0.0 Hallo, I actually don't know if it is a bug. However I didn't find an example in the WWW (forums, etc.) where those options had actually been used. Just found it in the manual. I didn't tried a newer GRASS version yet, also because I couldn't find anything in the change logs of the version 6.0.x concerning this. Here my problem in detail [statement1] vlegend ... border black end [/statement1] [statement2] text ... fontsize 8 end [/statement2] the above statements give the following result ERROR: boarder black : illegal vlegend sub-request ERROR: fontsize 8 : illegal request Any help is apprichiated Sascha -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Aug 2 12:53:58 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Aug 2 12:53:59 2006 Subject: [GRASS-dev] [bug #4949] (grass) ps.map scalebar - more options like what unit, display unit y/n Message-ID: <20060802105358.6A202101EE7@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4949 ------------------------------------------------------------------------- Subject: ps.map scalebar - more options like what unit, display unit y/n Platform: GNU/Linux/x86_64 grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.0.0 It would be nice if one could add the name of the unit used in the scalebar, e.g. meter, kilometer. Furthermore an option where one can choose in what unit the numbers of the scalebar should be displayed, i.e. meter or kilometer, etc. would be nice. Reasons to 1st request: generally it seems more appropriate to have the unit displayed. to 2nd request: Having a map of the scale 3.000.000 or something like that a scale bar with units in meters (e.g. in UTM) seems also not very nice - its OK, but a scalebar with kilometer units would be nicer in this case. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Aug 2 13:03:36 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Wed Aug 2 13:03:39 2006 Subject: [GRASS-dev] [bug #4947] (grass) ps.map vlegend(border), text(fontsize) doesn't work Message-ID: <20060802110336.DF0BB101EE7@lists.intevation.de> Sascha, If you are not sure if this is a bug ask on the Grass users list first, easy to subscribe: http://grass.itc.it/mailman/listinfo/grassuser Main ps.map expert is away till late August, but there might be other folks able to help you before then. Grass 6.0 is old know. Regarding the relevant changes in ps.map for Grass 6.1 branch you might like to check http://grass.itc.it/grass61/source/snapshot/ChangeLog.gz or browse the CVS repository directly via web browser http://freegis.org/cgi-bin/viewcvs.cgi/grass6/ps/. I'm closing this bug. If it shows there is a bug indeed please reopen it by replying to this email simply. Best, Maciek -------------------------------------------- Managed by Request Tracker From neteler at itc.it Wed Aug 2 13:23:46 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 13:23:48 2006 Subject: [GRASS-dev] v.db.connect SEGFAULT In-Reply-To: <20060802120717.7d713d5e@butan.gdf-hannover.de> References: <20060802114548.0ba1bfc5@butan.gdf-hannover.de> <20060802100053.GD24361@bartok.itc.it> <20060802120717.7d713d5e@butan.gdf-hannover.de> Message-ID: <44D08B42.7030507@itc.it> Stephan Holl wrote on 08/02/2006 12:07 PM: > Hello Markus, > > On Wed, 2 Aug 2006 12:00:53 +0200 Markus Neteler wrote: > > >> Hi Stephan, >> >> fixed. >> > > Thank you. > Update from CVS solves this? > Right - just update the module where I added an error trap. Markus From holl at gdf-hannover.de Wed Aug 2 13:32:20 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Wed Aug 2 13:32:35 2006 Subject: [GRASS-dev] v.extract and sqlite-db Message-ID: <20060802133220.60ad5094@butan.gdf-hannover.de> Dear devs, playing with sqlite as attribute-storage I found out, that the ID needs to be an integer. I tried with this[1] sample spearfish-sqlite-attributedb which has a 'numeric' type for ID. v.db.connect does not complain as long as you do not use v.extract with a where-statement to extract parts of your data. The resulting dataset is broken afterwards. To reproduce in spearfish60: wget [1] g.copy vect=soils@PERMANENT,soils_cp v.db.connect -o map=soils_cp table=soils_legend database=./soils_legend.db driver=sqlite key=id v.db.select soils_cp|head id|shortname|longname 0.000000|no data|no data 1.000000|AaB|Alice fine sandy loam, 0 to 6 ... v.extract in=soils_cp out=soils_steep type=area where="longname LIKE '%steep%'" Load cats from the database (table = soils_legend, db = ./soils_legend.db). 5 cats loaded from the database Building topology ... 194 primitives registered Building areas: 100% 39 areas built 16 isles built Attaching islands: 100% Attaching centroids: 100% Topology was built. Number of nodes : 171 Number of primitives: 194 Number of points : 0 Number of lines : 0 Number of boundaries: 164 Number of centroids : 30 Number of areas : 39 Number of isles : 16 Number of areas without centroid : 9 Writing attributes ... Layer 1 ERROR: Column 'id' is not integer GRASS 6.1.cvs (spearfish60): v.info soils_steep ERROR: Cannot open old vector soils_steep@lausanne_db on level 2 I would suggest, that the driver does not create the dataset, if the id-column is a non-integer. Using a table with an int id-column works fine though. Best Stephan [1] http://mpa.itc.it/grasstutor/scripts/soils_legend.db -- GDF Hannover - Solutions for spatial data analysis and remote sensing Hannover Office - Mengendamm 16d - D-30177 Hannover Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 From holl at gdf-hannover.de Wed Aug 2 13:59:41 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Wed Aug 2 13:59:46 2006 Subject: [GRASS-dev] v.db.connect SEGFAULT In-Reply-To: <44D08B42.7030507@itc.it> References: <20060802114548.0ba1bfc5@butan.gdf-hannover.de> <20060802100053.GD24361@bartok.itc.it> <20060802120717.7d713d5e@butan.gdf-hannover.de> <44D08B42.7030507@itc.it> Message-ID: <20060802135941.0370a2ff@butan.gdf-hannover.de> Hello Markus, On Wed, 02 Aug 2006 13:23:46 +0200 Markus Neteler wrote: > Stephan Holl wrote on 08/02/2006 12:07 PM: > > Hello Markus, > > > > On Wed, 2 Aug 2006 12:00:53 +0200 Markus Neteler > > wrote: > > > > > >> Hi Stephan, > >> > >> fixed. > >> > > > > Thank you. > > Update from CVS solves this? > > > Right - just update the module where I added an error trap. cvs up -dP && make distclean && sh configure_grass60.sh && make v.db.connect -d soils@PERMANENT WARNING: A map which is not in the current mapset cannot be opened for update. Segmentation fault ?! As said, I do not have write-permission to PERMANENT here. Perhaps this might be a problem? Stephan -- GDF Hannover - Solutions for spatial data analysis and remote sensing Hannover Office - Mengendamm 16d - D-30177 Hannover Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 From neteler at itc.it Wed Aug 2 14:02:50 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 14:02:52 2006 Subject: [GRASS-dev] v.extract and sqlite-db In-Reply-To: <20060802133220.60ad5094@butan.gdf-hannover.de> References: <20060802133220.60ad5094@butan.gdf-hannover.de> Message-ID: <20060802120250.GA10564@bartok.itc.it> On Wed, Aug 02, 2006 at 01:32:20PM +0200, Stephan Holl wrote: > Dear devs, > > playing with sqlite as attribute-storage I found out, that the ID needs > to be an integer. I tried with this[1] sample > spearfish-sqlite-attributedb which has a 'numeric' type for ID. > > v.db.connect does not complain as long as you do not use v.extract with > a where-statement to extract parts of your data. > The resulting dataset is broken afterwards. > > To reproduce in spearfish60: > wget [1] > g.copy vect=soils@PERMANENT,soils_cp > v.db.connect -o map=soils_cp table=soils_legend > database=./soils_legend.db driver=sqlite key=id > > v.db.select soils_cp|head > id|shortname|longname > 0.000000|no data|no data > 1.000000|AaB|Alice fine sandy loam, 0 to 6 > ... Interestingly I get v.db.select soils_cp|head -4 id|shortname|longname 0|no data|no data 1|AaB|Alice fine sandy loam, 0 to 6 2|Ba|Barnum silt loam I am using rpm -qf /usr/lib64/libsqlite3.so.0 sqlite-3.3.4-6 but: > v.extract in=soils_cp out=soils_steep type=area where="longname LIKE > '%steep%'" > Load cats from the database (table = soils_legend, db > = ./soils_legend.db). 5 cats loaded from the database > Building topology ... > 194 primitives registered > Building areas: 100% > 39 areas built > 16 isles built > Attaching islands: 100% > Attaching centroids: 100% > Topology was built. > Number of nodes : 171 > Number of primitives: 194 > Number of points : 0 > Number of lines : 0 > Number of boundaries: 164 > Number of centroids : 30 > Number of areas : 39 > Number of isles : 16 > Number of areas without centroid : 9 > Writing attributes ... > Layer 1 > ERROR: Column 'id' is not integer ok, same problem here. DEBUG=3 prints D3/3: table: soils_cp D3/3: select * from soils_legend where 0 = 1 D3/3: Escaped SQL: select * from soils_legend where 0 = 1 D3/3: describe_table() D3/3: ncols = 3 D3/3: litetype = 2 D3/3: litetype = 3 D3/3: litetype = 3 D3/3: nkcols = 3 D3/3: litetype = 2 D2/3: col: id, nkcols 0, litetype : 2, sqltype 6 D3/3: litetype = 3 D2/3: col: shortname, nkcols 1, litetype : 3, sqltype 13 D3/3: litetype = 3 D2/3: col: longname, nkcols 2, litetype : 3, sqltype 13 D3/3: Select cursor opened D3/3: ncols = 3 D3/3: id (DOUBLE PRECISION) ERROR: Column 'id' is not integer Analyzing it with db.describe: db.describe soils_legend table=soils_legend database=./soils_legend.db table:soils_legend description: insert:? delete:? ncols:3 column:id description: type:DOUBLE PRECISION len:99999 scale:0 precision:0 default: nullok:yes select:? update:? ... The problem is that SQLite is type agnostic. http://www.sqlite.org/datatype3.html states: "The key here is that the type is recommended, not required. Any column can still store any type of data, in theory." The only solution I see (while not knowing much about it!) is to scan the entire cat (here 'ID') column if it contains only integer values, if so, accept it as key column for v.extract or other commands, otherwise refuse. > GRASS 6.1.cvs (spearfish60): > > v.info soils_steep > ERROR: Cannot open old vector soils_steep@lausanne_db on level 2 > > I would suggest, that the driver does not create the dataset, if the > id-column is a non-integer. In SQLite it's always non-integer/or non-integer is always possible. > Using a table with an int id-column works fine though. I fear that it worked by chance. Does anyone have a suggestion how to resolve this problem? Not sure if the "Strict affinity mode" can help. To do a round() cannot be the solution... Markus > Best > > Stephan > > [1] http://mpa.itc.it/grasstutor/scripts/soils_legend.db > > -- > GDF Hannover - Solutions for spatial data analysis and remote sensing > Hannover Office - Mengendamm 16d - D-30177 Hannover > Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de > Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From holl at gdf-hannover.de Wed Aug 2 14:20:14 2006 From: holl at gdf-hannover.de (Stephan Holl) Date: Wed Aug 2 14:20:27 2006 Subject: [GRASS-dev] v.extract and sqlite-db In-Reply-To: <20060802120250.GA10564@bartok.itc.it> References: <20060802133220.60ad5094@butan.gdf-hannover.de> <20060802120250.GA10564@bartok.itc.it> Message-ID: <20060802142014.786d694d@butan.gdf-hannover.de> Hello Markus, On Wed, 2 Aug 2006 14:02:50 +0200 Markus Neteler wrote: > On Wed, Aug 02, 2006 at 01:32:20PM +0200, Stephan Holl wrote: > > Dear devs, > > > > playing with sqlite as attribute-storage I found out, that the ID > > needs to be an integer. I tried with this[1] sample > > spearfish-sqlite-attributedb which has a 'numeric' type for ID. > > > > v.db.connect does not complain as long as you do not use v.extract > > with a where-statement to extract parts of your data. > > The resulting dataset is broken afterwards. > > > > To reproduce in spearfish60: > > wget [1] > > g.copy vect=soils@PERMANENT,soils_cp > > v.db.connect -o map=soils_cp table=soils_legend > > database=./soils_legend.db driver=sqlite key=id > > > > v.db.select soils_cp|head > > id|shortname|longname > > 0.000000|no data|no data > > 1.000000|AaB|Alice fine sandy loam, 0 to 6 > > ... > > Interestingly I get > v.db.select soils_cp|head -4 > id|shortname|longname > 0|no data|no data > 1|AaB|Alice fine sandy loam, 0 to 6 > 2|Ba|Barnum silt loam > > I am using > rpm -qf /usr/lib64/libsqlite3.so.0 > sqlite-3.3.4-6 ?! > but: > > > v.extract in=soils_cp out=soils_steep type=area where="longname LIKE > > '%steep%'" > > Load cats from the database (table = soils_legend, db > > = ./soils_legend.db). 5 cats loaded from the database > > Building topology ... > > 194 primitives registered > > Building areas: 100% > > 39 areas built > > 16 isles built > > Attaching islands: 100% > > Attaching centroids: 100% > > Topology was built. > > Number of nodes : 171 > > Number of primitives: 194 > > Number of points : 0 > > Number of lines : 0 > > Number of boundaries: 164 > > Number of centroids : 30 > > Number of areas : 39 > > Number of isles : 16 > > Number of areas without centroid : 9 > > Writing attributes ... > > Layer 1 > > ERROR: Column 'id' is not integer > > ok, same problem here. > > DEBUG=3 prints > > D3/3: table: soils_cp > D3/3: select * from soils_legend where 0 = 1 > D3/3: Escaped SQL: select * from soils_legend where 0 = 1 > D3/3: describe_table() > D3/3: ncols = 3 > D3/3: litetype = 2 > D3/3: litetype = 3 > D3/3: litetype = 3 > D3/3: nkcols = 3 > D3/3: litetype = 2 > D2/3: col: id, nkcols 0, litetype : 2, sqltype 6 > D3/3: litetype = 3 > D2/3: col: shortname, nkcols 1, litetype : 3, sqltype 13 > D3/3: litetype = 3 > D2/3: col: longname, nkcols 2, litetype : 3, sqltype 13 > D3/3: Select cursor opened > D3/3: ncols = 3 > D3/3: id (DOUBLE PRECISION) > ERROR: Column 'id' is not integer > > Analyzing it with db.describe: > > db.describe soils_legend table=soils_legend database=./soils_legend.db > table:soils_legend > description: > insert:? > delete:? > ncols:3 > > column:id > description: > type:DOUBLE PRECISION > len:99999 > scale:0 > precision:0 > default: > nullok:yes > select:? > update:? > ... > > The problem is that SQLite is type agnostic. > http://www.sqlite.org/datatype3.html states: > > "The key here is that the type is recommended, not required. Any > column can still store any type of data, in theory." > > The only solution I see (while not knowing much about it!) is > to scan the entire cat (here 'ID') column if it contains only integer > values, if so, accept it as key column for v.extract or other > commands, otherwise refuse. Why cannot we cast to int()? > > GRASS 6.1.cvs (spearfish60): > > > > v.info soils_steep > > ERROR: Cannot open old vector soils_steep@lausanne_db on level 2 > > > > I would suggest, that the driver does not create the dataset, if the > > id-column is a non-integer. > > In SQLite it's always non-integer/or non-integer is always possible. > > > Using a table with an int id-column works fine though. > > I fear that it worked by chance. > > Does anyone have a suggestion how to resolve this problem? Probably a correct exit without segfault and an appropriate error meassage e.g.: ERROR: Column 'id' is not integer > Not sure if the "Strict affinity mode" can help. To do a round() > cannot be the solution... Stephan -- GDF Hannover - Solutions for spatial data analysis and remote sensing Hannover Office - Mengendamm 16d - D-30177 Hannover Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508 From neteler at itc.it Wed Aug 2 14:32:52 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 14:32:54 2006 Subject: [GRASS-dev] v.extract and sqlite-db In-Reply-To: <20060802142014.786d694d@butan.gdf-hannover.de> References: <20060802133220.60ad5094@butan.gdf-hannover.de> <20060802120250.GA10564@bartok.itc.it> <20060802142014.786d694d@butan.gdf-hannover.de> Message-ID: <20060802123252.GC10564@bartok.itc.it> Hi, ok, I found a workaround. On Wed, Aug 02, 2006 at 02:20:14PM +0200, Stephan Holl wrote: > On Wed, 2 Aug 2006 14:02:50 +0200 Markus Neteler wrote: > > On Wed, Aug 02, 2006 at 01:32:20PM +0200, Stephan Holl wrote: I have changed the column type from 'numeric' to 'integer primary key' using sqlitebrowser. Find the new table here: http://mpa.itc.it/grasstutor/scripts/soils_legend.db > > Does anyone have a suggestion how to resolve this problem? > > Probably a correct exit without segfault and an appropriate error > meassage e.g.: ERROR: Column 'id' is not integer Mhh, the current message is: ... Writing attributes ... Layer 1 ERROR: Column 'id' is not integer and it doesn't segfault (for me). Anyway, for the example it should be solved. Please try... Markus From tutey at o2.pl Wed Aug 2 14:37:37 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Aug 2 14:37:42 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <44D04D72.5030307@faunalia.it> References: <20060715155932.GD9134@bartok.itc.it> <20060731201944.GE8229@bartok.itc.it> <44CF8049.9040601@o2.pl> <200608012207.32674.maris.gis@gmail.com> <44CFC32D.1010903@o2.pl> <44D04D72.5030307@faunalia.it> Message-ID: <44D09C91.40100@o2.pl> Paolo Cavallini napisa?(a): > Hi all. > I have a slightly different view here: although it is agreed that the > bug report is not an advertising tool, it is clear that new and > institutional potential users, as well as potential bugfixers, are > scared by very long queues of bugs, especially if: > - most of them do not have an owner (so one can expect they'll not be > fixed soon) > - many are very old (> 1 yr, up to > 4yr!). I agree that the BT is a bit PR tool whether we like it or not... > I think the current approach mixes two different needs: > - a bug tracking system > - a knowledge base. > I think it is better to separate more clearly the two. > I would therefore suggest to close (as unreproducible/wontfix etc.) > *all* old bugs; we should not worry about losing relevant info, because > they stay on the database - they just don't show on the usual reports, > but can be easily checked and reopened if necessary. I could assign 'stalled' to all besides grass6, wish6 and doc*6 tickets. Do Others think it would be right? > The best bug reporting tool I'm using is Trac, used eg by qgis: > http://svn.qgis.org/trac/report/ > very easy to use, powerful, and reports can be customized easily. Could > we move to this? (Bernard has recently told that a move to Gforge at http://wald.intevation.org/ is planned.) Bernhard, is there a time schedule for that yet? How would Gforge compare to Trac? > Qgissers have done he transition not long ago, so they > could give us hints if necessary. A trac package is present eg in > Debian, so installation should pose no major problems. I personally don't like Trac's WIKI like format; it makes reporting bugs over complicated, which might scare off naive users. The WIKI formatting should be only an addition to allow formatting when needed. It should not not the requirement only to fill in a 10 word report. > I think this should be done before the bugsquishing party, in order to > have a more flexible tool and make the work more effective. I'd would be OK with me *if* moving to another bug tracking system is a realistic plan for close future. > I'm ready to cooperate on this. Maciek P.S. Let's hold off planning the bug fiest schedule until the issues here are sorted out. From cavallini at faunalia.it Wed Aug 2 14:46:47 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Wed Aug 2 14:46:48 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <44D09C91.40100@o2.pl> References: <20060715155932.GD9134@bartok.itc.it> <20060731201944.GE8229@bartok.itc.it> <44CF8049.9040601@o2.pl> <200608012207.32674.maris.gis@gmail.com> <44CFC32D.1010903@o2.pl> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> Message-ID: <44D09EB7.5020907@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maciej Sieczka ha scritto: > I agree that the BT is a bit PR tool whether we like it or not... Glad we agree. >> The best bug reporting tool I'm using is Trac, used eg by qgis: >> http://svn.qgis.org/trac/report/ >> very easy to use, powerful, and reports can be customized easily. Could >> we move to this? > > (Bernard has recently told that a move to Gforge at > http://wald.intevation.org/ is planned.) > > Bernhard, is there a time schedule for that yet? > > How would Gforge compare to Trac? I used both, and found trac far more straightforward. > I personally don't like Trac's WIKI like format; it makes reporting bugs > over complicated, which might scare off naive users. The WIKI formatting > should be only an addition to allow formatting when needed. It should > not not the requirement only to fill in a 10 word report. ? You can enter straight text, I do not see problems here. >> I think this should be done before the bugsquishing party, in order to >> have a more flexible tool and make the work more effective. > > I'd would be OK with me *if* moving to another bug tracking system is a > realistic plan for close future. > > Let's hold off planning the bug fiest schedule until the issues here are > sorted out. Agreed. pc - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0J63/NedwLUzIr4RAgWnAJ91I94PMTaB2AZq9NYQUl1vYQrc1ACaAqMG V9jwh29F/piRaq0RgVhvqBg= =0uU0 -----END PGP SIGNATURE----- From epatton at nrcan.gc.ca Wed Aug 2 14:55:18 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Wed Aug 2 14:55:22 2006 Subject: [GRASS-dev] GRASS 6.1.0 branch status Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55B0E@s5-dar-r1.nrn.nrcan.gc.ca> I am available for bug testing as well. ~ Eric. -----Original Message----- From: grass-dev-bounces@grass.itc.it To: grass-dev@grass.itc.it Sent: 8/2/2006 3:29 AM Subject: Re: [GRASS-dev] GRASS 6.1.0 branch status Am Mittwoch, 2. August 2006 07:44 schrieb Stephan Holl: > Hello Maris, > > On Tue, 1 Aug 2006 22:07:32 +0300 Maris Narti?s > > wrote: > > Could we have some bugday? Or bugweek? It's when no new feature > > development occurs and all are trying to close as much bugs as > > possible. There could be work for all users - trying to reproduce > > bugs, giving aditional info, testing paches etc. > > Good Idea! > I would participate too as tester too. I also like the idea and could help testing, too. regards, Otto > Best > Stephan _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev From tutey at o2.pl Wed Aug 2 16:05:53 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Aug 2 16:05:57 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <44D09EB7.5020907@faunalia.it> References: <20060715155932.GD9134@bartok.itc.it> <20060731201944.GE8229@bartok.itc.it> <44CF8049.9040601@o2.pl> <200608012207.32674.maris.gis@gmail.com> <44CFC32D.1010903@o2.pl> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> <44D09EB7.5020907@faunalia.it> Message-ID: <44D0B141.6010508@o2.pl> Paolo Cavallini napisa?(a): > Maciej Sieczka ha scritto: > > I agree that the BT is a bit PR tool whether we like it or not... > > Glad we agree. > >>>> The best bug reporting tool I'm using is Trac, used eg by qgis: >>>> http://svn.qgis.org/trac/report/ >>>> very easy to use, powerful, and reports can be customized easily. Could >>>> we move to this? >>> (Bernard has recently told that a move to Gforge at >>> http://wald.intevation.org/ is planned.) >>> >>> Bernhard, is there a time schedule for that yet? >>> >>> How would Gforge compare to Trac? > > I used both, and found trac far more straightforward. > >>> I personally don't like Trac's WIKI like format; it makes reporting bugs >>> over complicated, which might scare off naive users. The WIKI formatting >>> should be only an addition to allow formatting when needed. It should >>> not not the requirement only to fill in a 10 word report. > > ? You can enter straight text, I do not see problems here. I at least recall there are is an issue with linebreaks in Trac. Eg, if you do: 1. Point one. 2. Point two. it will become; 1. Point one.2. Point two. You have to remember to do it like: 1. Point one. 2. Point two. to avoid that. More gotchas I don't remember now. >>> Let's hold off planning the bug fiest schedule until the issues here are >>> sorted out. > > Agreed. *And* we need more C programmers. And tcltk propably too. Maciek From bernhard at intevation.de Wed Aug 2 16:34:59 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed Aug 2 16:35:11 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <44D09C91.40100@o2.pl> References: <20060715155932.GD9134@bartok.itc.it> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> Message-ID: <200608021635.04164.bernhard@intevation.de> Am Mittwoch, 2. August 2006 14:37 schrieb Maciej Sieczka: > Paolo Cavallini napisa?(a): > > Hi all. > > I have a slightly different view here: although it is agreed that the > > bug report is not an advertising tool, it is clear that new and > > institutional potential users, as well as potential bugfixers, are > > scared by very long queues of bugs, especially if: > > - most of them do not have an owner (so one can expect they'll not be > > fixed soon) > > - many are very old (> 1 yr, up to > 4yr!). > > I agree that the BT is a bit PR tool whether we like it or not... Partly it is, but the technical values should come first. It is better to conserve bugs that are not fixed then to clear them out for marketing purposes. > > I think the current approach mixes two different needs: > > - a bug tracking system > > - a knowledge base. > > I think it is better to separate more clearly the two. > > I would therefore suggest to close (as unreproducible/wontfix etc.) > > *all* old bugs; we should not worry about losing relevant info, because > > they stay on the database - they just don't show on the usual reports, > > but can be easily checked and reopened if necessary. If the stable version is considered stable by many many users then a clearing policy for old bugs in an old version is fine. It mostly depends how it is done. > I could assign 'stalled' to all besides grass6, wish6 and doc*6 tickets. > Do Others think it would be right? Depends on the bugs. What I did in the past sometimes was to ask the original reported if he or she tried a new version and that we might close the bug report after a time period, if there is no response. All if I believed the bug was gone for the new stable series. > > The best bug reporting tool I'm using is Trac, used eg by qgis: > > http://svn.qgis.org/trac/report/ > > very easy to use, powerful, and reports can be customized easily. Could > > we move to this? > > (Bernard has recently told that a move to Gforge at > http://wald.intevation.org/ is planned.) > > Bernhard, is there a time schedule for that yet? No, it depends a bit on me having a time block and feeling comfortable of having found most issues with large projects on wald already. Currently I like to fix some things on our installation first. There is a tracker for the bugs on wald itself. > How would Gforge compare to Trac? It is different in a few ways. A point for Gforge is that many people now the interface from savannah or similiar services. And it is modular, so that maybe more modules can be added in the future. > > I think this should be done before the bugsquishing party, in order to > > have a more flexible tool and make the work more effective. > > I'd would be OK with me *if* moving to another bug tracking system is a > realistic plan for close future. I would plan a bugsquishing party indepentely from the bugtracker move, as the hassles of the tracker are the minor concern. Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060802/8d39df96/attachment.bin From neteler at itc.it Wed Aug 2 17:15:58 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 17:16:01 2006 Subject: [GRASS-dev] v.digit startup error from -n position Message-ID: <20060802151558.GL10564@bartok.itc.it> Hi, I found a problem starting v.digit from the tcltk GUI: v.digit map=cities 'bgcmd=d.rast landcover.30m' -n New empty map created. Application initialization failed: "-n" option requires an additional argument Error in startup script: couldn't read file "map=cities": no such file or directory while v.digit -n map=cities 'bgcmd=d.rast landcover.30m' works (see -n position). Strange for me, since G_parser is used... Any ideas? Is it related to bgcmd_opt parsing? I think that the gtcltk code should in general put flags first (which would resolve the problem here). Markus From cavallini at faunalia.it Wed Aug 2 17:18:20 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Wed Aug 2 17:18:22 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <200608021635.04164.bernhard@intevation.de> References: <20060715155932.GD9134@bartok.itc.it> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> <200608021635.04164.bernhard@intevation.de> Message-ID: <44D0C23C.5030709@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bernhard Reiter ha scritto: > Partly it is, but the technical values should come first. > It is better to conserve bugs that are not fixed then > to clear them out for marketing purposes. Right. No real bug should be cleared, but I think we're now in the opposite position: we got a bug infestation! > If the stable version is considered stable by many many users > then a clearing policy for old bugs in an old version is fine. > It mostly depends how it is done. I do not think anybody considers grass5.x the main stable version nowadays. > What I did in the past sometimes was to ask the original reported > if he or she tried a new version and that we might close the bug report > after a time period, if there is no response. > All if I believed the bug was gone for the new stable series. Agreed. I tried this last year (or maybe longer ago?), and I got very few replies. Apparently there are individuals who casually try grass, get a problem, write a report, then disappear. This is what we have to get rid of, I think. All the best. pc - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0MI8/NedwLUzIr4RAmhaAJ4zj6xd+8m8NkpztKYApkRUIEgTNACgqmG3 Kf/LN1aq47uiWJpk+HpfVIo= =6sqR -----END PGP SIGNATURE----- From grass-bugs at intevation.de Wed Aug 2 17:26:44 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Aug 2 17:26:47 2006 Subject: [GRASS-dev] [bug #4951] (grass) proj folder and EPSG codes non-existant after 6.1 cygwin download Message-ID: <20060802152644.DA7E3101EE6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4951 ------------------------------------------------------------------------- Subject: proj folder and EPSG codes non-existant after 6.1 cygwin download Platform: WindowsNT/2000/XP grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.1 J Ready Installed Grass 6.1 using cygwin. Once installed, it opened up. I started to 'Create location from EPSG' only to find that folder proj does not exist. Searched in surrounding folders with no luck. tried installing proj package from cygwin again (twice) with no change in results -------------------------------------------- Managed by Request Tracker From neteler at itc.it Wed Aug 2 17:27:20 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 17:27:21 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <44D0C23C.5030709@faunalia.it> References: <20060715155932.GD9134@bartok.itc.it> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> <200608021635.04164.bernhard@intevation.de> <44D0C23C.5030709@faunalia.it> Message-ID: <20060802152720.GM10564@bartok.itc.it> On Wed, Aug 02, 2006 at 05:18:20PM +0200, Paolo Cavallini wrote: > Bernhard Reiter ha scritto: ... > > What I did in the past sometimes was to ask the original reported > > if he or she tried a new version and that we might close the bug report > > after a time period, if there is no response. > > All if I believed the bug was gone for the new stable series. > > Agreed. I tried this last year (or maybe longer ago?), and I got very > few replies. Apparently there are individuals who casually try grass, > get a problem, write a report, then disappear. This is what we have to > get rid of, I think. Well, I have cleaned up quite a few of such reports recently. There is a basic problem in RT: AFAIK we don't have a "WON'T FIX" button there. But generally: why wait for a bugfix party? Just go ahead... Bernhard: could you post some RT usage statistics as you did some months/years ago? Markus From maris.gis at gmail.com Wed Aug 2 17:38:40 2006 From: maris.gis at gmail.com (=?utf-8?q?M=C4=81ris_Narti=C5=A1s?=) Date: Wed Aug 2 17:38:56 2006 Subject: [GRASS-dev] Bug day wrap-up Message-ID: <200608021838.41836.maris.gis@gmail.com> Hi all, as I see, lots of people liked idea about bug day. I first heard about such happening from Gnome users. They even have web page for that: http://live.gnome.org/Bugsquad/BugDays As idea of new GRASS bug tracking system poped up, there are 3 q's: - how far (in time) is new bug tracking system? - is possible to get it running before 6.1.0 release? (or it can wait) - which product will be used for that? (maybee voting at grass-dev with +1 -1 for short list of options?) Markus: how far is GRASS 6.1.0 beta2 (if there would be such one)? My proposal: If there will be 6.1 beta2, then we could use beta2 to test grass6 marked bugs. As result we could divide bugs in 4 categories: - fixed - quick fix or already fixed in beta2; - longterm - applays to 6.1 beta2 and would not be fixed in 6.1.0. Those go to "Known bugs" list; - need more info - cant reproduce it and if bug reporter would not provide additional info about bug in reasonable time frame (2 months?), this bug will be closed. (bugzilla.kernel.org has something similar); - other - duplicates, wrong ones (like missing RTFM thing), etc. Pros for such action: - GRASS bug system is cleaned-up for migration to new software; - 6.1.0 release is a bit better :) Cons: - there may flow-up some showstoppers for 6.1.0 thus delaying release. Any comments, ideas etc. welcomed. Maris. From mlennert at club.worldonline.be Wed Aug 2 17:40:27 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Aug 2 17:40:30 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <20060802152720.GM10564@bartok.itc.it> References: <20060715155932.GD9134@bartok.itc.it> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> <200608021635.04164.bernhard@intevation.de> <44D0C23C.5030709@faunalia.it> <20060802152720.GM10564@bartok.itc.it> Message-ID: <44D0C76B.30709@club.worldonline.be> Markus Neteler wrote: > But generally: why wait for a bugfix party? Just go ahead... > I don't think it is about waiting, it is about creating a special, motivating event where everyone works together on one goal. Moritz From neteler at itc.it Wed Aug 2 17:45:31 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 17:45:33 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <44D0C76B.30709@club.worldonline.be> References: <20060715155932.GD9134@bartok.itc.it> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> <200608021635.04164.bernhard@intevation.de> <44D0C23C.5030709@faunalia.it> <20060802152720.GM10564@bartok.itc.it> <44D0C76B.30709@club.worldonline.be> Message-ID: <20060802154531.GN10564@bartok.itc.it> On Wed, Aug 02, 2006 at 05:40:27PM +0200, Moritz Lennert wrote: > Markus Neteler wrote: > >But generally: why wait for a bugfix party? Just go ahead... > > > > I don't think it is about waiting, it is about creating a special, > motivating event where everyone works together on one goal. Aren't we doing that all the time? :-) I wouldn't make it too complicated. People even live in different time zones etc. Markus From neteler at itc.it Wed Aug 2 18:08:29 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 18:08:32 2006 Subject: [GRASS-dev] GRASS 6.1.0RC1 released Message-ID: <20060802160829.GO10564@bartok.itc.it> Dear all, I have packaged the source code of GRASS 6.1.0RC1: http://grass.itc.it/grass61/source/ More than 40 fixes have been backported from beta1 to RC1. See the ChangeLog_6.1.0RC1.gz for details. Please test the new tarball. If things go well, we can publish it as 6.1.0 shortly. Thanks to all contributors, Markus -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From glynn at gclements.plus.com Wed Aug 2 18:29:16 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Aug 2 18:29:20 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <44D0C76B.30709@club.worldonline.be> References: <20060715155932.GD9134@bartok.itc.it> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> <200608021635.04164.bernhard@intevation.de> <44D0C23C.5030709@faunalia.it> <20060802152720.GM10564@bartok.itc.it> <44D0C76B.30709@club.worldonline.be> Message-ID: <17616.53980.563594.551273@cerise.gclements.plus.com> Moritz Lennert wrote: > > But generally: why wait for a bugfix party? Just go ahead... > > I don't think it is about waiting, it is about creating a special, > motivating event where everyone works together on one goal. The one thing which would do the most to motivate me to fix bugs would be a list of clearly-identified, verified, reproducible bugs. Back when I used to check the RT occasionally, I would generally skip any report where I couldn't quickly reproduce the problem from the information contained in the report. As this tends to be the case for the vast majority of reports, I eventually gave up checking the RT altogether (other than to kill requests generated by spam email to the grass-bugs address). If people want a bug to get fixed, by far the most important factor is providing a clear mechanism to demonstrate the bug, either using the spearfish dataset or starting from a new location (i.e. using self-generated test data). -- Glynn Clements From neteler at itc.it Wed Aug 2 18:36:51 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 18:36:54 2006 Subject: [GRASS-dev] Planning for GRASS 6.2 Message-ID: <20060802163651.GP10564@bartok.itc.it> Hi, GRASS 6.1-CVS HEAD meanwhile contains various fixes and improvements which are too complicated to be backported to the release branch. My suggestions are: - test 6.1.0RC1, eventuall release it as 6.1.0 without further backports. Stop working on this branch - do the bug day soon - don't submit changes with heavy impact for short time In 2-4 weeks from now (?): - create a new branch for 6.2, maintain it for a while - rename 6.1-CVS HEAD to 6.3-CVS HEAD to enable developers again to submit complex changes. Maybe a few things can be anticipated from the GRASS 7 planning [1] (respecting our rules to keep parameters/flags/behaviour as much as possible for the 6.x series) In general 6.2 should not deviate too much from the current 6.1-CVS HEAD to avoid a major delay. It would be great to have it available for FOSS4G2006 in September. Opinions? Markus [1] http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection -- Markus Neteler http://mpa.itc.it/markus/ ITC-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 Aug 2 18:57:09 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Aug 2 18:56:26 2006 Subject: [GRASS-dev] v.digit startup error from -n position In-Reply-To: <20060802151558.GL10564@bartok.itc.it> Message-ID: I thought that Glynn fixed this last week. I can't remember exactly, but it had to do with the same kind of string/command parsing that has repeatedly plagued us. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Markus Neteler > Date: Wed, 2 Aug 2006 17:15:58 +0200 > To: GRASS developers list > Subject: [GRASS-dev] v.digit startup error from -n position > > Hi, > > I found a problem starting v.digit from the tcltk GUI: > > v.digit map=cities 'bgcmd=d.rast landcover.30m' -n > New empty map created. > > Application initialization failed: "-n" option requires an additional argument > Error in startup script: couldn't read file "map=cities": no such file or > directory > > while > v.digit -n map=cities 'bgcmd=d.rast landcover.30m' > > works (see -n position). Strange for me, since G_parser is used... > > Any ideas? Is it related to bgcmd_opt parsing? > > I think that the gtcltk code should in general put flags > first (which would resolve the problem here). > > Markus > > From tutey at o2.pl Wed Aug 2 19:15:56 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Aug 2 19:16:01 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <17616.53980.563594.551273@cerise.gclements.plus.com> References: <20060715155932.GD9134@bartok.itc.it> <44D04D72.5030307@faunalia.it> <44D09C91.40100@o2.pl> <200608021635.04164.bernhard@intevation.de> <44D0C23C.5030709@faunalia.it> <20060802152720.GM10564@bartok.itc.it> <44D0C76B.30709@club.worldonline.be> <17616.53980.563594.551273@cerise.gclements.plus.com> Message-ID: <44D0DDCC.8020302@o2.pl> Glynn Clements napisa?(a): > Moritz Lennert wrote: > >>> But generally: why wait for a bugfix party? Just go ahead... >> I don't think it is about waiting, it is about creating a special, >> motivating event where everyone works together on one goal. > > The one thing which would do the most to motivate me to fix bugs would > be a list of clearly-identified, verified, reproducible bugs. I can do that and will send it to the list. Most likely next week. If there is no obvious test case I will try to create it based on spearfish. To all you Guys who were willing to help with testing during the bug sqaushing party: please give me a hand with that. Each of you, pick few reports, verify it using spearfish, or, for bugs in the interface etc., just verify if it is still present in current CVS. Then 'reply' from the tracker CCing me at my email. You can do it all even as guest, just make sure you sign with name and email. If I counted OK there should be 5 testers alltogether. Such a band can clean the mess up easily. Anybody - please join! > Back when I used to check the RT occasionally, I would generally skip > any report where I couldn't quickly reproduce the problem from the > information contained in the report. I agree this is often the case that people don't document their reports well enough, but this doesn't mean such reports should be ignored completely. > As this tends to be the case for the vast majority of reports, I > eventually gave up checking the RT altogether > (other than to kill requests generated by spam email to the grass-bugs > address). Please don't waste your time. This is such an easy task I can do it myself (and I'm doing it). > If people want a bug to get fixed, by far the most important factor is > providing a clear mechanism to demonstrate the bug, either using the > spearfish dataset or starting from a new location (i.e. using > self-generated test data). I know, I've failed to do it often too. But I also reported bugs, and saw other's reports, documented well but still never taken care of. You are right there is a need to clean up the tracker further to make developers' work easier. I'll work on this as I can. Maciek From tutey at o2.pl Wed Aug 2 19:17:34 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Aug 2 19:17:38 2006 Subject: [GRASS-dev] v.digit startup error from -n position In-Reply-To: References: Message-ID: <44D0DE2E.6000407@o2.pl> Markus, Michael, https://intevation.de/rt/webrt?serial_num=4604 Maciek From epatton at nrcan.gc.ca Wed Aug 2 19:20:34 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Wed Aug 2 19:20:45 2006 Subject: [GRASS-dev] v.digit startup error from -n position Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55B0F@s5-dar-r1.nrn.nrcan.gc.ca> Markus, I think that I found the same problem in this thread: http://grass.itc.it/pipermail/grass5/2006-July/024559.html As Michael said, Glynn had an explanation for this problem, but I can't seem to track his post down. ~ Eric. -----Original Message----- From: grass-dev-bounces@grass.itc.it To: GRASS developers list Sent: 8/2/2006 11:15 AM Subject: [GRASS-dev] v.digit startup error from -n position Hi, I found a problem starting v.digit from the tcltk GUI: v.digit map=cities 'bgcmd=d.rast landcover.30m' -n New empty map created. Application initialization failed: "-n" option requires an additional argument Error in startup script: couldn't read file "map=cities": no such file or directory while v.digit -n map=cities 'bgcmd=d.rast landcover.30m' works (see -n position). Strange for me, since G_parser is used... Any ideas? Is it related to bgcmd_opt parsing? I think that the gtcltk code should in general put flags first (which would resolve the problem here). Markus _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev From bcovill at tekmap.ns.ca Wed Aug 2 19:21:42 2006 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Wed Aug 2 19:21:49 2006 Subject: [GRASS-dev] rotated ps.map Message-ID: <1154539302.6813.7.camel@linuxmain.localhost> Hello, I recently noticed a small bug(?) is ps.map. If the "-r" option is used to rotate the plot, the output scale is automatically adjusted based on an un-rotated map. In other words a map scaled to nicely fit on a rotated page is scaled down based on the dimensions of the page which is not rotated. The attached patch for r_paper.c should fix this problem. Please test and see if this is the best solution (maybe there is an easier fix) to the problem. Thanks. -- Bob -------------- next part -------------- A non-text attachment was scrubbed... Name: r_paper.patch Type: text/x-patch Size: 2122 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060802/7df2f0f0/r_paper.bin From michael.barton at asu.edu Wed Aug 2 19:38:55 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Aug 2 19:38:13 2006 Subject: [GRASS-dev] v.digit startup error from -n position In-Reply-To: <44D0DE2E.6000407@o2.pl> Message-ID: OK. Looking through to the very bottom of the thread, there appears to be some confusion about what is meant by GUI. If v.digit is having a problem with a new vector when run from the toolbar button in gism, it is one thing. This SHOULD be OK. I've checked the code and it is written... v.digit -n map=new_map ... as Glynn indicated. If this is where the problem lies, then, there is some other kind of issue. Glynn also noted, however, that in the auto-generated GUI dialogs, this is being written as... v.digit map=new_map -n This causes a problem because the -n is misinterpreted by TclTk as a flag in the TclTk command. So if the problem arises when v.digit is run from a menu or the dialog is started from the CLI by simply typing v.digit, then THIS is where the problem lies. Generically, the GRASS flags should come before any other arguments it seems. I don't know where this is coded, but Cedric should know. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Maciej Sieczka > Date: Wed, 02 Aug 2006 19:17:34 +0200 > To: Michael Barton > Cc: Markus Neteler , GRASS developers list > > Subject: Re: [GRASS-dev] v.digit startup error from -n position > > Markus, Michael, > > https://intevation.de/rt/webrt?serial_num=4604 > > Maciek From grass-bugs at intevation.de Wed Aug 2 20:44:23 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Wed Aug 2 20:44:26 2006 Subject: [GRASS-dev] [bug #4604] (grass) tcl/tk GUI: v.digit can't create new vector in GUI mode Message-ID: <20060802184423.3A3F3101EFC@lists.intevation.de> This was trivial to fix (seeing Glynn's last comment). Strange that it didn't happen. Fixed. Markus -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Aug 2 21:36:51 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Wed Aug 2 21:36:53 2006 Subject: [GRASS-dev] [bug #3079] (grass) db.droptable is not available Message-ID: <20060802193651.4AE9F101EFC@lists.intevation.de> This problem is sill actual. There is a db.droptable manual, but no the command itself. Starnge, I thought manuals are built only for available commands? Using Grass 6.1 CVS today, built from source. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Aug 2 21:54:06 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Wed Aug 2 21:54:08 2006 Subject: [GRASS-dev] [bug #4725] (grass) nviz crashed while volume visualisation Message-ID: <20060802195406.E092E101EE6@lists.intevation.de> Hi, [ http://intevation.de/rt/webrt?serial_num=4725 ] I just tested the volume with the Slovakia3D dataset: it works again. Whatever happened, but NVIZ volume visualization seems to be back. GRASS 6.1.cvs (slovakia3d):~ > nviz dem500 volume=precip3d.500z50 Loading Data Update elev null mask Loading Data translating colors from fp recalculating normals... % [Raster MASK present] GRASS 6.1.cvs (slovakia3d):~ > Someone please test this with 6.1.0RC1. Enter Panel -> volume -> add -> constant -> 1000 to visualize an isosurface. Or read the README of the dataset. Markus -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Wed Aug 2 22:20:52 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Wed Aug 2 22:20:54 2006 Subject: [GRASS-dev] [bug #4951] (grass) proj folder and EPSG codes non-existant after 6.1 cygwin download Message-ID: <20060802202052.D274C101F04@lists.intevation.de> > Installed Grass 6.1 using cygwin. Once installed, it opened up. > I started to 'Create location from EPSG' only to find that folder proj does > not exist. Searched in surrounding folders with no luck. > > tried installing proj package from cygwin again (twice) with no change in > results Where is you share/proj/epsg file located on the disk? And what path is there in the "Path to EPSG-codes file" field? If these paths are different, press the "Browse..." button, navigate to where the 'epsg' file shipped with your proj instalation is located, then try again. Does that work? Maciek -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Wed Aug 2 22:53:17 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Aug 2 22:53:22 2006 Subject: [GRASS-dev] portable.h doubled Message-ID: <44D110BD.2070802@o2.pl> Hi, There are 2 instances of portable.h in my Grass 6.1 CVS (today) instalation: $ ls /usr/local/grass-6.1.cvs/include/ grass portable.h $ ls /usr/local/grass-6.1.cvs/include/grass/ | grep portable.h portable.h Is this OK? Maciek From neteler at itc.it Wed Aug 2 23:33:40 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 2 23:33:42 2006 Subject: [GRASS-dev] [bug #4725] (grass) nviz crashed while volume visualisation In-Reply-To: <20060802195406.E092E101EE6@lists.intevation.de> References: <20060802195406.E092E101EE6@lists.intevation.de> Message-ID: <20060802213340.GI15803@bartok.itc.it> On Wed, Aug 02, 2006 at 09:54:06PM +0200, Markus Neteler via RT wrote: > Hi, > > [ http://intevation.de/rt/webrt?serial_num=4725 ] > > I just tested the volume with the Slovakia3D dataset: > it works again. Whatever happened, but NVIZ volume > visualization seems to be back. > > GRASS 6.1.cvs (slovakia3d):~ > nviz dem500 volume=precip3d.500z50 > Loading Data > Update elev null mask > Loading Data > translating colors from fp > recalculating normals... > % [Raster MASK present] > GRASS 6.1.cvs (slovakia3d):~ > > > Someone please test this with 6.1.0RC1. Enter Panel -> volume > -> add -> constant -> 1000 to visualize an isosurface. Or > read the README of the dataset. > Ok, it crashed in a second run. I debugged a problem in togl_flythrough.c, line 800: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1239013664 (LWP 24023)] 0xb734e327 in __strtouq_internal () from /lib/tls/libc.so.6 (gdb) bt full #0 0xb734e327 in __strtouq_internal () from /lib/tls/libc.so.6 No symbol table info available. #1 0xb734e0cf in __strtol_internal () from /lib/tls/libc.so.6 No symbol table info available. #2 0xb7a2f2d0 in atoi (__nptr=0x0) at /usr/include/stdlib.h:333 No locals. #3 0x08068d93 in Ndraw_all_together_cmd (data=0x8073f40, interp=0x8079b18, argc=1, argv=0xbf8a89ec) at togl_flythrough.c:800 buf_surf = 0x0 buf_vect = 0x0 buf_site = 0x0 buf_vol = 0x0 buf_north_arrow = 0x0 arrow_x = 0x0 buf_label = 0x0 buf_legend = 0x0 buf_fringe = 0x0 buf_is_drawing = 0x0 #4 0xb76e3c86 in TclInvokeStringCommand () from /usr/lib/libtcl8.4.so No symbol table info available. #5 0x08073f40 in script_mode () No symbol table info available. #6 0x08079b18 in ?? () No symbol table info available. Since all the buf_xxx stuff is 0x0, atoi() crashes. Not sure if this is related to the recent togl changes. Markus From glynn at gclements.plus.com Thu Aug 3 00:28:25 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 3 00:29:42 2006 Subject: [GRASS-dev] v.digit startup error from -n position In-Reply-To: References: <44D0DE2E.6000407@o2.pl> Message-ID: <17617.9993.431263.22596@cerise.gclements.plus.com> Michael Barton wrote: > OK. Looking through to the very bottom of the thread, there appears to be > some confusion about what is meant by GUI. > > If v.digit is having a problem with a new vector when run from the toolbar > button in gism, it is one thing. This SHOULD be OK. I've checked the code > and it is written... > > v.digit -n map=new_map > > ... as Glynn indicated. If this is where the problem lies, then, there is > some other kind of issue. Contrary to the "resolved" status in the RT, the real bug remains. v.digit is calling Tk_Main() as: Tk_Main(argc, argv, Tcl_AppInit); where argc/argv are those passed to main. It shouldn't be doing this; it should be passing a dummy argv, e.g. char *fake_argv[2]; ... fake_argv[0] = argv[0]; fake_argv[1] = NULL; Tk_Main(1, fake_argv, Tcl_AppInit); Changing the order of v.digit's arguments is a workaround, not a fix. > Glynn also noted, however, that in the auto-generated GUI dialogs, this is > being written as... > > v.digit map=new_map -n > > This causes a problem because the -n is misinterpreted by TclTk as a flag in > the TclTk command. So if the problem arises when v.digit is run from a menu > or the dialog is started from the CLI by simply typing v.digit, then THIS is > where the problem lies. > > Generically, the GRASS flags should come before any other arguments it > seems. I don't know where this is coded, but Cedric should know. The generate_tcl() function in lib/gis/parser.c writes out a list of flags/options, with the flags last. gui.tcl passes the command-line options to the module in their original order, i.e. with the flags last. This isn't a problem, as G_parser() doesn't care about the order. The fact that putting the flags first happens to work around the bug in v.digit is a coincidence, but not a particularly relevant one: v.digit should still be fixed. -- Glynn Clements From glynn at gclements.plus.com Thu Aug 3 00:32:13 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 3 00:32:20 2006 Subject: [GRASS-dev] portable.h doubled In-Reply-To: <44D110BD.2070802@o2.pl> References: <44D110BD.2070802@o2.pl> Message-ID: <17617.10221.700572.739847@cerise.gclements.plus.com> Maciej Sieczka wrote: > There are 2 instances of portable.h in my Grass 6.1 CVS (today) instalation: > > $ ls /usr/local/grass-6.1.cvs/include/ > grass portable.h > > $ ls /usr/local/grass-6.1.cvs/include/grass/ | grep portable.h > portable.h > > Is this OK? Probably. I'm not sure whether it needs to be installed at all; none of the other headers reference it. It may have been done for the benefit of QGIS. -- Glynn Clements From glynn at gclements.plus.com Thu Aug 3 00:48:12 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 3 00:48:16 2006 Subject: [GRASS-dev] [bug #4725] (grass) nviz crashed while volume visualisation In-Reply-To: <20060802213340.GI15803@bartok.itc.it> References: <20060802195406.E092E101EE6@lists.intevation.de> <20060802213340.GI15803@bartok.itc.it> Message-ID: <17617.11180.340937.124047@cerise.gclements.plus.com> Markus Neteler wrote: > > [ http://intevation.de/rt/webrt?serial_num=4725 ] > > > > I just tested the volume with the Slovakia3D dataset: > > it works again. Whatever happened, but NVIZ volume > > visualization seems to be back. > > > > GRASS 6.1.cvs (slovakia3d):~ > nviz dem500 volume=precip3d.500z50 > > Loading Data > > Update elev null mask > > Loading Data > > translating colors from fp > > recalculating normals... > > % [Raster MASK present] > > GRASS 6.1.cvs (slovakia3d):~ > > > > > Someone please test this with 6.1.0RC1. Enter Panel -> volume > > -> add -> constant -> 1000 to visualize an isosurface. Or > > read the README of the dataset. > > Ok, it crashed in a second run. > > I debugged a problem in togl_flythrough.c, line 800: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1239013664 (LWP 24023)] > 0xb734e327 in __strtouq_internal () from /lib/tls/libc.so.6 > (gdb) bt full > #0 0xb734e327 in __strtouq_internal () from /lib/tls/libc.so.6 > No symbol table info available. > #1 0xb734e0cf in __strtol_internal () from /lib/tls/libc.so.6 > No symbol table info available. > #2 0xb7a2f2d0 in atoi (__nptr=0x0) at /usr/include/stdlib.h:333 > No locals. > #3 0x08068d93 in Ndraw_all_together_cmd (data=0x8073f40, interp=0x8079b18, argc=1, argv=0xbf8a89ec) > at togl_flythrough.c:800 > buf_surf = 0x0 > buf_vect = 0x0 > buf_site = 0x0 > buf_vol = 0x0 > buf_north_arrow = 0x0 > arrow_x = 0x0 > buf_label = 0x0 > buf_legend = 0x0 > buf_fringe = 0x0 > buf_is_drawing = 0x0 > #4 0xb76e3c86 in TclInvokeStringCommand () from /usr/lib/libtcl8.4.so > No symbol table info available. > #5 0x08073f40 in script_mode () > No symbol table info available. > #6 0x08079b18 in ?? () > No symbol table info available. > > > Since all the buf_xxx stuff is 0x0, atoi() crashes. > Not sure if this is related to the recent togl changes. It might be related to the new version of Togl. Or a different version of Tcl/Tk, or some other change to NVIZ. The problem is that the Togl canvas is being redrawn before the variables have been created. As the canvas can be redrawn at any point after it has been created (or even during creation), it is necessary to initialise all of the above variables before creating the canvas. Whilst creating them later and simply hoping that the canvas won't get redrawn first might work, it's an extremely fragile "solution". -- Glynn Clements From michael.barton at asu.edu Thu Aug 3 00:58:22 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 3 00:57:27 2006 Subject: [GRASS-dev] v.digit startup error from -n position In-Reply-To: <17617.9993.431263.22596@cerise.gclements.plus.com> Message-ID: OK. I get it (I think). This is a problem in the v.digit code itself, not with the TclTk wrappers that parse it for the GUI. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Wed, 2 Aug 2006 23:28:25 +0100 > To: Michael Barton > Cc: Maciej Sieczka , Markus Neteler , GRASS > developers list > Subject: Re: [GRASS-dev] v.digit startup error from -n position > > > Michael Barton wrote: > >> OK. Looking through to the very bottom of the thread, there appears to be >> some confusion about what is meant by GUI. >> >> If v.digit is having a problem with a new vector when run from the toolbar >> button in gism, it is one thing. This SHOULD be OK. I've checked the code >> and it is written... >> >> v.digit -n map=new_map >> >> ... as Glynn indicated. If this is where the problem lies, then, there is >> some other kind of issue. > > Contrary to the "resolved" status in the RT, the real bug remains. > > v.digit is calling Tk_Main() as: > > Tk_Main(argc, argv, Tcl_AppInit); > > where argc/argv are those passed to main. > > It shouldn't be doing this; it should be passing a dummy argv, e.g. > > char *fake_argv[2]; > ... > fake_argv[0] = argv[0]; > fake_argv[1] = NULL; > Tk_Main(1, fake_argv, Tcl_AppInit); > > Changing the order of v.digit's arguments is a workaround, not a fix. > >> Glynn also noted, however, that in the auto-generated GUI dialogs, this is >> being written as... >> >> v.digit map=new_map -n >> >> This causes a problem because the -n is misinterpreted by TclTk as a flag in >> the TclTk command. So if the problem arises when v.digit is run from a menu >> or the dialog is started from the CLI by simply typing v.digit, then THIS is >> where the problem lies. >> >> Generically, the GRASS flags should come before any other arguments it >> seems. I don't know where this is coded, but Cedric should know. > > The generate_tcl() function in lib/gis/parser.c writes out a list of > flags/options, with the flags last. gui.tcl passes the command-line > options to the module in their original order, i.e. with the flags > last. > > This isn't a problem, as G_parser() doesn't care about the order. The > fact that putting the flags first happens to work around the bug in > v.digit is a coincidence, but not a particularly relevant one: v.digit > should still be fixed. > > -- > Glynn Clements From grass-bugs at intevation.de Thu Aug 3 09:07:54 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 09:07:57 2006 Subject: [GRASS-dev] [bug #4954] (grass) make fails on processing grasstcl*.po files Message-ID: <20060803070754.EF3FD101EFB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4954 ------------------------------------------------------------------------- Subject: make fails on processing grasstcl*.po files Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1.0RC1 make tries to write in nonexisting directory. There is no msgs directory in dist.i686-pc-linux-gnu/etc/ grasstcl_de.po: msgfmt: error while opening "/home/maris/soft/grass-6.1.0RC1/dist.i686-pc-linux-gnu/etc/msgs/de.msg" for writing: No such file or directory -------------------------------------------- Managed by Request Tracker From peter.loewe at gmx.de Thu Aug 3 09:44:53 2006 From: peter.loewe at gmx.de (peter.loewe@gmx.de) Date: Thu Aug 3 09:44:55 2006 Subject: [GRASS-dev] Grass Variables/ Perl Message-ID: <20060803074453.313630@gmx.net> When running a Perl-script from the grass-shell, grass commands can be started via backticks or using "system()". However, this is not suitable to set variables such as GRASS_HEIGHT/WIDTH etc (Scoping). Has anybody tackled this issue before ? -- Dr. Peter L?we Diplom-Geograph "Feel free" ? 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From jachym.cepicky at centrum.cz Thu Aug 3 09:53:57 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Aug 3 09:54:05 2006 Subject: [GRASS-dev] Grass Variables/ Perl In-Reply-To: <20060803074453.313630@gmx.net> References: <20060803074453.313630@gmx.net> Message-ID: <20060803075356.GB8936@localdomain> Hi Peter, %ENV gives you the environment variables, if ($ENV{GISBASE}){ &main(); } else { print "You have to run GRASS first!" } you can also read from stdin: @region = `g.region -g` jachym On Thu, Aug 03, 2006 at 09:44:53AM +0200, peter.loewe@gmx.de wrote: > When running a Perl-script from the grass-shell, grass commands can be started via backticks or using "system()". However, this is not suitable to set variables such as GRASS_HEIGHT/WIDTH etc (Scoping). > > Has anybody tackled this issue before ? > > > -- > Dr. Peter L?we > > Diplom-Geograph > > > > > > > > > "Feel free" ? 10 GB Mailbox, 100 FreeSMS/Monat ... > Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060803/41994465/attachment.bin From peter.loewe at gmx.de Thu Aug 3 10:01:11 2006 From: peter.loewe at gmx.de (=?iso-8859-1?Q?=22Peter_L=F6we=22?=) Date: Thu Aug 3 10:01:13 2006 Subject: [GRASS-dev] Grass Variables/ Perl In-Reply-To: <20060803075356.GB8936@localdomain> References: <20060803074453.313630@gmx.net> <20060803075356.GB8936@localdomain> Message-ID: <20060803080111.146930@gmx.net> >%ENV gives you the environment variables, >if ($ENV{GISBASE}){ > &main(); >} >else { > print "You have to run GRASS first!" >} > >you can also read from stdin: > >@region = `g.region -g` Hello Jachym, that's true. However, neither `export GRASS_WIDTH=42` nor system "export GRASS_WIDTH=42" can be used to set the variables for later commands to make use of the settings (aka generate a huge PNG). Within the GRASS environment, the GRASS_HEIGHT/WIDTH will still default to 640/480. A remarkably awkward workaround would be to create a shell-script from within the perl environment and run it later. but i believe theremust be a better way. Peter -- Dr. Peter L?we Diplom-Geograph Echte DSL-Flatrate dauerhaft f?r 0,- Euro*. Nur noch kurze Zeit! "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl From grass-bugs at intevation.de Thu Aug 3 10:11:30 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 10:11:31 2006 Subject: [GRASS-dev] [bug #4955] (grass) C++ style comments in 6.1.0RC1 Message-ID: <20060803081130.14441101F04@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4955 ------------------------------------------------------------------------- Subject: C++ style comments in 6.1.0RC1 Platform: GNU/Linux/x86 grass binary for platform: Compiled from Sources GRASS Version: 6.1.0RC1 There are some C++ style comments '//' in RC1 that prevents compiling as described in debugging.txt (CFLAGS='-g -ansi -Wall -D_BSD_SOURCE=1 -D_SVID_SOURCE=1 -D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=199506L') visualization/nviz/src/pick_vect_commands.c:210 lib/gis/location.c:88 lib/gis/location.c:92 /vector/v.lrs/lib/lrs.c:281 /vector/v.lrs/lib/lrs.c:287 /vector/v.lrs/v.lrs.label/main.c:275 /vector/v.lrs/v.lrs.label/main.c:350 /vector/v.lrs/v.lrs.label/main.c:369 /vector/v.lrs/v.lrs.label/main.c:445 /vector/v.lrs/v.lrs.label/main.c:449 -------------------------------------------- Managed by Request Tracker From maris.gis at gmail.com Thu Aug 3 10:19:16 2006 From: maris.gis at gmail.com (=?utf-8?q?M=C4=81ris_Narti=C5=A1s?=) Date: Thu Aug 3 10:19:29 2006 Subject: [GRASS-dev] Inline functions in GRASS Message-ID: <200608031119.17157.maris.gis@gmail.com> According to debugging.txt, GRASS should compile with CFLAGS='-g -ansi -Wall -D_BSD_SOURCE=1 -D_SVID_SOURCE=1 -D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=199506L' But r.carve would fail to compile because it uses inline functions introduced in C99 (ISO/IEC 9899:1999). So - who's wrong - debugging.txt or r.carve? Maris. grass-6.1.0RC1/raster/r.carve$ make gcc -I/home/maris/soft/grass-6.1.0RC1/dist.i686-pc-linux-gnu/include -g -ansi -Wall -D_BSD_SOURCE=1 -D_SVID_SOURCE=1 -D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=199506L -I/usr/include -DPACKAGE=\""grassmods"\" -I/home/maris/soft/grass-6.1.0RC1/dist.i686-pc-linux-gnu/include \ -o OBJ.i686-pc-linux-gnu/enforce_ds.o -c enforce_ds.c enforce_ds.c:17: error: syntax error before ?void? enforce_ds.c:20: error: syntax error before ?void? enforce_ds.c:21: error: syntax error before ?void? enforce_ds.c:23: error: syntax error before ?void? enforce_ds.c:25: error: syntax error before ?double? enforce_ds.c: In function ?process_line?: enforce_ds.c:82: warning: unused variable ?j? enforce_ds.c: At top level: enforce_ds.c:194: error: syntax error before ?void? enforce_ds.c:204: error: syntax error before ?void? enforce_ds.c:230: error: syntax error before ?void? enforce_ds.c:258: error: syntax error before ?void? enforce_ds.c:288: error: syntax error before ?double? make: *** [OBJ.i686-pc-linux-gnu/enforce_ds.o] Error 1 From jachym.cepicky at centrum.cz Thu Aug 3 10:21:23 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Aug 3 10:21:29 2006 Subject: [GRASS-dev] Grass Variables/ Perl In-Reply-To: <20060803080111.146930@gmx.net> References: <20060803074453.313630@gmx.net> <20060803075356.GB8936@localdomain> <20060803080111.146930@gmx.net> Message-ID: <20060803082122.GE8936@localdomain> #!/usr/bin/perl -w $ENV{GRASS_WIDTH} = 20; $ENV{GRASS_HEIGHT} = 20; system("d.mon start=PNG"); system("d.rast soils"); system("d.mon stop=PNG"); jachym On Thu, Aug 03, 2006 at 10:01:11AM +0200, "Peter L?we" wrote: > >%ENV gives you the environment variables, > > >if ($ENV{GISBASE}){ > > &main(); > >} > >else { > > print "You have to run GRASS first!" > >} > > > >you can also read from stdin: > > > >@region = `g.region -g` > > Hello Jachym, > > that's true. However, neither `export GRASS_WIDTH=42` nor system "export GRASS_WIDTH=42" can be used to set the variables for later commands to make use of the settings (aka generate a huge PNG). Within the GRASS environment, the GRASS_HEIGHT/WIDTH will still default to 640/480. > A remarkably awkward workaround would be to create a shell-script from within the perl environment and run it later. but i believe theremust be a better way. > > Peter > -- > Dr. Peter L?we > > Diplom-Geograph > > > > > > > > > Echte DSL-Flatrate dauerhaft f?r 0,- Euro*. Nur noch kurze Zeit! > "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060803/0c4aeb9e/attachment.bin From grass-bugs at intevation.de Thu Aug 3 10:24:30 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 10:24:32 2006 Subject: [GRASS-dev] [bug #4956] (grass) gis.m: transparency setting not saved in .grc file Message-ID: <20060803082430.9754B101EE6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4956 ------------------------------------------------------------------------- Subject: gis.m: transparency setting not saved in .grc file Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: cvs_head_20060803 Transparency settings are not saved in the .grc file of the GIS Manager. Moritz -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Aug 3 10:24:41 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Thu Aug 3 10:24:44 2006 Subject: [GRASS-dev] [bug #4955] (grass) C++ style comments in 6.1.0RC1 Message-ID: <20060803082441.F3DCD101EE6@lists.intevation.de> Fixed in CVS (both HEAD and branch). Thanks for testing, Markus -------------------------------------------- Managed by Request Tracker From rez at touchofmadness.com Thu Aug 3 10:49:45 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Aug 3 10:50:23 2006 Subject: [GRASS-dev] Inline functions in GRASS In-Reply-To: <200608031119.17157.maris.gis@gmail.com> References: <200608031119.17157.maris.gis@gmail.com> Message-ID: <1154594985.2698.89.camel@devel> On Thu, 2006-08-03 at 11:19 +0300, M?ris Narti?s wrote: > According to debugging.txt, GRASS should compile with > CFLAGS='-g -ansi -Wall -D_BSD_SOURCE=1 -D_SVID_SOURCE=1 -D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=199506L' > But r.carve would fail to compile because it uses inline functions introduced > in C99 (ISO/IEC 9899:1999). > > So - who's wrong - debugging.txt or r.carve? I'm wrong. I made them inline because they are only called once. I was using functions to compartmentalize code for readability, etc. Changes committed. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From mlennert at club.worldonline.be Thu Aug 3 10:51:33 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Aug 3 10:51:35 2006 Subject: [GRASS-dev] GRASS 6.1.0RC1 released In-Reply-To: <20060802160829.GO10564@bartok.itc.it> References: <20060802160829.GO10564@bartok.itc.it> Message-ID: <44D1B915.4000803@club.worldonline.be> Markus Neteler wrote: > Dear all, > > I have packaged the source code of GRASS 6.1.0RC1: > http://grass.itc.it/grass61/source/ > > More than 40 fixes have been backported from beta1 > to RC1. See the ChangeLog_6.1.0RC1.gz for details. > > Please test the new tarball. If things go well, we > can publish it as 6.1.0 shortly. Compiling and superficial testing on Debian did not show any problems. Moritz From dassau at gdf-hannover.de Thu Aug 3 10:58:15 2006 From: dassau at gdf-hannover.de (Otto Dassau) Date: Thu Aug 3 10:56:30 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <44D0DDCC.8020302@o2.pl> References: <20060715155932.GD9134@bartok.itc.it> <17616.53980.563594.551273@cerise.gclements.plus.com> <44D0DDCC.8020302@o2.pl> Message-ID: <200608031058.15607.dassau@gdf-hannover.de> Am Mittwoch, 2. August 2006 19:15 schrieb Maciej Sieczka: > Glynn Clements napisa?(a): > > Moritz Lennert wrote: > >>> But generally: why wait for a bugfix party? Just go ahead... > >> > >> I don't think it is about waiting, it is about creating a special, > >> motivating event where everyone works together on one goal. > > > > The one thing which would do the most to motivate me to fix bugs would > > be a list of clearly-identified, verified, reproducible bugs. > > I can do that and will send it to the list. Most likely next week. If > there is no obvious test case I will try to create it based on spearfish. > > To all you Guys who were willing to help with testing during the bug > sqaushing party: please give me a hand with that. Each of you, pick few > reports, verify it using spearfish, or, for bugs in the interface etc., > just verify if it is still present in current CVS. Then 'reply' from the > tracker CCing me at my email. You can do it all even as guest, just make > sure you sign with name and email. If I counted OK there should be 5 > testers alltogether. Such a band can clean the mess up easily. Anybody - > please join! Hi, would it make sense to create a list of bug IDs to verify - maybe in wiki? People can add themselves together with their favorite IDs to make sure that bugs won't be verified twice. regards, Otto > > Back when I used to check the RT occasionally, I would generally skip > > any report where I couldn't quickly reproduce the problem from the > > information contained in the report. > > I agree this is often the case that people don't document their reports > well enough, but this doesn't mean such reports should be ignored > completely. > > > As this tends to be the case for the vast majority of reports, I > > eventually gave up checking the RT altogether > > (other than to kill requests generated by spam email to the grass-bugs > > address). > > Please don't waste your time. This is such an easy task I can do it > myself (and I'm doing it). > > > If people want a bug to get fixed, by far the most important factor is > > providing a clear mechanism to demonstrate the bug, either using the > > spearfish dataset or starting from a new location (i.e. using > > self-generated test data). > > I know, I've failed to do it often too. But I also reported bugs, and > saw other's reports, documented well but still never taken care of. > > You are right there is a need to clean up the tracker further to make > developers' work easier. I'll work on this as I can. > > Maciek From mlennert at club.worldonline.be Thu Aug 3 11:30:41 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Aug 3 11:30:42 2006 Subject: [GRASS-dev] d.vect.thematic fails if db.connect and v.db.connect are different Message-ID: <44D1C241.3000201@club.worldonline.be> Hi, I don't know if this is a bug or a feature, but when I have a location for which I have set a database connection with db.connect, and then set a different database connection for one vector map with v.db.connect, d.vect.thematic looks for the vector map attributes in the database defined by db.connect: GRASS 6.1.0RC1 (spearfish60):~ > db.connect -p driver:pg database:belgique schema:(null) group:(null) GRASS 6.1.0RC1 (spearfish60):~ > v.db.connect -p fields Vector map is connected by: layer <1> table in database through driver with key DBMI-Postgres driver error: Cannot connect to Postgres: FATAL: la base de donn?es ?/home/mlennert/GRASS/DATA/spearfish60/PERMANENT/dbf/? n'existe pas (meaning the database does not exist) Moritz From landa.martin at gmail.com Thu Aug 3 11:36:52 2006 From: landa.martin at gmail.com (Martin Landa) Date: Thu Aug 3 11:36:59 2006 Subject: [GRASS-dev] v.extrude testing Message-ID: Hi, working with simple 2d vector map layer I have slightly tested great v.extrude module. My notes: 1) problem with "type" parameter GRASS 6.1.cvs (karlin):~ > v.extrude help 2>&1 | grep -n1 "options: line" 22- type Type 23: options: line,boundary,area,face 24- default: line,boundary,area,face GRASS 6.1.cvs (karlin):~ > v.info hraz2d_c2|grep lines | Number of lines: 22 Number of islands: 0 | a) GRASS 6.1.cvs (karlin):~ > v.extrude in=hraz2d_c2 out=hraz3d height=10 .... Number of nodes : 0 Number of primitives: 0 Number of points : 0 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 b) GRASS 6.1.cvs (karlin):~ > v.extrude in=hraz2d_c2 out=hraz3d height=10 type=line ... Number of nodes : 77 Number of primitives: 80 Number of points : 0 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of faces : 80 Number of areas : 0 Number of isles : 0 2) height X hcolumn GRASS 6.1.cvs (karlin):~ > echo "select * from hraz2d_c2" | db.select cat|vyska 2|10 a) GRASS 6.1.cvs (karlin):~ > v.extrude in=hraz2d_c2 out=hraz3d height=10 1>/dev/null 2>/dev/null;v.info hraz3d|grep T: | B: 0.000 T: 10.000 b) v.extrude in=hraz2d_c2 out=hraz3d hco=vyska 1>/dev/null 2>/dev/null;v.info hraz3d|grep T: | B: 0.000 T: 0.000 | It seems that parameter "hcolumn" does not work (pg driver)... I have also tested data type for "hcolumn" (e.g. date), the result is GRASS 6.1.cvs (karlin):~ > v.extrude in=hraz2d_c2 out=hraz3d hco=vyska_d 1>/dev/null 2>/dev/null;v.info hraz3d|grep T: | B: 0.000 T: 0.000 I did not get any error message... 3) zshift && elev GRASS 6.1.cvs (karlin):~ > v.extrude in=hraz2d_c2 out=hraz3d he=10 el=vdem5 1>/dev/null 2>/dev/null;v.info hraz3d|grep T: | B: 184.480 T: 201.461 GRASS 6.1.cvs (karlin):~ > v.extrude in=hraz2d_c2 out=hraz3d he=10 el=vdem5 zs=5 1>/dev/null 2>/dev/null;v.info hraz3d|grep T: | B: 184.480 T: 201.461 Parameter "zshift" does not work in combination with "elevation". I have *tried* to fix the described problems. I hope it helps... Best regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: v_extrude_fix.diff.gz Type: application/x-gzip Size: 1222 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060803/837e51c2/v_extrude_fix.diff.gz From neteler at itc.it Thu Aug 3 11:54:16 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Aug 3 11:54:18 2006 Subject: [GRASS-dev] d.vect.thematic fails if db.connect and v.db.connect are different In-Reply-To: <44D1C241.3000201@club.worldonline.be> References: <44D1C241.3000201@club.worldonline.be> Message-ID: <20060803095416.GF4687@bartok.itc.it> On Thu, Aug 03, 2006 at 11:30:41AM +0200, Moritz Lennert wrote: > Hi, > > I don't know if this is a bug or a feature, but when I have a location > for which I have set a database connection with db.connect, and then set > a different database connection for one vector map with v.db.connect, > d.vect.thematic looks for the vector map attributes in the database > defined by db.connect: > > GRASS 6.1.0RC1 (spearfish60):~ > db.connect -p > driver:pg > database:belgique > schema:(null) > group:(null) > > GRASS 6.1.0RC1 (spearfish60):~ > v.db.connect -p fields > Vector map is connected by: > layer <1> table in database > through driver > with key > > > DBMI-Postgres driver error: > Cannot connect to Postgres: FATAL: la base de donn?es > ?/home/mlennert/GRASS/DATA/spearfish60/PERMANENT/dbf/? n'existe pas > (meaning the database does not exist) Moritz, the best way to figure out what's happening is to edit d.vect.thematic in the GISBASE/scripts/ and to add -x there in the #!/bin/sh line: #!/bin/sh -x Then it will print all executed commands and variable values step by step. Markus From grass-bugs at intevation.de Thu Aug 3 12:53:40 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 12:53:41 2006 Subject: [GRASS-dev] [bug #4957] (grass) GUI not notified about exit in CLI Message-ID: <20060803105340.45A7C1005C9@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4957 ------------------------------------------------------------------------- Subject: GUI not notified about exit in CLI Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1.0RC1 If I run GRASS with GUI (gis.m) and type "exit" in terminal (konsole), GRASS session ends, but GUI keeps running and is unusable (no more ENV variables). Steps to reproduce: 1) start GRASS with "grass61 -gui" 2) in same console type in "exit" 3) try any command in GUI. Exit from CLI should close also any GRASS gui related stuff. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Aug 3 13:07:14 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 13:07:16 2006 Subject: [GRASS-dev] [bug #4958] (grass) wrong menu entry for r.grow Message-ID: <20060803110714.0E9791005CD@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4958 ------------------------------------------------------------------------- Subject: wrong menu entry for r.grow Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1.0RC1 GRASS 6.1.0RC1 ships with r.grow but gis.m expects r.grow2 resulting in error. couldn't execute "r.grow2": no such file or directory -------------------------------------------- Managed by Request Tracker From frankie at debian.org Thu Aug 3 13:13:22 2006 From: frankie at debian.org (Francesco P. Lovergine) Date: Thu Aug 3 13:13:39 2006 Subject: [GRASS-dev] A few ideas about development tools... In-Reply-To: <20060803105340.45A7C1005C9@lists.intevation.de> References: <20060803105340.45A7C1005C9@lists.intevation.de> Message-ID: <20060803111322.GD5000@mithrandir> Markus asked me to report the list about some ideas I have... Well, a CVS repo could be easily converted to a SVN one by cvs2svn, subversion is currently the mainstream for a cetralized SCM. Honestly, CVS has a series of defects for management, maybe it's time to use a more advanced tool, without loosing past history. It is also well integrated with Trac which is a very nice bug tracker in respect with WebRT. That could be a major pain for migration, anyway. Ideas? PS: did the Google Summer of Code be considered for sponsored students efforts about grass activities? I think grass is eligible as mentor for that... The new year is not so far, indeed :) -- Francesco P. Lovergine From grass-bugs at intevation.de Thu Aug 3 13:28:56 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 13:28:58 2006 Subject: [GRASS-dev] [bug #4959] (grass) wrong menu entries for r.flow, r.lake and r.terraflow Message-ID: <20060803112856.0A8B31005DB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4959 ------------------------------------------------------------------------- Subject: wrong menu entries for r.flow, r.lake and r.terraflow Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1.0RC1 modules r.lake, r.flow and r.terraflow cannot be started from gis.m (they are just executed like from CLI) In r.lake and r.flow case it's just enough to change 'spawn' to 'execute' in gui/tcltk/menus/menu.tcl r.terraflow needs some other fix. -------------------------------------------- Managed by Request Tracker From frankie at debian.org Thu Aug 3 13:43:55 2006 From: frankie at debian.org (Francesco Paolo Lovergine) Date: Thu Aug 3 13:44:11 2006 Subject: [GRASS-dev] A few ideas about development tools... In-Reply-To: <20060803111322.GD5000@mithrandir> References: <20060803105340.45A7C1005C9@lists.intevation.de> <20060803111322.GD5000@mithrandir> Message-ID: <20060803114355.GE5000@mithrandir> On Thu, Aug 03, 2006 at 01:13:22PM +0200, Francesco P. Lovergine wrote: > Markus asked me to report the list about some ideas I have... > Ops, sorry inadvertently hijacked the thread :-( -- Francesco P. Lovergine From tutey at o2.pl Thu Aug 3 13:52:10 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Aug 3 13:52:14 2006 Subject: [GRASS-dev] Re: GRASS bugs In-Reply-To: <200608031058.15607.dassau@gdf-hannover.de> References: <20060715155932.GD9134@bartok.itc.it> <17616.53980.563594.551273@cerise.gclements.plus.com> <44D0DDCC.8020302@o2.pl> <200608031058.15607.dassau@gdf-hannover.de> Message-ID: <44D1E36A.9090205@o2.pl> Otto Dassau napisa?(a): > would it make sense to create a list of bug IDs to verify - maybe in wiki? > People can add themselves together with their favorite IDs to make sure that > bugs won't be verified twice. Let's not complicate things. Just go into BT, pick any grass6 report you like, go to the bottom. You will see the latest comment there. If, by date and the information contained, you conclude the bug requires verification, do it. After that leave the message by repling *CCing me*. Easy. Then I can decide whether to close, need more info, or put it on the list of actuall bugs. (This will be quicker than co-maintinig a list of bugs to check, updating it manually and updating the list of confirmed bugs accordingly. I think I can handle the logistics myself, being on vacation now :). Only more testers are needed. I've been testing myself too). Good hunting! After our work is done I will submit our list of confirmed, reproducable bugs to the wiki and the dev list. I've started preparing it. Eric is helping *a lot*, he has already verified and informed me about at least 10 bugs since yesterday. Maciek From grass-bugs at intevation.de Thu Aug 3 13:52:39 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 13:52:41 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules Message-ID: <20060803115239.EE603101EE6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4960 ------------------------------------------------------------------------- Subject: gis.m has menu entries for nonexisting modules Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.1.0RC1 gis.m menus contain menu entries for modules which are missing for some reason. i.e. if I compile grass without C++, I don't have r.terraflow, but I sill will have menu entry for it. Couldn't there be something like script which runs after all module compilation (before make install?) and masks unavailable module entries? Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting guru, I can't write such script. -------------------------------------------- Managed by Request Tracker From epatton at nrcan.gc.ca Thu Aug 3 15:02:41 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Aug 3 15:02:53 2006 Subject: [GRASS-dev] Re: GRASS bugs Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55B13@s5-dar-r1.nrn.nrcan.gc.ca> Otto, I've just been starting at the oldest bugs and working my way forward. I've noticed a lot of the older bugs I've encountered aren't relevant anymore as the source code has improved and changed so much over the last 3-4 years. Regards, ~ Eric. -----Original Message----- From: grass-dev-bounces@grass.itc.it To: grass-dev@grass.itc.it Sent: 8/3/2006 4:58 AM Subject: Re: [GRASS-dev] Re: GRASS bugs Am Mittwoch, 2. August 2006 19:15 schrieb Maciej Sieczka: > Glynn Clements napisa?(a): > > Moritz Lennert wrote: > >>> But generally: why wait for a bugfix party? Just go ahead... > >> > >> I don't think it is about waiting, it is about creating a special, > >> motivating event where everyone works together on one goal. > > > > The one thing which would do the most to motivate me to fix bugs would > > be a list of clearly-identified, verified, reproducible bugs. > > I can do that and will send it to the list. Most likely next week. If > there is no obvious test case I will try to create it based on spearfish. > > To all you Guys who were willing to help with testing during the bug > sqaushing party: please give me a hand with that. Each of you, pick few > reports, verify it using spearfish, or, for bugs in the interface etc., > just verify if it is still present in current CVS. Then 'reply' from the > tracker CCing me at my email. You can do it all even as guest, just make > sure you sign with name and email. If I counted OK there should be 5 > testers alltogether. Such a band can clean the mess up easily. Anybody - > please join! Hi, would it make sense to create a list of bug IDs to verify - maybe in wiki? People can add themselves together with their favorite IDs to make sure that bugs won't be verified twice. regards, Otto > > Back when I used to check the RT occasionally, I would generally skip > > any report where I couldn't quickly reproduce the problem from the > > information contained in the report. > > I agree this is often the case that people don't document their reports > well enough, but this doesn't mean such reports should be ignored > completely. > > > As this tends to be the case for the vast majority of reports, I > > eventually gave up checking the RT altogether > > (other than to kill requests generated by spam email to the grass-bugs > > address). > > Please don't waste your time. This is such an easy task I can do it > myself (and I'm doing it). > > > If people want a bug to get fixed, by far the most important factor is > > providing a clear mechanism to demonstrate the bug, either using the > > spearfish dataset or starting from a new location (i.e. using > > self-generated test data). > > I know, I've failed to do it often too. But I also reported bugs, and > saw other's reports, documented well but still never taken care of. > > You are right there is a need to clean up the tracker further to make > developers' work easier. I'll work on this as I can. > > Maciek _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev From muzafferayvaz at yahoo.com Thu Aug 3 15:17:40 2006 From: muzafferayvaz at yahoo.com (Muzaffer Ayvaz) Date: Thu Aug 3 15:17:43 2006 Subject: [GRASS-dev] Floating Point exception error Message-ID: <20060803131740.13423.qmail@web53403.mail.yahoo.com> Hi List; I have compiled grass from source on intel x86_64 platform. My operating system is Redhat Linux AS 3.No error in configure no error in make. But while executing the commands; as an example; > g.list type=rast Floating point exception. I have written this problem before. Glyn aid that try new versions. I have compiled also 6.1.0RC1 version but the same error still occurs. Please ...Any suggestions, any informations. Thank you for all Muzaffer... --------------------------------- Groups are talking. We´re listening. Check out the handy changes to Yahoo! Groups. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060803/2a2cc166/attachment.html From kwythers at umn.edu Tue Aug 1 19:57:55 2006 From: kwythers at umn.edu (Kirk R. Wythers) Date: Thu Aug 3 16:24:13 2006 Subject: [GRASS-dev] r.in.gdal and .ecw files on OS X In-Reply-To: References: <35469E27904CA04687795AF87D26930001CDFF@september.ecotrust.org> <437CC904-E231-4FD7-A04E-1BFCE57AFE5D@UMN.EDU> <7622FE34-A899-438A-A94F-053047CE76AF@kyngchaos.com> <66A3CAAD-5A59-46BE-957F-883CF4532A8C@umn.edu> Message-ID: <6D6C6DA1-DF6D-4590-B016-2E396F8BC508@umn.edu> William, I just finished compiling gdal with the ecw stuff. Is this the error you get when trying read an .ecw file: GRASS 6.1.cvs (cecr_utm):~ > r.in.gdal -oe input=~/Desktop/ farmservcolororthophoto2003/q0625k/q3334/img_fsa01aim4.ecw output=fsa01aim4 dyld: lazy symbol binding failed: Symbol not found: _FSFindFolder Referenced from: /usr/local/lib/libNCSUtil.0.dylib Expected in: flat namespace dyld: Symbol not found: _FSFindFolder Referenced from: /usr/local/lib/libNCSUtil.0.dylib Expected in: flat namespace ERROR 1: File is invalid or corrupt GRASS 6.1.cvs (cecr_utm):~ > Just wanted to run this by you to if I was hung up in the same place. Although I do get the ecw coming up as a readable file option with the -f option now: ECW (rw): ERMapper Compressed Wavelets thanks, Kirk On Aug 1, 2006, at 10:35 AM, William Kyngesburye wrote: > I tried both. By default, it builds shared with the old collection > of libraries, and static with the new single libecwj2. And yes, I > noticed the missing makefile-osx also. But they're moving away > from the fixed makefiles from qmake to the standard configure-make- > install. You're supposed to be able to create your own with qmake, > but in the past I haven't had that installed. I have it now, part > of the Qt stuff, but I'm not sure I want to mess with that. > > There is one change you need to make or it won't build: in Source/C/ > NCSnet/NCScnet3/NCSSocket.cpp, line 190, comment out or delete the > MACOSX ifdef block so just the NON-MACOSX line is used: > > //# ifdef MACOSX > // int tempSize = sizeof(struct sockaddr); > //# else > socklen_t tempSize = sizeof(struct sockaddr); > //# endif > > I don't think this has anything to do with the crashes - Tom Lynch > from ERMapper (hangs out on the GDAL list) suggested this, or at > least pointed out a thread in their forum about it. > > > Interesting - I was just poking around their forums to see if there > was any new info. Tom mentioned a final release at the end of > June. Indeed, the binary (Windoze only) is final, but the source > is still RC2. Soon, he says. Things move slow over there... I > hope they have OSX working. > > On Aug 1, 2006, at 9:39 AM, Kirk R. Wythers wrote: > >> I'll give it a go today William. >> >> Curiosity, did you build the static or the shared? Also, I am >> puzzled by the presence of Makefile-linux and Makefile-solaris, >> but no Makefile-osx >> >> Any thoughts? >> > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > First Pogril: Why is life like sticking your head in a bucket > filled with hyena offal? > Second Pogril: I don't know. Why IS life like sticking your head > in a bucket filled with hyena offal? > First Pogril: I don't know either. Wretched, isn't it? > > -HitchHiker's Guide to the Galaxy > From grass-bugs at intevation.de Thu Aug 3 17:17:09 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 17:17:11 2006 Subject: [GRASS-dev] [bug #4964] (grass) baks Message-ID: <20060803151709.822521006C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4964 ------------------------------------------------------------------------- Subject: baks grass binary for platform: Downloaded precompiled Binaries Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Aug 3 17:17:36 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Aug 3 17:17:37 2006 Subject: [GRASS-dev] [bug #4965] (grass) Message-ID: <20060803151736.736291006C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4965 ------------------------------------------------------------------------- Subject: -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Aug 3 18:04:44 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Thu Aug 3 18:04:46 2006 Subject: [GRASS-dev] [bug #4915] (grass) gis.m: cannot use v.in.ogr if no monitor is open Message-ID: <20060803160444.872561006CC@lists.intevation.de> mlennert@club.worldonline.be wrote (Mon, Jul 31 2006 15:16:34): > Markus Neteler via RT wrote: > > For me it works. > Did you close the map display and launch v.in.ogr from the file menu ? > Can someone else try ? I confirm: 1. gis.m 2. close map window 3. run v.in.ogr (on anything, no special test case required): GRASS_INFO_ERROR(13160,1): region for current mapset is not set GRASS_INFO_ERROR(13160,1): run "g.region" The differece in my case is that I don't get the tcltk error as Moritz, only the error about missing region setting. What's more however, it seems you can't import ANY data: r.in.* and all the other v.in.* modules don't work either if Map window is closed and the import module is started from gis.m. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Aug 3 18:17:03 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Thu Aug 3 18:17:06 2006 Subject: [GRASS-dev] [bug #3506] (grass) NVIZ: drastic scene setup change after adjusting the 'zexag' Message-ID: <20060803161703.E5EBF1006CC@lists.intevation.de> mneteler wrote (Mon, Jul 31 2006 13:46:41): > Still present now? Bob has submitted a modification > but I am not sure if it's related. The only Bob's change after my last check on 2007.07.23 was Bob Covill: load a transparent surface if vector data or sites data is being loaded without a surface and it's not related. The bug still applies. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Aug 3 18:18:05 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Thu Aug 3 18:18:06 2006 Subject: [GRASS-dev] [bug #3506] (grass) NVIZ: drastic scene setup change after adjusting the 'zexag' Message-ID: <20060803161805.2A0941006CC@lists.intevation.de> And it's easy to reproduce, using any data. -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Thu Aug 3 20:12:15 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Aug 3 20:10:41 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <20060803115239.EE603101EE6@lists.intevation.de> Message-ID: This should be a wish, not a bug. Nice idea to have autogenerated menus. I've floated it a time or two and others have mentioned it too. Maybe someone knows how to do it. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Request Tracker > Reply-To: Request Tracker > Date: Thu, 3 Aug 2006 13:52:39 +0200 (CEST) > To: > Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for > nonexisting modules > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4960 > ------------------------------------------------------------------------- > > Subject: gis.m has menu entries for nonexisting modules > > Platform: GNU/Linux/x86 > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: 6.1.0RC1 > > gis.m menus contain menu entries for modules which are missing for some > reason. > > i.e. if I compile grass without C++, I don't have r.terraflow, but I sill > will have menu entry for it. > > Couldn't there be something like script which runs after all module > compilation (before make install?) and masks unavailable module entries? > Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep > menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting > guru, I can't write such script. > > -------------------------------------------- Managed by Request Tracker > > From grass-bugs at intevation.de Thu Aug 3 21:04:20 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Thu Aug 3 21:04:24 2006 Subject: [GRASS-dev] [bug #4725] (grass) nviz crashed while volume visualisation Message-ID: <20060803190420.0FC961006CC@lists.intevation.de> Glann, to me it is not entirely clear how to implement your suggestion... Markus -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Thu Aug 3 22:23:26 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Aug 3 22:23:30 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: References: Message-ID: <44D25B3E.9040901@o2.pl> Michael Barton napisa?(a): > This should be a wish, not a bug. No, it shouldn't be a wish only because we don't know how to fix it currently. All the user knows is that he selects an entry in the gis.m or d.m and he gets "command not found" or whatever other error. It is a bug for him. For me too. > Nice idea to have autogenerated menus. I've floated it a time or two and > others have mentioned it too. Maybe someone knows how to do it. I'm not trying to be wise ass or whatever. I don't know too. Just let's not pretend bugs are not bugs. Maciek From glynn at gclements.plus.com Fri Aug 4 00:09:28 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 4 00:09:34 2006 Subject: [GRASS-dev] [bug #4725] (grass) nviz crashed while volume visualisation In-Reply-To: <20060803190420.0FC961006CC@lists.intevation.de> References: <20060803190420.0FC961006CC@lists.intevation.de> Message-ID: <17618.29720.351373.670133@cerise.gclements.plus.com> Markus Neteler via RT wrote: > to me it is not entirely clear how to implement your > suggestion... The variables are initially set in mkmainPanel in panel_main.tcl. The top-level of nviz2.2_script calls Nv_makeGUI, which calls "Nv_openPanel main 0", which calls mkmainPanel. However, Nv_makeGUI creates the Togl widget early on, and the main panel much later. If anything causes a redraw inbetween, you will get the error which you report. Either the creation of the Togl canvas needs to be delayed until /everything/ required by the redraw handler has been done, or the redraw handler needs to be made more robust so that it at least doesn't crash if it gets called too early. At a minimum, you can fix the specific crash by protecting all of the atoi() calls in Ndraw_all_together_cmd() with checks to ensure that their arguments (obtained from Tcl_GetVar) are non-NULL, e.g. - if (atoi(buf_surf) == 1) + if (buf_surf && atoi(buf_surf) == 1) Or move all of the Tcl_GetVar() calls to the top of the function and add a single check, i.e.: if (!buf_surf || !buf_vect || ... ) return (TCL_OK); -- Glynn Clements From glynn at gclements.plus.com Fri Aug 4 00:19:20 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 4 00:29:15 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: References: <20060803115239.EE603101EE6@lists.intevation.de> Message-ID: <17618.30312.776595.151987@cerise.gclements.plus.com> Michael Barton wrote: > > gis.m menus contain menu entries for modules which are missing for some > > reason. > > > > i.e. if I compile grass without C++, I don't have r.terraflow, but I sill > > will have menu entry for it. > > > > Couldn't there be something like script which runs after all module > > compilation (before make install?) and masks unavailable module entries? > > Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep > > menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting > > guru, I can't write such script. > > This should be a wish, not a bug. Actually, I'm not sure that it should even be a wish. Leaving the menu entry in place lets the user know that certain functionality is "available", even if they have to get a newer version or compile GRASS themselves. If the menu entry is simply omitted, they won't even consider that option. Also, testing whether an executable is present isn't the same thing as testing whether or not it can actually be run. It's arguably better to treat all such problems in a similar manner (attempt to run the module and show any specific errors to the user) than to treat specially the case where the executable is absent. -- Glynn Clements From michael.barton at asu.edu Fri Aug 4 00:39:46 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 4 00:38:07 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <17618.30312.776595.151987@cerise.gclements.plus.com> Message-ID: Good points. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Thu, 3 Aug 2006 23:19:20 +0100 > To: Michael Barton > Cc: Paolo Cavallini via RT , > > Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for > nonexisting modules > > > Michael Barton wrote: > >>> gis.m menus contain menu entries for modules which are missing for some >>> reason. >>> >>> i.e. if I compile grass without C++, I don't have r.terraflow, but I sill >>> will have menu entry for it. >>> >>> Couldn't there be something like script which runs after all module >>> compilation (before make install?) and masks unavailable module entries? >>> Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep >>> menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting >>> guru, I can't write such script. >> >> This should be a wish, not a bug. > > Actually, I'm not sure that it should even be a wish. > > Leaving the menu entry in place lets the user know that certain > functionality is "available", even if they have to get a newer version > or compile GRASS themselves. If the menu entry is simply omitted, they > won't even consider that option. > > Also, testing whether an executable is present isn't the same thing as > testing whether or not it can actually be run. It's arguably better to > treat all such problems in a similar manner (attempt to run the module > and show any specific errors to the user) than to treat specially the > case where the executable is absent. > > -- > Glynn Clements From rez at touchofmadness.com Fri Aug 4 04:33:27 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Aug 4 04:33:42 2006 Subject: [GRASS-dev] PATCH: debugging.txt Message-ID: <1154658807.2441.0.camel@devel> Any suggestions/objections to the attached patch? -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.diff Type: text/x-patch Size: 1946 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060803/af3b0378/debug.bin From glynn at gclements.plus.com Fri Aug 4 04:59:08 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 4 04:59:11 2006 Subject: [GRASS-dev] PATCH: debugging.txt In-Reply-To: <1154658807.2441.0.camel@devel> References: <1154658807.2441.0.camel@devel> Message-ID: <17618.47100.67548.572099@cerise.gclements.plus.com> Brad Douglas wrote: > Any suggestions/objections to the attached patch? > + * After running 'configure', include/Make/Platform.make should be > + edited and append -pg to LINK_FLAGS No need; just add -pg to LDFLAGS when running configure, e.g. CFLAGS='-pg -O2' LDFLAGS=-pg ./configure ... -- Glynn Clements From rez at touchofmadness.com Fri Aug 4 06:40:21 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Fri Aug 4 06:41:18 2006 Subject: [GRASS-dev] PATCH: debugging.txt In-Reply-To: <17618.47100.67548.572099@cerise.gclements.plus.com> References: <1154658807.2441.0.camel@devel> <17618.47100.67548.572099@cerise.gclements.plus.com> Message-ID: <1154666421.2640.0.camel@devel> On Fri, 2006-08-04 at 03:59 +0100, Glynn Clements wrote: > Brad Douglas wrote: > > > Any suggestions/objections to the attached patch? > > > + * After running 'configure', include/Make/Platform.make should be > > + edited and append -pg to LINK_FLAGS > > No need; just add -pg to LDFLAGS when running configure, e.g. > > CFLAGS='-pg -O2' LDFLAGS=-pg ./configure ... Ah! Thank you. That makes things a bit easier to document. Changes attached. -- Brad Douglas KB8UYR Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.diff Type: text/x-patch Size: 1971 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060803/34a16107/debug.bin From michael.barton at asu.edu Fri Aug 4 07:55:59 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 4 07:56:09 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 Message-ID: Building on Jachym?s work and doing a personal ?summer of code? since I?m not in the field for a change, I?ve completed a 2nd version of a wxPython GUI for GRASS 6. It was developed and tested with wxPython 2.6.3 (ANSI version) and Python 2.4.3 (ActiveStates binary) for Mac OS X. The wxPython site is at and has links to Python downloads. Currently, the command line interface, display window, and example menu items are functional. There is also a non-functional demo tree control for GIS layers and notebook interface. I haven?t yet done options panels or their equivalents. In the command console window, you can enter GRASS (or other) commands to be parsed by the OS. Yes, you can even enter display commands and they will magically create displays. You can chain together display commands, separated by commas. For example, you can type... d.rast elevation_dem, d.vect roads color=red ...to create a display of a DEM overlayed by a red road network from the Spearfish60 demo data set. For some reason g.list bombs. But other commands seem to work pretty well, and can also launch the current TclTk GUI dialogs. You can open multiple display windows; the one on top and active (i.e., click it) is the one that will receive and process display commands from the console. Zoom in, zoom out, and pan controls are functional in the map display window, though zooming is a bit ugly. A few demo menu items are included. These could be redone as a toolbox, as several have suggested, using an icon mode listcontrol. There is a simple treecontrol for layers. I haven't added any icons. There is a nice custom treecontrol available that can have checkboxes and other widgets that we might want to use. Please give it a try and see what you think. It is especially important to see if it runs well cross-platform. I'm sure there are bugs, and the error trapping is minimal. I'm sure that the code could (and should) be modularized and optimized more. However, it seems to do much of the basic UI work that we need. While wxPython lacks a few items that we use in TclTk, it has a number of other widgets or more sophisticated versions of widgets that are lacking or underdeveloped in TclTk. Given that I knew ZERO Python in May, to have come this far in a few months is a testament to the relative ease of programming in this platform. I'm sold on it for GRASS UI development because of its flexibility, versitility, power, and ease of programming. For anyone interested, my references have been: Rappin, Noel and Robin Dunn 2006 wxPython in Action. Manning Publications, Greenwich, CT. Hetland, Magnus 2005 Beginning Python: from Novice to Professional. Apress/Springer-Verlag, NY. And the ActiveStates Python 2.4 documentation package. I've used SPE (cross-platform, open source) as an integrated development. environment (IDE) for coding. After this has been evaluated a bit and (hopefully) works for everyone, the next step could be to divide up the tasks of porting the GUI from TclTk to wxPython, trying to follow the GUI roadmap. This is a very big job and could use the coordinated work of several people. As we do that, and after we have a relatively functional product, we can begin to implement some of the updates, improvements, and wishes that can be better done more easily with wxPython. If you are interested in helping but don't know Python or wxPython, take heart. Even I could learn enough to do something useful in a fairly short time. If you want to download and try out gism.py, I made a section on the GRASS WIKI for it in the development/python section and linked it to the tgz package on my website for download. I also uploaded the tgz file to the WIKI, but can't figure out how to link it to the text section I did (Can someone advise me on this?) Enjoy! Michael __________________________________________ Michael Barton, Professor of Anthropology 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 Aug 4 08:19:51 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 4 08:19:54 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <44D25B3E.9040901@o2.pl> Message-ID: Maciek, What goes into the menu at the moment is what is a standard, complete (not minimal) GRASS installation, AFAICT. I try to leave out things that are not normally compiled and modules that require the installation of a separate program that does not come with GRASS (I used to leave out r.out.gdal, for example, but GDAL is now a required dependency and it is on the menu). However, this does not account for someone who compiles GRASS and decides not to include some module. Nor can it easily do so. Also, other people besides me also add to the menu occasionally, and I may miss what is a standard, complete install--especially given the rapidly changing state of the program. A new program to autogenerate a menu based on what a user decides to compile is a new feature; its lack is not a bug. In fact, it is more accurate to treat the missing feature as a bug than the non-functional menu item for it. Unless someone else writes a program to automatically generate a menu--probably requiring significant reorganization of the menu system--it is not going to happen anytime soon. In the long run, it's worthwhile to have such a system to better keep up with GRASS development. But probably it won't really be feasible to consider such a system until the switch to a new GUI development platform, like wxPython, where GUI descriptors and menus can be stored in XML format. I also agree with the sentiment of Glynn's comments. There should be a standard GUI for a standard GRASS installation. I menu item that doesn't do anything signals that the program is not complete, not that the menu is faulty. I appreciate your perspective on this. However, there are more than enough bugs of things that are actually broken to keep us all busy. But that doesn't mean that we should keep open to ways to improve the program too. Cheers Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Maciej Sieczka > Date: Thu, 03 Aug 2006 22:23:26 +0200 > To: Michael Barton > Cc: , > Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for > nonexisting modules > > Michael Barton napisa?(a): >> This should be a wish, not a bug. > > No, it shouldn't be a wish only because we don't know how to fix it > currently. > > All the user knows is that he selects an entry in the gis.m or d.m and > he gets "command not found" or whatever other error. It is a bug for > him. For me too. > >> Nice idea to have autogenerated menus. I've floated it a time or two and >> others have mentioned it too. Maybe someone knows how to do it. > > I'm not trying to be wise ass or whatever. I don't know too. Just let's > not pretend bugs are not bugs. > > Maciek > > From neteler at itc.it Fri Aug 4 09:38:53 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Aug 4 09:38:56 2006 Subject: [GRASS-dev] rotated ps.map In-Reply-To: <1154539302.6813.7.camel@linuxmain.localhost> References: <1154539302.6813.7.camel@linuxmain.localhost> Message-ID: <20060804073853.GD30796@bartok.itc.it> On Wed, Aug 02, 2006 at 02:21:42PM -0300, Bob Covill wrote: > Hello, > > I recently noticed a small bug(?) is ps.map. If the "-r" option is used > to rotate the plot, the output scale is automatically adjusted based on > an un-rotated map. In other words a map scaled to nicely fit on a > rotated page is scaled down based on the dimensions of the page which is > not rotated. > > The attached patch for r_paper.c should fix this problem. Please test > and see if this is the best solution (maybe there is an easier fix) to > the problem. > > Thanks. Bob, I have applied your patch (untested) to CVS-HEAD. Markus From maris.gis at gmail.com Fri Aug 4 09:49:34 2006 From: maris.gis at gmail.com (=?utf-8?q?M=C4=81ris_Narti=C5=A1s?=) Date: Fri Aug 4 09:49:46 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <17618.30312.776595.151987@cerise.gclements.plus.com> References: <20060803115239.EE603101EE6@lists.intevation.de> <17618.30312.776595.151987@cerise.gclements.plus.com> Message-ID: <200608041049.34907.maris.gis@gmail.com> Hi, as I'm not coder but simple user, I can not understand why letting program to fail with user UNfrendly error is good point. If there could be discussion about showing or hiding unavailable menu items*, then I don't see any reason why there should be no check against does such module (file) exists. And second - I never understood how RT works (yea, it's definitely not Bugzilla), so You probably missed my proposed 3line quickfix. So - please take a look at it and say a word - does such user friendly error handling is bad for GRASS? Just my 3c to make GRASS better, Maris. On Friday 04 August 2006 01:19, Glynn Clements wrote: > Also, testing whether an executable is present isn't the same thing as > testing whether or not it can actually be run. It's arguably better to > treat all such problems in a similar manner (attempt to run the module > and show any specific errors to the user) than to treat specially the > case where the executable is absent. Here are my first 3 lines in tcl/tk. W0ps - just found bug - it will fail IF $program already contains full path to executable ($GISBASE/etc/gm/scripts/FOO). --- gui/tcltk/gis.m/runandoutput.tcl.orig 2006-07-22 12:29:48.000000000 +0300 +++ gui/tcltk/gis.m/runandoutput.tcl 2006-08-03 23:09:43.000000000 +0300 @@ -65,10 +65,15 @@ } proc run_ui {cmd} { - global dlg path + global dlg path env set program [lindex $cmd 0] + if { ![file executable $env(GISBASE)/bin/$program] } { + tk_messageBox -icon error -message [G_msg "Sorry, your GRASS installation lacks module \"$program\""] + return + } + set code [exec -- $program --tcltk] set path .dialog$dlg From neteler at itc.it Fri Aug 4 09:59:04 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Aug 4 09:59:06 2006 Subject: [GRASS-dev] Planning for GRASS 6.2 In-Reply-To: <20060802163651.GP10564@bartok.itc.it> References: <20060802163651.GP10564@bartok.itc.it> Message-ID: <20060804075904.GE30796@bartok.itc.it> On Wed, Aug 02, 2006 at 06:36:51PM +0200, Markus Neteler wrote: > Hi, > > GRASS 6.1-CVS HEAD meanwhile contains various fixes and > improvements which are too complicated to be backported to > the release branch. > > My suggestions are: > - test 6.1.0RC1, eventuall release it as 6.1.0 > without further backports. Stop working on this branch > - do the bug day soon > - don't submit changes with heavy impact for short time > > In 2-4 weeks from now (?): > - create a new branch for 6.2, maintain it for a while > - rename 6.1-CVS HEAD to 6.3-CVS HEAD to enable developers > again to submit complex changes. Maybe a few things > can be anticipated from the GRASS 7 planning [1] (respecting > our rules to keep parameters/flags/behaviour as much as > possible for the 6.x series) > > In general 6.2 should not deviate too much from the current > 6.1-CVS HEAD to avoid a major delay. It would be great to > have it available for FOSS4G2006 in September. > > Opinions? > > Markus > > [1] http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection Hi, I take the lack of opinions as plenary approval of the proposal (BDFL?). I have created a "roadmap" page on the Wiki which contains some more details: http://grass.gdf-hannover.de/wiki/Release_Roadmap cheers Markus From neteler at itc.it Fri Aug 4 10:04:27 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Aug 4 10:04:29 2006 Subject: [GRASS-dev] [bug #4959] (grass) wrong menu entries for r.flow, r.lake and r.terraflow In-Reply-To: <20060803112856.0A8B31005DB@lists.intevation.de> References: <20060803112856.0A8B31005DB@lists.intevation.de> Message-ID: <20060804080427.GG30796@bartok.itc.it> On Thu, Aug 03, 2006 at 01:28:56PM +0200, Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4959 > ------------------------------------------------------------------------- > > Subject: wrong menu entries for r.flow, r.lake and r.terraflow > > Platform: GNU/Linux/x86 > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: 6.1.0RC1 > > modules r.lake, r.flow and r.terraflow cannot be started from gis.m (they > are just executed like from CLI) > > In r.lake and r.flow case it's just enough to change 'spawn' to 'execute' in > gui/tcltk/menus/menu.tcl > > r.terraflow needs some other fix. I have fixed those + r.grow. Markus From david.p.finlayson at gmail.com Fri Aug 4 10:17:14 2006 From: david.p.finlayson at gmail.com (David Finlayson) Date: Fri Aug 4 10:17:17 2006 Subject: [GRASS-dev] Re: WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: Message-ID: Very cool. I just knew once people took a look at Python they would get it. Sorry I haven't been very active on this this summer. I got my PhD a couple of months ago and took a new job with the USGS. So I've been taking it easy this summer and playing with my daughter. I've been teaching the GIS techs here how to use the Python interface for that other GIS (mumbles under breath) and I've been developing a new Python tool for working with our Sonar system. I really like the way ArcToolbox works conceptually (it still has bugs that drive me nuts, but...). I think that we should implement something similar in GRASS. It keeps the linkage between the GUI and the CLI strong without looking old fashioned and is very easy to extend in Python, C or whatever. I'll take a look at what you did tomorrow. Thanks for all the hard work on this. Cheers, David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060804/3868772f/attachment.html From mlennert at club.worldonline.be Fri Aug 4 10:28:47 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Aug 4 10:28:48 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: Message-ID: <44D3053F.7020402@club.worldonline.be> Michael Barton wrote: > Building on Jachym?s work and doing a personal ?summer of code? since I?m > not in the field for a change, I?ve completed a 2nd version of a wxPython > GUI for GRASS 6. Great job Michael ! > > Zoom in, zoom out, and pan controls are functional in the map display > window, though zooming is a bit ugly. Yes, but it works. Panning however causes problems for me: - first the screen flashes very frequently while the map moves - once the map is in its new position, I cannot use the mouse anymore, only my keyboard. However, when I change to another workspace of my Gnome desktop and then switch back again, the map display is empty, but I can use my mouse again. > A few demo menu items are included. Here they also cause a funny behaviour: when I chose import (or export), I get the command window (which is still the tcltk one, or ?) in modal mode, i.e. the other windows are dead. When I then click on 'close' in the command window, it closes and then reopens immediately. When I close it a second time it closes and the other windows (gis manager and map display) become active again... > > Please give it a try and see what you think. It is especially important to > see if it runs well cross-platform. My tests are on Debian testing/unstable. > While wxPython lacks a few items that we use in TclTk, such as ? > After this has been evaluated a bit and (hopefully) works for everyone, the > next step could be to divide up the tasks of porting the GUI from TclTk to > wxPython, trying to follow the GUI roadmap. This is a very big job and could > use the coordinated work of several people. Even though my programming knowledge is limited (just as - obviously - my time), I am willing to help with this, at least in the form of testing, but maybe even some simple coding. > If you want to download and try out gism.py, I made a section on the GRASS > WIKI for it in the development/python section and linked it to the tgz > package on my website for download. I also uploaded the tgz file to the > WIKI, but can't figure out how to link it to the text section I did (Can > someone advise me on this?) How about [[Media:FileName]] ? Moritz From jachym.cepicky at centrum.cz Fri Aug 4 10:29:48 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Fri Aug 4 10:29:56 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: Message-ID: <20060804082947.GA6031@localdomain> Hallo, I report that it is working on Linux (Ubuntu 6.06) - nice work! > After this has been evaluated a bit and (hopefully) works for everyone, the > next step could be to divide up the tasks of porting the GUI from TclTk to > wxPython, trying to follow the GUI roadmap. This is a very big job and could > use the coordinated work of several people. First step could be, implement Jan-Oliver's grassgui.py script (grass6/gui/wxpython) :-) should be pretty easy. > As we do that, and after we have > a relatively functional product, we can begin to implement some of the > updates, improvements, and wishes that can be better done more easily with > wxPython. If you are interested in helping but don't know Python or > wxPython, take heart. Even I could learn enough to do something useful in a > fairly short time. > > If you want to download and try out gism.py, I made a section on the GRASS > WIKI for it in the development/python section and linked it to the tgz > package on my website for download. I also uploaded the tgz file to the > WIKI, but can't figure out how to link it to the text section I did (Can > someone advise me on this?) > Thanks, looking forward to contribute a bit jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc ----------------------------------------- OFFICE: GDF-Hannover Mengendamm 16d 30177 Hannover Germany e-mail: cepicky@gdf-hannover.de URL: http://gdf-hannover.de Tel.: +49 511-39088507 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060804/b8d0dcb4/attachment.bin From neteler at itc.it Fri Aug 4 10:42:10 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Aug 4 10:42:11 2006 Subject: [GRASS-dev] A few ideas about development tools... Message-ID: <20060804084210.GI30796@bartok.itc.it> On Thu, Aug 03, 2006 at 01:13:22PM +0200, Francesco P. Lovergine wrote: > Markus asked me to report the list about some ideas I have... > > Well, a CVS repo could be easily converted to a SVN one by cvs2svn, subversion > is currently the mainstream for a cetralized SCM. Honestly, CVS has > a series of defects for management, maybe it's time to use a more > advanced tool, without loosing past history. Yes, I agree. I have recently migrated my own CVS (was running for several years and quite fat) to SVN with cvs2svn. No big deal. SVN would finally offer the possibility to create a GRASS Addon repository with granular access rights. > It is also well integrated > with Trac which is a very nice bug tracker in respect with WebRT. That > could be a major pain for migration, anyway. RT is pretty limited. We observe that developers don't like/use it. This is obviously bad. In particular, the lack of patch support (which is nice in trac) is a major pain. > Ideas? The OSGeo foundation considers to offer SVN/trac etc support for foundation projects. This could be interesting since moving bugs among projects will (hopefully) be possible. Example: if an apparent GRASS bug turns out to be a GDAL bug, we just move it there. No need to write everything again. Also code leverage will be simplified (no need to reinvent the wheel for many GIS tasks given the same programming language is used). > PS: did the Google Summer of Code be considered for sponsored students > efforts about grass activities? I think grass is eligible as mentor for > that... The new year is not so far, indeed :) Good point! Markus From tutey at o2.pl Fri Aug 4 10:47:41 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Aug 4 10:47:46 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <200608041049.34907.maris.gis@gmail.com> References: <20060803115239.EE603101EE6@lists.intevation.de> <17618.30312.776595.151987@cerise.gclements.plus.com> <200608041049.34907.maris.gis@gmail.com> Message-ID: <44D309AD.7010006@o2.pl> Ma-ris Narti?s napisa?(a): > --- gui/tcltk/gis.m/runandoutput.tcl.orig 2006-07-22 > 12:29:48.000000000 +0300 > +++ gui/tcltk/gis.m/runandoutput.tcl 2006-08-03 23:09:43.000000000 +0300 > @@ -65,10 +65,15 @@ > } > > proc run_ui {cmd} { > - global dlg path > + global dlg path env > > set program [lindex $cmd 0] > > + if { ![file executable $env(GISBASE)/bin/$program] } { > + tk_messageBox -icon error -message [G_msg "Sorry, your GRASS > installation lacks module \"$program\""] > + return > + } > + > set code [exec -- $program --tcltk] > > set path .dialog$dlg Ma-ris, Very good, in my opinion. Easy to implement and making user's life easier. I'd like to see it applied. Maybe let's add to the message: "See REQUIREMENTS.html/Optional requirements for details." (or something like that) Maciek From ychemin at gmail.com Fri Aug 4 11:24:20 2006 From: ychemin at gmail.com (Yann Chemin) Date: Fri Aug 4 11:24:24 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: Message-ID: <6278879c0608040224lcc88b11p9f0dc76ecc34f128@mail.gmail.com> very nice! I would be interested to help within a couple of months from now. Used it on a Linux Mandriva 2007. When closing the window of Import (or export) by the Upper Right X button, it reopens the dialog once. if closed again the sme way, then it does not come back. Same comments on resizing, the display flickers and troubles the cursor. Really like it ! Congrats! Yann On 04/08/06, Michael Barton wrote: > Building on Jachym?s work and doing a personal ?summer of code? since I?m > not in the field for a change, I?ve completed a 2nd version of a wxPython > GUI for GRASS 6. > > It was developed and tested with wxPython 2.6.3 (ANSI version) and Python > 2.4.3 (ActiveStates binary) for Mac OS X. The wxPython site is at > and has links to Python > downloads. Currently, the command line interface, display window, and > example menu items are functional. There is also a non-functional demo tree > control for GIS layers and notebook interface. I haven?t yet done options > panels or their equivalents. > > In the command console window, you can enter GRASS (or other) commands to be > parsed by the OS. Yes, you can even enter display commands and they will > magically create displays. You can chain together display commands, > separated by commas. For example, you can type... > > d.rast elevation_dem, d.vect roads color=red > > ...to create a display of a DEM overlayed by a red road network from the > Spearfish60 demo data set. For some reason g.list bombs. But other commands > seem to work pretty well, and can also launch the current TclTk GUI dialogs. > You can open multiple display windows; the one on top and active (i.e., > click it) is the one that will receive and process display commands from the > console. > > Zoom in, zoom out, and pan controls are functional in the map display > window, though zooming is a bit ugly. A few demo menu items are included. > These could be redone as a toolbox, as several have suggested, using an icon > mode listcontrol. There is a simple treecontrol for layers. I haven't added > any icons. There is a nice custom treecontrol available that can have > checkboxes and other widgets that we might want to use. > > Please give it a try and see what you think. It is especially important to > see if it runs well cross-platform. I'm sure there are bugs, and the error > trapping is minimal. I'm sure that the code could (and should) be > modularized and optimized more. However, it seems to do much of the basic UI > work that we need. While wxPython lacks a few items that we use in TclTk, it > has a number of other widgets or more sophisticated versions of widgets that > are lacking or underdeveloped in TclTk. Given that I knew ZERO Python in > May, to have come this far in a few months is a testament to the relative > ease of programming in this platform. I'm sold on it for GRASS UI > development because of its flexibility, versitility, power, and ease of > programming. For anyone interested, my references have been: > > Rappin, Noel and Robin Dunn > 2006 wxPython in Action. Manning Publications, Greenwich, CT. > > Hetland, Magnus > 2005 Beginning Python: from Novice to Professional. > Apress/Springer-Verlag, NY. > > And the ActiveStates Python 2.4 documentation package. > > I've used SPE (cross-platform, open source) as an integrated development. > environment (IDE) for coding. > > After this has been evaluated a bit and (hopefully) works for everyone, the > next step could be to divide up the tasks of porting the GUI from TclTk to > wxPython, trying to follow the GUI roadmap. This is a very big job and could > use the coordinated work of several people. As we do that, and after we have > a relatively functional product, we can begin to implement some of the > updates, improvements, and wishes that can be better done more easily with > wxPython. If you are interested in helping but don't know Python or > wxPython, take heart. Even I could learn enough to do something useful in a > fairly short time. > > If you want to download and try out gism.py, I made a section on the GRASS > WIKI for it in the development/python section and linked it to the tgz > package on my website for download. I also uploaded the tgz file to the > WIKI, but can't figure out how to link it to the text section I did (Can > someone advise me on this?) > > Enjoy! > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From neteler at itc.it Fri Aug 4 11:24:22 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Aug 4 11:24:32 2006 Subject: [GRASS-dev] v.digit startup error from -n position In-Reply-To: <17617.9993.431263.22596@cerise.gclements.plus.com> References: <44D0DE2E.6000407@o2.pl> <17617.9993.431263.22596@cerise.gclements.plus.com> Message-ID: <20060804092422.GJ30796@bartok.itc.it> On Wed, Aug 02, 2006 at 11:28:25PM +0100, Glynn Clements wrote: > > Michael Barton wrote: > > > OK. Looking through to the very bottom of the thread, there appears to be > > some confusion about what is meant by GUI. > > > > If v.digit is having a problem with a new vector when run from the toolbar > > button in gism, it is one thing. This SHOULD be OK. I've checked the code > > and it is written... > > > > v.digit -n map=new_map > > > > ... as Glynn indicated. If this is where the problem lies, then, there is > > some other kind of issue. > > Contrary to the "resolved" status in the RT, the real bug remains. > > v.digit is calling Tk_Main() as: > > Tk_Main(argc, argv, Tcl_AppInit); > > where argc/argv are those passed to main. > > It shouldn't be doing this; it should be passing a dummy argv, e.g. > > char *fake_argv[2]; > ... > fake_argv[0] = argv[0]; > fake_argv[1] = NULL; > Tk_Main(1, fake_argv, Tcl_AppInit); > > Changing the order of v.digit's arguments is a workaround, not a fix. > Now fixed as suggested. Someone may close the report, cannot find it. Markus From tutey at o2.pl Fri Aug 4 11:50:43 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Aug 4 11:50:50 2006 Subject: [GRASS-dev] Planning for GRASS 6.2 In-Reply-To: <20060804075904.GE30796@bartok.itc.it> References: <20060802163651.GP10564@bartok.itc.it> <20060804075904.GE30796@bartok.itc.it> Message-ID: <44D31873.1010607@o2.pl> On Wed, Aug 02, 2006 at 06:36:51PM +0200, Markus Neteler wrote: >> GRASS 6.1-CVS HEAD meanwhile contains various fixes and >> improvements which are too complicated to be backported to >> the release branch. >> >> My suggestions are: >> - test 6.1.0RC1, eventuall release it as 6.1.0 >> without further backports. Stop working on this branch >> - do the bug day soon Before that, the Bug Tracker should be updated. I've been doing my best within last months and BT has improved a lot (cheers to Paolo Cavallini and others who worked on this too!). Currently Eric Patton, Stephan Holl (thanks Guys!) and I are working on this together. But it's going slow. I can't promise we are done in a week or 2. So I wouldn't hope too much for the bug squashing day taking place before 6.2 release. More users involved in verifying the BT would be very appreciated! Ladies, Gentlemen? All it takes is to: 1. Install Grass 6.1 current CVS, or the 6.1 RC at least. 2. Download sample datasets: - for non-3D raster bugs: http://grass.itc.it/sampledata/spearfish_grass60data-0.2.tar.gz - for 3D raster bugs: http://mpa.itc.it/grasstutor/data7/slovakia3d.tar.gz 2. Pick any grass6 bug from https://intevation.de/rt/webrt?logout=guest&q_queue=grass 3. Scroll to the bottom of the report and see what's the status. 4. If the status isn't fresh (last days), or if the bug lacks enough information to *easily* reproduce it, try doing it in the appropriate dataset. 5. Update the information in the bug report: - Press the 'Reply' link. - Enter information: is the bug reproducable? If so, provide a detailed test case so a developer can easily take care of the bug; if the report is completely obscure, ask the author if he at least can update the bug's status. - CC myself, tutey at o2.pl, so I stay updated and can close or test/comment further to improve the report usability. - Press 'Send Response'. 'Replies' from the tracker are automatically forwarded *only* to bug reporter and bug owner. So if you need the reply reach any other address (including Grass dev list) you have to explicitely put it in the CC box; you can CC many addresses seperated with comma. At least, users who ever reported anything - please take a look into your reports and give some feedback! Hey, it's open source :)! After all is done I will craft a list of reproducable, confirmed bugs and developers can start effectively working on these issues. Maciek From neteler at itc.it Fri Aug 4 11:55:36 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Aug 4 11:55:39 2006 Subject: [GRASS-dev] Planning for GRASS 6.2 In-Reply-To: <44D31873.1010607@o2.pl> References: <20060802163651.GP10564@bartok.itc.it> <20060804075904.GE30796@bartok.itc.it> <44D31873.1010607@o2.pl> Message-ID: <20060804095536.GO30796@bartok.itc.it> On Fri, Aug 04, 2006 at 11:50:43AM +0200, Maciej Sieczka wrote: > On Wed, Aug 02, 2006 at 06:36:51PM +0200, Markus Neteler wrote: > > >> GRASS 6.1-CVS HEAD meanwhile contains various fixes and > >> improvements which are too complicated to be backported to > >> the release branch. > >> > >> My suggestions are: > >> - test 6.1.0RC1, eventuall release it as 6.1.0 > >> without further backports. Stop working on this branch > >> - do the bug day soon [ see also http://grass.gdf-hannover.de/wiki/Release_Roadmap ] > Before that, the Bug Tracker should be updated. I've been doing my best > within last months and BT has improved a lot (cheers to Paolo Cavallini > and others who worked on this too!). Currently Eric Patton, Stephan Holl > (thanks Guys!) and I are working on this together. But it's going slow. > I can't promise we are done in a week or 2. So I wouldn't hope too much > for the bug squashing day taking place before 6.2 release. Ok, no problem. We can do 6.2 anyway... It VERY important to have that release for FOSS4G2006. ... > After all is done I will craft a list of reproducable, confirmed bugs > and developers can start effectively working on these issues. Looking forward to see this happen (the bugfixing). Markus From grass-bugs at intevation.de Fri Aug 4 13:00:45 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Aug 4 13:00:49 2006 Subject: [GRASS-dev] [bug #4966] (grass) d.rast fg=color (for non-null cells/ binary rasters) Message-ID: <20060804110045.ED4DA101EF8@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4966 ------------------------------------------------------------------------- Subject: d.rast fg=color (for non-null cells/ binary rasters) Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: GRASS 6.1.cvs (2006) I am working a lot with binary rasters. To visualize them it would be very handy to have a "fg=color" option for d.rast which draws the non-null cells in the specified color. I'd find this more flexible than having to define color maps with r.colors. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Aug 4 13:07:01 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Aug 4 13:07:03 2006 Subject: [GRASS-dev] [bug #4967] (grass) v.clean tool=rmpseudo Message-ID: <20060804110701.DE825101EF8@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4967 ------------------------------------------------------------------------- Subject: v.clean tool=rmpseudo Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: GRASS 6.1.cvs (2006) Among the cleaning tools of v.clean I am missing one that removes "pseudonodes". A pseudonode is a node of degree 2 that connects two lines with equal cat and attributes which consequently could be represented by one single line only. -------------------------------------------- Managed by Request Tracker From bcovill at tekmap.ns.ca Fri Aug 4 13:27:14 2006 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Fri Aug 4 13:27:16 2006 Subject: [GRASS-dev] rotated ps.map In-Reply-To: <20060804073853.GD30796@bartok.itc.it> References: <1154539302.6813.7.camel@linuxmain.localhost> <20060804073853.GD30796@bartok.itc.it> Message-ID: <1154690834.6359.1.camel@linuxmain.localhost> Markus, Thanks for applying the patch. -- Bob On Fri, 2006-08-04 at 09:38 +0200, Markus Neteler wrote: > On Wed, Aug 02, 2006 at 02:21:42PM -0300, Bob Covill wrote: > > Hello, > > > > I recently noticed a small bug(?) is ps.map. If the "-r" option is used > > to rotate the plot, the output scale is automatically adjusted based on > > an un-rotated map. In other words a map scaled to nicely fit on a > > rotated page is scaled down based on the dimensions of the page which is > > not rotated. > > > > The attached patch for r_paper.c should fix this problem. Please test > > and see if this is the best solution (maybe there is an easier fix) to > > the problem. > > > > Thanks. > > Bob, > > I have applied your patch (untested) to CVS-HEAD. > > Markus From mlennert at club.worldonline.be Fri Aug 4 14:14:00 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Aug 4 14:14:00 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow Message-ID: <44D33A08.7000405@club.worldonline.be> Hello, (Please tell me if I should take this over to the grass-win list.) After quite a long time of lobbying and a first presentation, my department here at the university is seriously thinking of moving towards GRASS, both for teaching and for research. Now, several colleagues working in a MS Win environment would like to try GRASS. However, after having installed the Cygwin+GRASS combination (using the grass-cvs package from http://geni.ath.cx/grass.html) for several colleagues, I have noticed that GRASS is quite slow, at least diplaying vector maps. If I can't get this to speed up, it will be an immediate showstopper for most of my colleagues. I know I could tell them to use QGIS, but currently, the capacities of QGIS in terms of vector mapping (which is what most of my colleagues do - currently mostly with ArcView) are just too limited compared to GRASS. The other option is obviously to wait for the new GRASS python interface. But as the dynamic is launched now, I would hate to tell people: GRASS is great, just wait a bit. So: is the cygwin solution slow because of the cygwin layer in between ? Because of the X-server ? What might be a solution to speed things up ? Moritz From warmerdam at pobox.com Fri Aug 4 15:08:19 2006 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Aug 4 15:08:53 2006 Subject: [GRASS-dev] A few ideas about development tools... In-Reply-To: <20060804084210.GI30796@bartok.itc.it> References: <20060804084210.GI30796@bartok.itc.it> Message-ID: <44D346C3.4070204@pobox.com> Markus Neteler wrote: > The OSGeo foundation considers to offer SVN/trac etc support for > foundation projects. This could be interesting since moving bugs > among projects will (hopefully) be possible. Example: if an apparent > GRASS bug turns out to be a GDAL bug, we just move it there. No need > to write everything again. Also code leverage will be simplified > (no need to reinvent the wheel for many GIS tasks given the same > programming language is used). Markus / GRASS developers, I think the general intention was to maintain a distinct bug database instance for each project, which would mean we can't easily reassign bugs between project within a single database. I will say, I found it quite helpful having various projects (ie. gdal, libtiff, libgeotiff, proj.4) all in the same bug database at remotesensing.org for exactly the reason you indicate. I just don't think we will get that benefit on OSGeo unless we make a particular effort to do so. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | President OSGF, http://osgeo.org From epatton at nrcan.gc.ca Fri Aug 4 15:48:35 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Fri Aug 4 15:48:39 2006 Subject: [GRASS-dev] Bugs vs. wishes Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55B1F@s5-dar-r1.nrn.nrcan.gc.ca> Hi guys, One thing that I've noticed a lot in the brief time I've been pouring through old bugs is how often a wish is submitted as a bug. Ideas for improvments, complaints about 'this could be better' or 'it should work this way instead' get submitted as bugs when they are /not/ bugs. If software doesn't work the way you think it should, this is not a bug. It is a wish. I find that a lot on the BT. I wonder if there is a way to put some kind of message in bold letters on the BT advising the user to clearly discriminate between what they want the software to do (a wish) vs. what it is supposed to do based on the Grass documentation (a bug). A /lot/ of "bugs" could be prevented this way. It's fine to have a wish list a mile long, but the more we can prevent false bugs from being posted, the faster we can get a true bug short list created for the devs. I don't know if there is anything that can really be done about it, I'm just grumbling. (I'll submit a wish for this). ~ Eric. From cavallini at faunalia.it Fri Aug 4 15:51:55 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Fri Aug 4 15:51:56 2006 Subject: [GRASS-dev] Bugs vs. wishes In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55B1F@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C26208C55B1F@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <44D350FB.3000907@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Right. Could you reclassify the bugs as wishes? All the best. pc Patton, Eric ha scritto: > Hi guys, > > One thing that I've noticed a lot in the brief time I've been pouring > through old bugs is how often a wish is submitted as a bug. Ideas for > improvments, complaints about 'this could be better' or 'it should work this > way instead' get submitted as bugs when they are /not/ bugs. If software > doesn't work the way you think it should, this is not a bug. It is a wish. I > find that a lot on the BT. > > I wonder if there is a way to put some kind of message in bold letters on > the BT advising the user to clearly discriminate between what they want the > software to do (a wish) vs. what it is supposed to do based on the Grass > documentation (a bug). A /lot/ of "bugs" could be prevented this way. It's > fine to have a wish list a mile long, but the more we can prevent false bugs > from being posted, the faster we can get a true bug short list created for > the devs. > > I don't know if there is anything that can really be done about it, I'm just > grumbling. (I'll submit a wish for this). > > ~ Eric. -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE01D6/NedwLUzIr4RAtT3AJ4o9jTEs06PdzPvDuKgXB46ICm5UQCdHtnU +iJma4xgHlirfijL0DqET4k= =mcU0 -----END PGP SIGNATURE----- From epatton at nrcan.gc.ca Fri Aug 4 15:57:09 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Fri Aug 4 15:57:12 2006 Subject: [GRASS-dev] Bugs vs. wishes Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55B20@s5-dar-r1.nrn.nrcan.gc.ca> If it seems that a bug should be reclassed as a wish, I include a note in the BT saying why I think so, CC'ing it to Maciek. If he's in agreement, he takes care of it. ~ Eric. -----Original Message----- From: Paolo Cavallini To: Patton, Eric Cc: 'grass-dev@grass.itc.it' Sent: 8/4/2006 9:51 AM Subject: Re: [GRASS-dev] Bugs vs. wishes -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Right. Could you reclassify the bugs as wishes? All the best. pc Patton, Eric ha scritto: > Hi guys, > > One thing that I've noticed a lot in the brief time I've been pouring > through old bugs is how often a wish is submitted as a bug. Ideas for > improvments, complaints about 'this could be better' or 'it should work this > way instead' get submitted as bugs when they are /not/ bugs. If software > doesn't work the way you think it should, this is not a bug. It is a wish. I > find that a lot on the BT. > > I wonder if there is a way to put some kind of message in bold letters on > the BT advising the user to clearly discriminate between what they want the > software to do (a wish) vs. what it is supposed to do based on the Grass > documentation (a bug). A /lot/ of "bugs" could be prevented this way. It's > fine to have a wish list a mile long, but the more we can prevent false bugs > from being posted, the faster we can get a true bug short list created for > the devs. > > I don't know if there is anything that can really be done about it, I'm just > grumbling. (I'll submit a wish for this). > > ~ Eric. -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE01D6/NedwLUzIr4RAtT3AJ4o9jTEs06PdzPvDuKgXB46ICm5UQCdHtnU +iJma4xgHlirfijL0DqET4k= =mcU0 -----END PGP SIGNATURE----- From mlennert at club.worldonline.be Fri Aug 4 16:06:40 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Aug 4 16:06:40 2006 Subject: [GRASS-dev] [Fwd: Grass cvs-6.1 very slow on imac intel] Message-ID: <56360.164.15.134.162.1154700400.squirrel@geog-pc40.ulb.ac.be> Maybe some other Mac users have something to say ? Moritz ---------------------------- Original Message ---------------------------- Subject: Grass cvs-6.1 very slow on imac intel From: "Didier Peeters" Date: Fri, August 4, 2006 14:32 To: lorenzo.moretti@bologna.enea.it Cc: "Moritz Lennert" -------------------------------------------------------------------------- Dear Lorenzo, Thank you for providing GRASS binaries for Mac OS X. I'm trying to use the last cvs 6.1 version downloaded from http:// wwwamb.bologna.enea.it/forgrass/downloadcvs.htm on an Imac with an Intel processor and it seems to be very slow, displaying a simple vector map takes about 20 seconds, which is far more slowly than on the Debian system of my colleague. Do you have any explanation for that ? Is this due to the Rosetta emulation ? Best wishes. Didier Peeters Institut de Gestion de l'Environnement et d'Am?nagement du Territoire Universit? Libre de Bruxelles CP246 - Acc?s 5 - Campus Plaine Boulevard du Triomphe B-1050 Bruxelles T?l : 32-2-650 65 16 Fax : 32-2-650 50 92 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060804/a4fdd8f1/untitled-2.html From neteler at itc.it Fri Aug 4 16:15:27 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Aug 4 16:15:28 2006 Subject: [GRASS-dev] How the GRASS Webserver and related infrastructure works Message-ID: <20060804141527.GA1271@bartok.itc.it> Hi, just in case... I have written a small document on "How the GRASS Webserver and related infrastructure works". Find it in CVS in doc/infrastructure.txt . It shortly describes == GRASS Web server == == GRASS Wiki == == GRASS Source code repository == == GRASS Bugtracker == == GRASS Quality Control == and the dependencies between the systems. If I forgot anything, please let me know. cheers Markus -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From glynn at gclements.plus.com Fri Aug 4 16:21:53 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 4 16:21:58 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <200608041049.34907.maris.gis@gmail.com> References: <20060803115239.EE603101EE6@lists.intevation.de> <17618.30312.776595.151987@cerise.gclements.plus.com> <200608041049.34907.maris.gis@gmail.com> Message-ID: <17619.22529.513917.922258@cerise.gclements.plus.com> M-Dàris Narti-B¹s wrote:-A > as I'm not coder but simple user, I can not understand why letting program to > fail with user UNfrendly error is good point. It would certainly be useful to improve error messages. Apart from anything else, errors arising from executing commands from a menu item shouldn't include the Tcl backtrace, only the actual error. > If there could be discussion > about showing or hiding unavailable menu items*, then I don't see any reason > why there should be no check against does such module (file) exists. As I said before, non-existence is only one possible problem. The executable itself might exist, but it might require shared libraries which are missing, or it may be a script which uses an executable which doesn't exist. > > Also, testing whether an executable is present isn't the same thing as > > testing whether or not it can actually be run. It's arguably better to > > treat all such problems in a similar manner (attempt to run the module > > and show any specific errors to the user) than to treat specially the > > case where the executable is absent. > > Here are my first 3 lines in tcl/tk. > W0ps - just found bug - it will fail IF $program already contains full path to > executable ($GISBASE/etc/gm/scripts/FOO). > > --- gui/tcltk/gis.m/runandoutput.tcl.orig 2006-07-22 > 12:29:48.000000000 +0300 > +++ gui/tcltk/gis.m/runandoutput.tcl 2006-08-03 23:09:43.000000000 +0300 > @@ -65,10 +65,15 @@ > } > > proc run_ui {cmd} { > - global dlg path > + global dlg path env > > set program [lindex $cmd 0] > > + if { ![file executable $env(GISBASE)/bin/$program] } { Not everything is in $GISBASE/bin; some are in $GISBASE/scripts or $GISBASE/etc/gm/script. Also, on Windows the file itself may have a .exe suffix. -- Glynn Clements From glynn at gclements.plus.com Fri Aug 4 16:34:46 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 4 16:34:50 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <44D33A08.7000405@club.worldonline.be> References: <44D33A08.7000405@club.worldonline.be> Message-ID: <17619.23302.904232.511653@cerise.gclements.plus.com> Moritz Lennert wrote: > Now, several colleagues working in a MS Win environment would like to > try GRASS. However, after having installed the Cygwin+GRASS combination > (using the grass-cvs package from http://geni.ath.cx/grass.html) for > several colleagues, I have noticed that GRASS is quite slow, at least > diplaying vector maps. If I can't get this to speed up, it will be an > immediate showstopper for most of my colleagues. > > I know I could tell them to use QGIS, but currently, the capacities of > QGIS in terms of vector mapping (which is what most of my colleagues do > - currently mostly with ArcView) are just too limited compared to GRASS. > The other option is obviously to wait for the new GRASS python > interface. But as the dynamic is launched now, I would hate to tell > people: GRASS is great, just wait a bit. > > So: is the cygwin solution slow because of the cygwin layer in between ? > Because of the X-server ? What might be a solution to speed things up ? Are you displaying the maps with XDRIVER or with gis.m? If you're using gis.m, the X server isn't involved in rendering the maps; gis.m uses the PNG driver to render them into an image. -- Glynn Clements From kwythers at umn.edu Fri Aug 4 16:35:47 2006 From: kwythers at umn.edu (Kirk R. Wythers) Date: Fri Aug 4 16:35:52 2006 Subject: [GRASS-dev] creating new modules Message-ID: <3080786D-9DBF-493E-94E4-66D4C54D202D@umn.edu> I am interested in porting an ecosystem model (carbon balance model) to a grass module. Currently my simulation model consists of 4 .cpp files (essentially a "main" file, a vegetation parameters file, and climate file, and a io file), and then 3 associated header files. I found the link: http://grass.itc.it/intro/modelintegration.html Which describes simulation models that have been incorporated into grass. But could also use some general advice as to "best practices" new module structure. Has anyone put together a grass module howto? Perhaps the programmers guide? I've been digging around on the wiki, but haven't found what I'm looking for yet. What I am basically asking for is to be pointed to a well done example that I should follow as "simulation model module template" Any suggestions? Thanks, Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060804/a410d0dd/attachment.html From woklist at kyngchaos.com Fri Aug 4 17:12:38 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Aug 4 17:12:52 2006 Subject: [GRASS-dev] [Fwd: Grass cvs-6.1 very slow on imac intel] In-Reply-To: <56360.164.15.134.162.1154700400.squirrel@geog-pc40.ulb.ac.be> References: <56360.164.15.134.162.1154700400.squirrel@geog-pc40.ulb.ac.be> Message-ID: Yes, the Rosetta translation is probably slowing it down some. Not a big issue when coming from a PPC Mac, since those processors generally top out at slower speeds than the Intel Macs, but coming from another Intel-native OS you might notice the Rosetta slowdown. Not really trying to squeeze in on Lorenzo's work (well, maybe a tiny bit ^_^), but how about trying my Universal OSX GRASS package? It's pretty solid now, and it would be nice to get more feedback on it. I just uploaded an update this morning to take care of a couple startup issues. On Aug 4, 2006, at 9:06 AM, Moritz Lennert wrote: > Maybe some other Mac users have something to say ? > > Moritz > > ---------------------------- Original Message > ---------------------------- > Subject: Grass cvs-6.1 very slow on imac intel > From: "Didier Peeters" > Date: Fri, August 4, 2006 14:32 > To: lorenzo.moretti@bologna.enea.it > Cc: "Moritz Lennert" > ---------------------------------------------------------------------- > ---- > > Dear Lorenzo, > > Thank you for providing GRASS binaries for Mac OS X. I'm trying to > use the last cvs 6.1 version downloaded from http:// > wwwamb.bologna.enea.it/forgrass/downloadcvs.htm on an Imac with an > Intel processor and it seems to be very slow, displaying a simple > vector map takes about 20 seconds, which is far more slowly than on > the Debian system of my colleague. Do you have any explanation for > that ? Is this due to the Rosetta emulation ? > ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From tutey at o2.pl Fri Aug 4 18:11:17 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Aug 4 18:11:21 2006 Subject: [GRASS-dev] v.digit startup error from -n position In-Reply-To: <20060804092422.GJ30796@bartok.itc.it> References: <44D0DE2E.6000407@o2.pl> <17617.9993.431263.22596@cerise.gclements.plus.com> <20060804092422.GJ30796@bartok.itc.it> Message-ID: <44D371A5.4040608@o2.pl> Markus Neteler napisa?(a): > Now fixed as suggested. > Someone may close the report, cannot find it. Done. Maciek From tutey at o2.pl Fri Aug 4 18:26:14 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Aug 4 18:26:18 2006 Subject: [GRASS-dev] Bugs vs. wishes In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55B20@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C26208C55B20@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <44D37526.6070108@o2.pl> Patton, Eric napisa?(a): > If it seems that a bug should be reclassed as a wish, I include a note in > the BT saying why I think so, CC'ing it to Maciek. If he's in agreement, he > takes care of it. Since I've been involved with the Grass BT, for each new doubtfull bug report I'm taking care to reassign and comment such issues as they are hot (though I may seem to liberal in terms of what-a-bug-is for many of you ;)). I'm affraid we cannot fully avoid it, no matter what warnings. It happens in other projects as well. The bigger the project the more often. It only takes somebody to keep an eye. For now it's me and I hope I'm making developers' life a but easier a bit. I aggree with Eric that there are still some such fake bugs out there, but I can assure you there were many more :). Maciek From tutey at o2.pl Fri Aug 4 18:38:02 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Aug 4 18:38:06 2006 Subject: [GRASS-dev] Planning for GRASS 6.2 In-Reply-To: <20060804095536.GO30796@bartok.itc.it> References: <20060802163651.GP10564@bartok.itc.it> <20060804075904.GE30796@bartok.itc.it> <44D31873.1010607@o2.pl> <20060804095536.GO30796@bartok.itc.it> Message-ID: <44D377EA.6070409@o2.pl> Markus Neteler napisa?(a): >> I can't promise we are done in a week or 2. So I wouldn't hope too much >> for the bug squashing day taking place before 6.2 release. > > Ok, no problem. We can do 6.2 anyway... It VERY important to have > that release for FOSS4G2006. Sure, good luck! Maciek From cavallini at faunalia.it Fri Aug 4 19:44:15 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Fri Aug 4 19:44:15 2006 Subject: [GRASS-dev] file permissions Message-ID: <44D3876F.8030804@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. After compilation, I'm getting wrong files permissions: - -rw-r----- 1 root root 613 2006-08-04 19:32 /usr/local/grass-6.1.0beta1/etc/grass_write_ascii.style and other files in: /usr/local/grass-6.1.0beta1/bwidget/lang/* My fault, or Makefile's? Very easy to fix, but a bit annoying. All the best. pc - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE04dv/NedwLUzIr4RAg/hAKCws7Q8mu84xvVDlpfmKTA253kpggCfe/GU bwdEjofZjuKAKYwkzXr2AhA= =bLlM -----END PGP SIGNATURE----- From michael.barton at asu.edu Fri Aug 4 20:44:49 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 4 20:42:22 2006 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 4, Issue 14 In-Reply-To: <200608040842.k748gNxi031288@grass.itc.it> Message-ID: I agree. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Reply-To: Date: Fri, 4 Aug 2006 10:42:23 +0200 To: Subject: grass-dev Digest, Vol 4, Issue 14 Hi, I take the lack of opinions as plenary approval of the proposal (BDFL?). I have created a "roadmap" page on the Wiki which contains some more details: http://grass.gdf-hannover.de/wiki/Release_Roadmap cheers Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060804/b6658977/attachment.html From michael.barton at asu.edu Fri Aug 4 20:53:35 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 4 20:51:08 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <44D309AD.7010006@o2.pl> Message-ID: This looks like a good workaround to the issue of missing modules. If it works, go ahead and commit it. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Maciej Sieczka > Date: Fri, 04 Aug 2006 10:47:41 +0200 > To: Ma-ris Narti?s > Cc: > Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for > nonexisting modules > > Ma-ris Narti?s napisa?(a): > >> --- gui/tcltk/gis.m/runandoutput.tcl.orig 2006-07-22 >> 12:29:48.000000000 +0300 >> +++ gui/tcltk/gis.m/runandoutput.tcl 2006-08-03 23:09:43.000000000 +0300 >> @@ -65,10 +65,15 @@ >> } >> >> proc run_ui {cmd} { >> - global dlg path >> + global dlg path env >> >> set program [lindex $cmd 0] >> >> + if { ![file executable $env(GISBASE)/bin/$program] } { >> + tk_messageBox -icon error -message [G_msg "Sorry, your GRASS >> installation lacks module \"$program\""] >> + return >> + } >> + >> set code [exec -- $program --tcltk] >> >> set path .dialog$dlg > > Ma-ris, > > Very good, in my opinion. Easy to implement and making user's life > easier. I'd like to see it applied. > > Maybe let's add to the message: "See REQUIREMENTS.html/Optional > requirements for details." (or something like that) > > Maciek > > From michael.barton at asu.edu Fri Aug 4 21:01:23 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 4 20:59:01 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <44D33A08.7000405@club.worldonline.be> Message-ID: Moritz, Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules work without X11 or there is a TclTk replacement for critical modules. v.digit is the only major exception now. NVIZ without X11 may still be in transition. It still has problems on Intel Macs and I'm not sure about where it is for Windows. I hear that GRASS compiles under MinGW without X11. What this all means is that with comparatively minimal work (compared to rebuilding the entire GUI and any related links to C modules in wxPython), GRASS **should** run natively under Windows with nearly all modules functional. This ought to be a LOT faster than Cygwin. We need some people to test and work on this. I believe that Glynn Clements is working on it, but could probably use some collaborators. I have very similar issues to yours. If we could get a native windows version--for all the folks who prefer or are forced to use that platform--I would have no problem justifying using GRASS in classes and getting colleagues to try it. In many respects it is easier to use and teach than ArcGIS. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Moritz Lennert > Date: Fri, 04 Aug 2006 14:14:00 +0200 > To: Grass Developers List > Subject: [GRASS-dev] GRASS & cygwin quite slow > > Hello, > > (Please tell me if I should take this over to the grass-win list.) > > After quite a long time of lobbying and a first presentation, my > department here at the university is seriously thinking of moving > towards GRASS, both for teaching and for research. > > Now, several colleagues working in a MS Win environment would like to > try GRASS. However, after having installed the Cygwin+GRASS combination > (using the grass-cvs package from http://geni.ath.cx/grass.html) for > several colleagues, I have noticed that GRASS is quite slow, at least > diplaying vector maps. If I can't get this to speed up, it will be an > immediate showstopper for most of my colleagues. > > I know I could tell them to use QGIS, but currently, the capacities of > QGIS in terms of vector mapping (which is what most of my colleagues do > - currently mostly with ArcView) are just too limited compared to GRASS. > The other option is obviously to wait for the new GRASS python > interface. But as the dynamic is launched now, I would hate to tell > people: GRASS is great, just wait a bit. > > So: is the cygwin solution slow because of the cygwin layer in between ? > Because of the X-server ? What might be a solution to speed things up ? > > Moritz > > From michael.barton at asu.edu Fri Aug 4 21:17:52 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Aug 4 21:15:34 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <17619.22529.513917.922258@cerise.gclements.plus.com> Message-ID: Glynn's right. I got ahead of myself in encouraging this fix. Making a better error trapping is a good idea. However this script can't just look in $GISBASE/bin, it also has to look in $GISBASE/scripts and $GISBASE/etc/gm(or dm)/script. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Fri, 4 Aug 2006 15:21:53 +0100 > To: M?ris Narti?s > Cc: > Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for > nonexisting modules > > >> > Not everything is in $GISBASE/bin; some are in $GISBASE/scripts or > $GISBASE/etc/gm/script. Also, on Windows the file itself may have a > .exe suffix. > > -- > Glynn Clements > > From florian.kindl at uibk.ac.at Fri Aug 4 21:26:47 2006 From: florian.kindl at uibk.ac.at (Florian Kindl) Date: Fri Aug 4 21:24:52 2006 Subject: [GRASS-dev] Bugs vs. wishes In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55B1F@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C26208C55B1F@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: On 04.08.2006, at 15:48, Patton, Eric wrote: > Hi guys, > > One thing that I've noticed a lot in the brief time I've been pouring > through old bugs is how often a wish is submitted as a bug. Eric, today I submitted two wishes via the form at [1] - I chose "type of report - wish" from the menu. Both came through grass-devel classified as "bug". Shouldn't the form be modified to classify them correctly as "wish" and consequently append them to their own queue of wishes instead of bugs? \Flo. [1] http://grass.itc.it/bugtracking/bugreport.html From glynn at gclements.plus.com Fri Aug 4 23:38:45 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 4 23:38:51 2006 Subject: [GRASS-dev] file permissions In-Reply-To: <44D3876F.8030804@faunalia.it> References: <44D3876F.8030804@faunalia.it> Message-ID: <17619.48741.803132.328192@cerise.gclements.plus.com> Paolo Cavallini wrote: > After compilation, I'm getting wrong files permissions: > - -rw-r----- 1 root root 613 2006-08-04 19:32 > /usr/local/grass-6.1.0beta1/etc/grass_write_ascii.style > and other files in: > /usr/local/grass-6.1.0beta1/bwidget/lang/* > My fault, or Makefile's? A lot of Makefiles do bulk copying using "tar c | tar x", which will preserve the permissions of the original files. The easiest solution is to run "chmod -R go+rX" on the build directory. The only long-term solution is to stop using "tar" in the Makefiles, but to use $(INSTALL) and $(INSTALL_DATA) instead. -- Glynn Clements From glynn at gclements.plus.com Fri Aug 4 23:47:16 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 4 23:48:21 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: References: <44D33A08.7000405@club.worldonline.be> Message-ID: <17619.49252.581045.981257@cerise.gclements.plus.com> Michael Barton wrote: > Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules > work without X11 or there is a TclTk replacement for critical modules. > v.digit is the only major exception now. NVIZ without X11 may still be in > transition. It still has problems on Intel Macs and I'm not sure about where > it is for Windows. Executing external programs (e.g. using g.list to generate a list of maps) doesn't work. The actual OpenGL rendering works fine. > I hear that GRASS compiles under MinGW without X11. > > What this all means is that with comparatively minimal work (compared to > rebuilding the entire GUI and any related links to C modules in wxPython), > GRASS **should** run natively under Windows with nearly all modules > functional. This ought to be a LOT faster than Cygwin. The main issue here is that gis.m would need to use the immediate rendering provided by the new version of libraster. The MSVC runtime doesn't include socket functions (and Windows itself doesn't support Unix-domain sockets), so using a separate PNG driver won't work. -- Glynn Clements From glynn at gclements.plus.com Fri Aug 4 23:56:35 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 4 23:58:32 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: References: <17619.22529.513917.922258@cerise.gclements.plus.com> Message-ID: <17619.49811.942266.744633@cerise.gclements.plus.com> Michael Barton wrote: > Glynn's right. I got ahead of myself in encouraging this fix. Making a > better error trapping is a good idea. However this script can't just look in > $GISBASE/bin, it also has to look in $GISBASE/scripts and $GISBASE/etc/gm(or > dm)/script. And, as I already mentioned, a given command may or may not have a .exe suffix. E.g. in the MinGW versions which I've built, programs only get a .exe suffix if they don't contain any dots. OTOH, it's possible to build an executable with no dots and without a .exe suffix, and equally possible for an individual Makefile to force a .exe suffix on any executable. More generally, trying to figure out in advance whether executing a given command will succeed is the wrong approach. The only reliable approach is to actually run the command and check whether or not it did succeed. If it didn't succeed, figuring out why isn't entirely straightforward, as the error message (corresponding to ENOENT) will vary between platforms, and depend upon the user's locale settings. -- Glynn Clements From michael.barton at asu.edu Sat Aug 5 00:21:16 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 5 00:18:45 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: <17619.49811.942266.744633@cerise.gclements.plus.com> Message-ID: I suppose a partial solution would be to at least check to see if the command file listed in the menu exists in one of the 3 standard locations and return something on the order of "This GRASS command is not installed". It wouldn't help if it was installed but not executable. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Fri, 4 Aug 2006 22:56:35 +0100 > To: Michael Barton > Cc: M?ris Narti?s , > Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for > nonexisting modules > > > Michael Barton wrote: > >> Glynn's right. I got ahead of myself in encouraging this fix. Making a >> better error trapping is a good idea. However this script can't just look in >> $GISBASE/bin, it also has to look in $GISBASE/scripts and $GISBASE/etc/gm(or >> dm)/script. > > And, as I already mentioned, a given command may or may not have a > .exe suffix. E.g. in the MinGW versions which I've built, programs > only get a .exe suffix if they don't contain any dots. OTOH, it's > possible to build an executable with no dots and without a .exe > suffix, and equally possible for an individual Makefile to force a > .exe suffix on any executable. > > More generally, trying to figure out in advance whether executing a > given command will succeed is the wrong approach. The only reliable > approach is to actually run the command and check whether or not it > did succeed. If it didn't succeed, figuring out why isn't entirely > straightforward, as the error message (corresponding to ENOENT) will > vary between platforms, and depend upon the user's locale settings. > > -- > Glynn Clements From michael.barton at asu.edu Sat Aug 5 00:29:02 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 5 00:26:28 2006 Subject: [GRASS-dev] Behavior of explore mode in GIS Manager Message-ID: I have a question for you all. I just discovered an unexpected (to me) behavior of explore mode in gism. I thought explore mode only tried to fill the display window with the rendered map. However, it also changes the region resolution as you zoom in and out. To give an example: Start with the 30m DEM in Spearfish and set the region to match the DEM Zoom in and the resolution increases to 10m, 5m, 1m Zoom out and the resolution decreases to 60m, 90m, etc Essentially, it is changing so that a constant number of grid cells are represented in the display window. I first thought this was a bug and have been trying to find where it is located over the past day. I found it and discovered that it is intentional. So here?s the question. Is this the way we want zooming to work in this special mode? If so, we need to change the mouse over help to make sure this is clear. If not, we need to change how explore mode works so that it does not change resolution. I can see advantages and disadvantages of each. I?ve included the code of the relevant function below. Michael __________________________________________ Michael Barton, Professor of Anthropology 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 --- relevant function of mapcanvas.tcl with code lines marked that change resolution. proc MapCanvas::currentzoom { mon } { variable zoom_attrs variable exploremode variable monitor_zooms global canvas_w global canvas_h # Fetch the current zoom settings set region {} foreach attr $zoom_attrs { lappend region $monitor_zooms($mon,1,$attr) } # If explore mode is engaged blow up the region to match the canvas if {$exploremode($mon) == 1} { # Set the region to the smallest region no smaller than the canvas set canvas_ar [expr {1.0 * $canvas_w($mon) / $canvas_h($mon)}] set expanded_nsew [MapCanvas::shrinkwrap 1 [lrange $region 0 3] $canvas_ar] puts "expanded = $expanded_nsew" foreach {n s e w} $expanded_nsew {break} # Calculate the resolutions ---> lappend expanded_nsew [expr {1.0 * ($n - $s) / $canvas_h($mon)}] ---> lappend expanded_nsew [expr {1.0 * ($e - $w) / $canvas_w($mon)}] set region $expanded_nsew } return $region } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060804/900a8c8a/attachment.html From michael.barton at asu.edu Sat Aug 5 00:34:32 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 5 00:32:04 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17619.49252.581045.981257@cerise.gclements.plus.com> Message-ID: This bombs in the prototype wxPython UI too. Is this somehow different from other GRASS modules? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > From: Glynn Clements > Date: Fri, 4 Aug 2006 22:47:16 +0100 > To: Michael Barton > Cc: Moritz Lennert , Grass Developers List > > Subject: Re: [GRASS-dev] GRASS & cygwin quite slow > > > Executing external programs (e.g. using g.list to generate a list of > maps) doesn't work. The actual OpenGL rendering works fine. > >> I hear that GRASS compiles under MinGW without X11. From michael.barton at asu.edu Sat Aug 5 00:38:57 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 5 00:36:26 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <20060804082947.GA6031@localdomain> Message-ID: A VERY good idea. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Jachym Cepicky > Date: Fri, 4 Aug 2006 10:29:48 +0200 > To: Michael Barton > Cc: Grass Developers List , Trevor Wiens > , David Finlayson > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > First step could be, implement Jan-Oliver's grassgui.py script > (grass6/gui/wxpython) :-) should be pretty easy. > From ychemin at gmail.com Sat Aug 5 09:12:05 2006 From: ychemin at gmail.com (Yann Chemin) Date: Sat Aug 5 09:12:07 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <20060804082947.GA6031@localdomain> Message-ID: <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> > > First step could be, implement Jan-Oliver's grassgui.py script > > (grass6/gui/wxpython) :-) should be pretty easy. Well, it actually works already.. somehow. 1-copy grass6/gui/wxpython/grassgui.py and grass6/gui/wxpython/grass-interface.py into py_gm/ from which you run the "python gism.py &" command. 2-open GRASScvs and select i.e. Spearfish 3-cd /dir/to/py_gm/ ; python gism.py & 4-Once the gism.py opens the GRASS GIS GUI, type the following in the command line interface of the GUI: "d.rast --interface-description | python grassgui.py" 5-d.rast GUI will appear, type i.e. elevation.10m, then select OK button and close the d.rast GUI (Upper Right X Button for example). After destroying the d.rast GUI, elevation.10m will be displayed in the Map Display-1. anybody who knows a little bit of Python might indicate how we could get this seemlessly into the actual GUI. Yann On 05/08/06, Michael Barton wrote: > A VERY good idea. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Jachym Cepicky > > Date: Fri, 4 Aug 2006 10:29:48 +0200 > > To: Michael Barton > > Cc: Grass Developers List , Trevor Wiens > > , David Finlayson > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > > > > First step could be, implement Jan-Oliver's grassgui.py script > > (grass6/gui/wxpython) :-) should be pretty easy. > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From adiez at uv.es Sat Aug 5 12:42:33 2006 From: adiez at uv.es (Agustin Diez Castillo) Date: Sat Aug 5 12:43:08 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: Message-ID: <49C8101D-A24B-4165-BD04-1766B557E4D7@uv.es> On a Imac running PPC 10.4.7 I got this error when launching 21:12:53: No handler found for image type. 21:12:53: no bitmap handler for type 50 defined. Other than that it works. I have a hard time figuring up the correct setting until I got this "You?ll want to add the following environment variables. Open or create the file .bash_profile in your home directory and add the following: PYTHONBIN=/Library/Frameworks/Python.framework/Versions/2.4/bin export PATH=/usr/local/bin:/usr/local/sbin:$PYTHONBIN:$PATH " Agustin ******************************************************* Dr. Agustin Diez Castillo Departament de Prehistoria i Arqueologia Universitat de Valencia Phone: +34 963 86 42 42 Avda. Blasco Iba?ez, 28 Fax: +34 963 98 38 87 Valencia 46010 ******************************************************* On 04/08/2006, at 07:55 AM, Michael Barton wrote: > d.rast elevation_dem, d.vect roads color=red -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060805/2a51fe77/attachment.html From adiez at uv.es Sat Aug 5 13:31:30 2006 From: adiez at uv.es (Agustin Diez Castillo) Date: Sat Aug 5 13:31:37 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> References: <20060804082947.GA6031@localdomain> <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> Message-ID: <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> Do you mean grass-interface.dtd? I have no grass-interface.py > grass6/gui/wxpython/grass-interface.py into py_gm/ from which you run -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060805/60efb424/attachment-0001.html From soerengebbert at gmx.de Sat Aug 5 16:02:10 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Sat Aug 5 16:02:15 2006 Subject: [GRASS-dev] g3d lib bug? Message-ID: <200608051602.10115.soerengebbert@gmx.de> Dear devs, while extending some g3d modules i noticed that the resampling function (nearest neighbor) and the window structure is not set when a new g3d map is created (G3d_openCellNew()). Only G3d_openCellOld() sets those values. Was there a specific reason to not implement this in G3d_openCellNew()? I do need this functionality! Without setting the resampling function and the window of the new map, i do not have access to values i have already written with G3d_putValue(). G3d_getValue() will give only null values or will crash. I have added a diff of the changes i want to make to lib/g3d/g3dopen.c. What do you think? Best regards Soeren cvs server: Diffing . Index: g3dopen.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/g3d/g3dopen.c,v retrieving revision 2.4 diff -u -r2.4 g3dopen.c --- g3dopen.c 6 May 2006 22:50:17 -0000 2.4 +++ g3dopen.c 5 Aug 2006 13:56:52 -0000 @@ -320,6 +320,11 @@ return (void *) NULL; } + /*Set the map window to the map region */ + G3d_regionCopy (&(map->window), region); + /*Set the resampling function to nearest neighbor for data access */ + G3d_getNearestNeighborFunPtr (&(map->resampleFun)); + G3d_maskOff (map); return (void *) map; From michael.barton at asu.edu Sat Aug 5 17:35:12 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 5 17:35:17 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <49C8101D-A24B-4165-BD04-1766B557E4D7@uv.es> Message-ID: Hola Agustin, The first 2 errors (I think) are because it somehow can?t find the icon images in the icon folder that come with the package. It should find these if the icon folder is correctly located inside the py_gm folder and you cd to this folder to run gism.py. Could you check these? For the second error, I don?t have PYTHONBIN set on my Mac (at least not obviously). Nothing is returned with $PYTHONBIN and I don?t have a .bash_profile. That said, I?m sure that something is set to point toward the Python 2.4 installation. I installed ActiveState?s Python 2.4 binaries and this probably does some automatic environment setting. Also, there is Apple?s Python 2.3 installed in a slightly different location that may cause confusion. The message you got is probably a good idea to make sure that the proper Python installation is being referenced. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Agustin Diez Castillo Date: Sat, 5 Aug 2006 12:42:33 +0200 To: Michael Barton Cc: Grass Developers List Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 On a Imac running PPC 10.4.7 I?got this error when launching 21:12:53: No handler found for image type. 21:12:53: no bitmap handler for type 50 defined. Other than that it works. I have a hard time figuring up the correct setting until I got this "You?ll want to add the following environment variables. Open or create the file .bash_profile in your home directory and add the following: PYTHONBIN=/Library/Frameworks/Python.framework/Versions/2.4/bin export PATH=/usr/local/bin:/usr/local/sbin:$PYTHONBIN:$PATH " Agustin ******************************************************* Dr. Agustin Diez Castillo Departament de Prehistoria i Arqueologia Universitat de Valencia???????? Phone: +34 963 86 42 42 Avda. Blasco Iba?ez, 28???????? Fax:?? +34 963 98 38 87 Valencia 46010 ******************************************************* On 04/08/2006, at 07:55 AM, Michael Barton wrote: > > d.rast elevation_dem, d.vect roads color=red > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060805/ec2711ab/attachment.html From michael.barton at asu.edu Sat Aug 5 17:35:52 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 5 17:35:57 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> Message-ID: This is great. I'll have to try it out and see what happens. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Sat, 5 Aug 2006 14:12:05 +0700 > To: Grass Developers List > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > >>> First step could be, implement Jan-Oliver's grassgui.py script >>> (grass6/gui/wxpython) :-) should be pretty easy. > > Well, it actually works already.. somehow. > > 1-copy grass6/gui/wxpython/grassgui.py and > grass6/gui/wxpython/grass-interface.py into py_gm/ from which you run > the "python gism.py &" command. > > 2-open GRASScvs and select i.e. Spearfish > > 3-cd /dir/to/py_gm/ ; python gism.py & > > 4-Once the gism.py opens the GRASS GIS GUI, type the following in the > command line interface of the GUI: "d.rast --interface-description | > python grassgui.py" > > 5-d.rast GUI will appear, type i.e. elevation.10m, then select OK > button and close the d.rast GUI (Upper Right X Button for example). > After destroying the d.rast GUI, elevation.10m will be displayed in > the Map Display-1. > > anybody who knows a little bit of Python might indicate how we could > get this seemlessly into the actual GUI. > > Yann > > On 05/08/06, Michael Barton wrote: >> A VERY good idea. >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> 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: Jachym Cepicky >>> Date: Fri, 4 Aug 2006 10:29:48 +0200 >>> To: Michael Barton >>> Cc: Grass Developers List , Trevor Wiens >>> , David Finlayson >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>> >>> >>> First step could be, implement Jan-Oliver's grassgui.py script >>> (grass6/gui/wxpython) :-) should be pretty easy. >>> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> > > From michael.barton at asu.edu Sat Aug 5 17:39:35 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Aug 5 17:39:39 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> Message-ID: Agustin, This is a typo. You need to get this from the cvs. You can use the web version to download it. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Agustin Diez Castillo Date: Sat, 5 Aug 2006 13:31:30 +0200 To: Yann Chemin Cc: Grass Developers List Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 Do you mean?grass-interface.dtd? I have no?grass-interface.py > > grass6/gui/wxpython/grass-interface.py into py_gm/ from which you run > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060805/7ad606a3/attachment.html From adiez at uv.es Sat Aug 5 18:24:12 2006 From: adiez at uv.es (Agustin Diez Castillo) Date: Sat Aug 5 18:26:33 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: Message-ID: Michael, I didn't explain myself > PYTHONBIN=/Library/Frameworks/Python.framework/Versions/2.4/bin was the solution I found to direct python to ActiveState. I have tested it in another machine and it is working w/o problem besides the icon thing. To me it seems that the icons are there, I have changed permissions with no luck. My py_gm directory /py_gm agus$ ls -l total 240 -rw-r--r-- 1 agus agus 1237 Aug 4 06:55 README.txt -rwxrwxr-x 1 agus agus 14325 Aug 4 06:40 gism.py -rw-r--r-- 1 agus agus 14325 Aug 4 06:39 gism.py.bak -rw-r--r-- 1 agus agus 12364 Aug 5 12:32 gism.pyc -rw-rw-r-- 1 agus agus 4448 Jul 3 23:02 grass-interface.dtd -rwxrwxr-x 1 agus agus 12950 Jul 3 23:21 grassgui.py drwxr-xr-x 20 agus agus 680 Aug 4 20:39 icons -rwxr-xr-x 1 agus agus 12022 Aug 4 06:15 map.py -rw-r--r-- 1 agus agus 11048 Aug 5 12:32 map.pyc -rwxrwxr-x 1 agus agus 8871 Aug 4 06:16 render.py -rw-r--r-- 1 agus agus 6533 Aug 5 12:32 render.pyc ../py_gm agus$ cd icons ../py_gm/icons agus$ ls -l total 88 -rwxrwxr-x 1 agus agus 0 Aug 4 20:39 Makefile -rwxr-xr-x 1 agus agus 580 May 5 20:03 Makefile.1 -rwxrwxr-x 1 agus agus 0 Aug 4 20:39 README -rwxr-xr-x 1 agus agus 1129 Mar 23 19:56 README.1 -rwxr-xr-x 1 agus agus 250 May 6 00:10 element-cell.1.gif -rwxrwxr-x 1 agus agus 0 Aug 4 20:39 element-cell.gif -rwxr-xr-x 1 agus agus 189 May 6 00:12 element-vector.1.gif -rwxrwxr-x 1 agus agus 0 Aug 4 20:39 element-vector.gif -rw-r--r-- 1 agus agus 258 May 5 22:02 gui-display.gif -rwxr-xr-x 1 agus agus 180 May 5 22:47 gui-pan.1.gif -rwxrwxr-x 1 agus agus 0 Aug 4 20:39 gui-pan.gif -rwxr-xr-x 1 agus agus 137 May 5 22:55 gui-startmon.1.gif -rwxrwxr-x 1 agus agus 0 Aug 4 20:39 gui-startmon.gif -rwxr-xr-x 1 agus agus 191 May 5 21:54 gui-zoom_back.gif -rwxr-xr-x 1 agus agus 184 May 5 21:51 gui-zoom_in.gif -rwxr-xr-x 1 agus agus 180 May 5 21:58 gui-zoom_out.gif -rwxr-xr-x 1 agus agus 176 Jun 11 14:58 pan.gif ../py_gm/icons agus$ chmod a+wx * On 05/08/2006, at 05:35 PM, Michael Barton wrote: > Hola Agustin, > > The first 2 errors (I think) are because it somehow can?t find the > icon images in the icon folder that come with the package. It > should find these if the icon folder is correctly located inside > the py_gm folder and you cd to this folder to run gism.py. Could > you check these? > > For the second error, I don?t have PYTHONBIN set on my Mac (at > least not obviously). Nothing is returned with $PYTHONBIN and I > don?t have a .bash_profile. > > That said, I?m sure that something is set to point toward the > Python 2.4 installation. I installed ActiveState?s Python 2.4 > binaries and this probably does some automatic environment setting. > Also, there is Apple?s Python 2.3 installed in a slightly different > location that may cause confusion. The message you got is probably > a good idea to make sure that the proper Python installation is > being referenced. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Agustin Diez Castillo > Date: Sat, 5 Aug 2006 12:42:33 +0200 > To: Michael Barton > Cc: Grass Developers List > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > On a Imac running PPC 10.4.7 > I got this error when launching > 21:12:53: No handler found for image type. > 21:12:53: no bitmap handler for type 50 defined. > Other than that it works. > I have a hard time figuring up the correct setting until I got this > "You?ll want to add the following environment variables. Open or > create the file .bash_profile in your home directory and add the > following: > PYTHONBIN=/Library/Frameworks/Python.framework/Versions/2.4/bin > export PATH=/usr/local/bin:/usr/local/sbin:$PYTHONBIN:$PATH > " > Agustin > > ******************************************************* > Dr. Agustin Diez Castillo > Departament de Prehistoria i Arqueologia > Universitat de Valencia Phone: +34 963 86 42 42 > Avda. Blasco Iba?ez, 28 Fax: +34 963 98 38 87 > Valencia 46010 > ******************************************************* > > > > On 04/08/2006, at 07:55 AM, Michael Barton wrote: > >> >> d.rast elevation_dem, d.vect roads color=red >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060805/329274bb/attachment-0001.html From glynn at gclements.plus.com Sat Aug 5 18:32:06 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 5 18:36:19 2006 Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules In-Reply-To: References: <17619.49811.942266.744633@cerise.gclements.plus.com> Message-ID: <17620.51206.163141.530662@cerise.gclements.plus.com> Michael Barton wrote: > I suppose a partial solution would be to at least check to see if the > command file listed in the menu exists in one of the 3 standard locations > and return something on the order of "This GRASS command is not installed". > It wouldn't help if it was installed but not executable. The problem is that you need to err on the side of caution, i.e. only disable the option if you can guarantee that the command will fail. Otherwise you're introducing a real bug to fix a not-really-a-bug. That's assuming that you consider disabling menu items to be a good idea in the first place (which I don't). -- Glynn Clements From glynn at gclements.plus.com Sat Aug 5 18:41:12 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 5 18:47:21 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17619.49252.581045.981257@cerise.gclements.plus.com> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> Message-ID: <17620.51752.396232.734623@cerise.gclements.plus.com> Glynn Clements wrote: > > Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules > > work without X11 or there is a TclTk replacement for critical modules. > > v.digit is the only major exception now. NVIZ without X11 may still be in > > transition. It still has problems on Intel Macs and I'm not sure about where > > it is for Windows. > > Executing external programs (e.g. using g.list to generate a list of > maps) doesn't work. The actual OpenGL rendering works fine. > > > I hear that GRASS compiles under MinGW without X11. > > > > What this all means is that with comparatively minimal work (compared to > > rebuilding the entire GUI and any related links to C modules in wxPython), > > GRASS **should** run natively under Windows with nearly all modules > > functional. This ought to be a LOT faster than Cygwin. > > The main issue here is that gis.m would need to use the immediate > rendering provided by the new version of libraster. The MSVC runtime > doesn't include socket functions (and Windows itself doesn't support > Unix-domain sockets), so using a separate PNG driver won't work. Having finally managed to compile a recent version under Cygwin (since updating Cygwin, --enable-shared no longer works), I've found another reason to make gis.m use immediate rendering. Cygwin implements Unix-domain sockets using TCP sockets. On my system, the result is that running any d.* command pops up a ZoneAlarm dialog asking me if the command should be allowed to make network connections. This starts to get annoying rather quickly. You only need to answer once per command, but that still means once for the PNG driver, once for d.font, once for d.rast, etc. Also, if you update an executable, ZoneAlarm tells you that the program has changed and asks again. Needless to say, this is a significant nuisance if you're recompiling GRASS regularly. -- Glynn Clements From glynn at gclements.plus.com Sat Aug 5 19:01:11 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 5 19:05:38 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: References: <17619.49252.581045.981257@cerise.gclements.plus.com> Message-ID: <17620.52951.348154.527585@cerise.gclements.plus.com> Michael Barton wrote: > > Executing external programs (e.g. using g.list to generate a list of > > maps) doesn't work. The actual OpenGL rendering works fine. > > This bombs in the prototype wxPython UI too. Is this somehow different from > other GRASS modules? Oops. The NVIZ map browser uses "ls", not g.list. In any case, it appears to be a Tcl/Tk issue. The code works from a normal wish shell, so something specific to the NVIZ code interferes with the exec command. -- Glynn Clements From grass-bugs at intevation.de Sat Aug 5 19:33:41 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Aug 5 19:33:43 2006 Subject: [GRASS-dev] [bug #4972] (grass) 5 Sterne Hotels. Message-ID: <20060805173341.6FD581005BE@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4972 ------------------------------------------------------------------------- ***Fuenf Sterne Strand Hotel an Tuerkischen Riveria HP eine Woche = KOSTENLOS.*** Als S Group 2006 feiern wir das 10jaehrige Jubilaeum unserer Gruendung=2E Aus diesem Anlass bieten wir in den 5 Sterne Strandhotels in Belek Antalya Aufenthalt-Halbpension kostenlos=2E Im Einzelnen: Reisetermine sind zwischen dem 10.11.2006 bis zum 30.04.2007, jeden Freitag und Samstag=2E Flug und Transfer zum Hotel ?bernehmen Sie selbst=2E Auf Wunsch koennen wir dies fuer Sie organisieren=2E Schon ab Euro 89.- p. P. fuer die einfache Flugstrecke, koennen Sie auch = Ihre Fluege bei uns bequem buchen=2E Ab;Duesseldorf-Frankfurt-Muenchen-Hamburg-Hannover-Berlin(TXL-SXF) - Friedrichshafen- Wien-Salzburg-Graz-Linz-Zuerich und Basel=2E KOSTENLOSE INKLUSIVELEISTUNG: =B7 6 Uebernachtungen im 5-Sterne-Hotel im Doppelzimmer=2E =B7 1 Uebernachtung in einem Thermalhotel in Pamukkale=2E =B7 Begruesungscocktail =B7 1-Taegiger Ausflug nach Antalya mit Bootsfahrt=2E =B7 Sprechstunden (Taeglich) im Hotel =B7 Klimatisierte Bu?e fuer 2 Ausfluege=2E =B7 Stadtlichgepruefte Reisefuehrer *Info Reise fuer die Gruppenleitern moeglich. Ihr S Group Team. --- Headers Follow --- >From suedtuerkei@freenet.de Sat Aug 5 19:33:41 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id 536E61005B8 for ; Sat, 5 Aug 2006 19:33:41 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 9D0D7199C4B for ; Sat, 5 Aug 2006 19:33:41 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 72CE2199A5F for ; Sat, 5 Aug 2006 19:33:41 +0200 (CEST) Received: from nati (unknown [85.104.228.140]) by kolab.intevation.de (Postfix) with SMTP id 114BF199C4B for ; Sat, 5 Aug 2006 19:33:39 +0200 (CEST) Received: from nati[127.0.0.1] by nati[127.0.0.1] (SMTPD32); Sat, 5 Aug 2006 20:33:43 +0300 Reply-To: sreisen@freenet.de Message-ID: From: "5 Sterne Hotels." To: Subject: 5 Sterne Hotels. Date: Sat, 5 Aug 2006 20:32:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5] X-Spam-Level: -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Sat Aug 5 20:49:40 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Aug 5 20:49:49 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17620.52951.348154.527585@cerise.gclements.plus.com> References: <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.52951.348154.527585@cerise.gclements.plus.com> Message-ID: <17620.59460.354001.833248@cerise.gclements.plus.com> Glynn Clements wrote: > > > Executing external programs (e.g. using g.list to generate a list of > > > maps) doesn't work. The actual OpenGL rendering works fine. > > > > This bombs in the prototype wxPython UI too. Is this somehow different from > > other GRASS modules? > > Oops. The NVIZ map browser uses "ls", not g.list. But that's irrelevant; it was getting stuck on calling g.gisenv to get GISDBASE etc. I've discovered that it seems to blocking on stdin; pressing Return in the terminal allows it to continue, until the next exec. Furthermore, running nviz as "nviz ... From neteler at itc.it Sat Aug 5 23:09:23 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Aug 5 23:09:25 2006 Subject: [GRASS-dev] GRASS release roadmap updated Message-ID: <20060805210923.GE11865@bartok.itc.it> Hi, I have finetuned the proposed Release Roadmap: http://grass.gdf-hannover.de/wiki/Release_Roadmap Markus From neteler at itc.it Sat Aug 5 23:15:21 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Aug 5 23:15:22 2006 Subject: [GRASS-dev] GRASS release roadmap updated In-Reply-To: <20060805210923.GE11865@bartok.itc.it> References: <20060805210923.GE11865@bartok.itc.it> Message-ID: <20060805211521.GG11865@bartok.itc.it> On Sat, Aug 05, 2006 at 11:09:23PM +0200, Markus Neteler wrote: > Hi, > > I have finetuned the proposed Release Roadmap: > http://grass.gdf-hannover.de/wiki/Release_Roadmap > BTW: The idea of moving the roadmap to the Wiki is to - enable others to contribute (which rarely happens in the Web-CVS since full write access to CVS is needed) - render it more transparent and predictable since email announcements often get lost in the noise I have suggested there to get out 6.2 (really!) in early September to have it ready for the big conference in Lausanne. Hope that this finds consensus. cheers Markus From neteler at itc.it Sat Aug 5 23:19:12 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Aug 5 23:19:15 2006 Subject: [GRASS-dev] Bugs vs. wishes In-Reply-To: References: <0E5A77B55A57D511BB3F0002A537C26208C55B1F@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <20060805211912.GH11865@bartok.itc.it> On Fri, Aug 04, 2006 at 09:26:47PM +0200, Florian Kindl wrote: > > On 04.08.2006, at 15:48, Patton, Eric wrote: > > >Hi guys, > > > >One thing that I've noticed a lot in the brief time I've been pouring > >through old bugs is how often a wish is submitted as a bug. > > Eric, > today I submitted two wishes via the form at [1] - I chose "type of > report - wish" from the menu. > Both came through grass-devel classified as "bug". > Shouldn't the form be modified to classify them correctly as "wish" > and consequently append them to their own queue of wishes instead of > bugs? > > \Flo. > > [1] > http://grass.itc.it/bugtracking/bugreport.html In the HTML source code is used "wish6" which should be ok. If it doesn't work I suspect something in the bugtracker not functioning (any more). ? Markus From florian.kindl at uibk.ac.at Sun Aug 6 00:02:07 2006 From: florian.kindl at uibk.ac.at (Florian Kindl) Date: Sun Aug 6 00:00:15 2006 Subject: [GRASS-dev] announcing v.strahler public alpha Message-ID: Hello lists! I am writing a module that calculates the Strahler Order for all lines of a given dendritic network. The program works on input data that meets some requirements: The input vector map must be free of cycles. More than one tree in the input data is allowed. No given flow direction is needed. To find the outlet of each tree, a DEM must be given. Strahler Order is not attached as a new layer yet, it is merely written to an ASCII file. Everyone interested in this functionality can get the sources along with sparse documentation from http://geo4.uibk.ac.at/tilde/kindl/grass/v.strahler.tgz Copy the file to the "vector" directory of your grass source tree and unpack it with `tar xzvf v.strahler.tgz` `cd v.strahler` and type `make` to compile. It should compile cleanly against current grass 6.1-cvs If you like, you can help me developing the program: Users: Apply the module on a dataset of yours. Does it hang? Does it produce incorrect output? How can the behaviour of the program be improved? How should it format its output, what other options would you like to see? Can input data be treated (v.clean ..?) to make v.strahler work better? If it works, is it acceptable, performance-wise? You can use g.gisenv set="DEBUG=4" to see more (maybe too much) information about the process. Developers: Are there any fundamental flaws in the design of the algorithm? Any severe quirks in the code? Is there any solution on the treatment of cyclic graphs? How would you realize the output? How can the code be optimized? - This is my first try in C programming, I'm sure there's a lot that can be improved. I am looking forward to your opinions and experience, may this alpha one day become a beta! However, I will be out-of-office for some weeks from Tuesday 8th - so this public alpha phase will last until mid-september at least. \Flo. Florian Kindl Dept. of Geography University of Innsbruck, Austria From florian.kindl at uibk.ac.at Sun Aug 6 00:08:07 2006 From: florian.kindl at uibk.ac.at (Florian Kindl) Date: Sun Aug 6 00:06:12 2006 Subject: [GRASS-dev] Bugs vs. wishes In-Reply-To: <20060805211912.GH11865@bartok.itc.it> References: <0E5A77B55A57D511BB3F0002A537C26208C55B1F@s5-dar-r1.nrn.nrcan.gc.ca> <20060805211912.GH11865@bartok.itc.it> Message-ID: <12937CE2-C036-45D5-AD6D-09316281F7CF@uibk.ac.at> On 05.08.2006, at 23:19, Markus Neteler wrote: > > In the HTML source code is used "wish6" > > > > > > > which should be ok. If it doesn't work I suspect something in the > bugtracker not functioning (any more). > RT stores it in the "Area" wish6. So far, this is correct. However, it is forwarded to grass-devel with Subject: [bug #nnnn] ^^^ ? \flo. From michael.barton at asu.edu Sun Aug 6 06:56:28 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sun Aug 6 06:56:40 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: Message-ID: Agustin, For some reason, I don?t need to set PYTHONBIN. But it is probably a good idea to set it to make sure of the python path. For the icons, I?m baffled. Have you tried to look at the icon gifs to see if they are perhaps corrupted? Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Agustin Diez Castillo Date: Sat, 5 Aug 2006 18:24:12 +0200 To: Michael Barton Cc: Agust?n Diez Castillo , Grass Developers List Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 Michael, I didn't explain myself > PYTHONBIN=/Library/Frameworks/Python.framework/Versions/2.4/bin was the solution I found to direct python to ActiveState. I have tested it in another machine and it is working w/o problem besides the icon thing. To me it seems that the icons are there, I have changed permissions with no luck. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060805/da6889e9/attachment.html From grass-bugs at intevation.de Sun Aug 6 14:04:36 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Aug 6 14:04:38 2006 Subject: [GRASS-dev] [bug #4976] (grass) tolotti walter Message-ID: <20060806120436.F20541005B7@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4976 ------------------------------------------------------------------------- Subject: tolotti walter Platform: WindowsNT/2000/XP grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! -------------------------------------------- Managed by Request Tracker From smitch at mac.com Sun Aug 6 16:47:34 2006 From: smitch at mac.com (Scott Mitchell) Date: Sun Aug 6 16:47:45 2006 Subject: [GRASS-dev] Mac OS X frameworks beta 2 In-Reply-To: <7AD2E2F5-A92B-42CB-B537-042D6204D506@kyngchaos.com> References: <7AD2E2F5-A92B-42CB-B537-042D6204D506@kyngchaos.com> Message-ID: <6FC3C4C4-57B4-4998-A1C3-9817D365697E@mac.com> I've been using a new Macbook to test this out - so unfortunately everything's new, complicating troubleshooting, but I'm catching up. I downloaded the frameworks, and installed. Tried your GRASS.app, and it's working well, at least in light testing. Then tried compiling against your frameworks, and that worked once I got the hang of the flags. Finding this updated post of yours was a big help. Did my own compile of 6.1-RC1, and it went cleanly. Starting up the program, after choosing the mapset, two of the gis.m windows briefly appear (I think it's the credits screen and the command history window), then all disappears, and I'm left with only the GRASS prompt. Finally noticed that this was using the Aqua wish - so setting env vbls to use X11 wish, and it seems to be working fine. Will keep playing, just wanted to send some feedback. Cheers, Scott On 29-Jul-06, at 2:11 PM, William Kyngesburye wrote: > Fine tuned a few things. For all frameworks, they should work in > Panther now (10.3.9). It was simpler than I made it sound ^_^ I > also switched to disk images for distribution because I was having > problems with Apple's zipping. > > The GEOS framework includes both normal C++ and C APIs in one. So, > saying -framework GEOS is the same as saying -lgeos -lgeos_c, like > I do with the UnixImageIO framework. > > For the UnixImageIO framework, I linked the unix/lib/*.dylib's to > the framework itself instead of the internal libraries, so no > messing around with configure scripts should be needed now. And > that effectively hides the internal libraries. > > Curl was added internally to the GDAL framework for the Panther > compatibility. > > I may have broken something else, and there may still be other > issues to work out, but it's beta. > > > To go along with this (sorry for the cross-posting on this), > another GRASS.app beta. It now should work in Panther (but I > haven't tested it much there). I made it automatically start X11 > if not running already. Updated to today's CVS snapshot. > > > As an example to use the frameworks, here's part of my GRASS > configure line: > > ./configure --enable-sysv --with-freetype --with-freetype- > includes="/Library/Frameworks/FreeType.framework/Headers/freetype2 \ > /Library/Frameworks/FreeType.framework/Headers" \ > --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib \ > --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config \ > --with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/ > Headers \ > --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib \ > --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj \ > --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/ > Headers \ > --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib \ > --with-png-includes=/Library/Frameworks/UnixImageIO.framework/ > Headers \ > --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib \ > --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/ > Headers \ > --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib \ > --with-cxx --with-sqlite \ > --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib \ > --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/Headers \ > --with-fftw-includes=/Library/Frameworks/FFTW3.framework/Headers \ > --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib \ > --with-tcltk-includes=/usr/local/grasslibs/include \ > --with-tcltk-libs=/usr/local/grasslibs/lib \ > --with-x --without-motif --without-glw --with-opengl=x11 > > The Tcl/Tk libs are an X11 build. I left out the various DB > options, you would use those as you normally would. > > Notice how the includes point to the Headers folder in the > frameworks, and the libs point to the unix/lib in the frameworks. > Since the actual binary of the library is the framework name, the > unix/lib has a normal lib*.dylib symlinked to the framework binary, > so detecting and using -lfoo works. > > If a *-config script is used, like for GDAL, the script will give > you the correct -framework and include flags to use. > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "Oh, look, I seem to have fallen down a deep, dark hole. Now what > does that remind me of? Ah, yes - life." > > - Marvin > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From woklist at kyngchaos.com Sun Aug 6 18:36:19 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Aug 6 18:36:29 2006 Subject: [GRASS-dev] Mac OS X frameworks beta 2 In-Reply-To: <6FC3C4C4-57B4-4998-A1C3-9817D365697E@mac.com> References: <7AD2E2F5-A92B-42CB-B537-042D6204D506@kyngchaos.com> <6FC3C4C4-57B4-4998-A1C3-9817D365697E@mac.com> Message-ID: <0910D252-D9C7-4708-8E2E-EE3224FDE8CC@kyngchaos.com> Good to hear the feedback. I'm not sure what's up with the Aqua Wish - did you use Apple's or the ActiveTcl? Apple's might have issues since it's a bit old. Has the same Aqua wish worked before? But, probably not anything to do with the frameworks. The Aqua TclTk (IMHO) is not really usable anyways - for a "Mac" look and feel, it's not complete, there are still many GUI widgets that aren't native for some reason (ie sliders) so it ends up looking strange, and OSX widgets are often larger and mess with layout (or from another perspective, have more fluff around the edges and so cut off text labels, like in buttons). Note - I've released a few more versions, and I felt it was ready to pull out of beta. Check out the current set of frameworks. I just added GD and PDFlib this weekend so I can work on switching my MapServer package over to the frameworks. On Aug 6, 2006, at 9:47 AM, Scott Mitchell wrote: > > I've been using a new Macbook to test this out - so unfortunately > everything's new, complicating troubleshooting, but I'm catching up. > > I downloaded the frameworks, and installed. Tried your GRASS.app, > and it's working well, at least in light testing. Then tried > compiling against your frameworks, and that worked once I got the > hang of the flags. Finding this updated post of yours was a big > help. Did my own compile of 6.1-RC1, and it went cleanly. > Starting up the program, after choosing the mapset, two of the > gis.m windows briefly appear (I think it's the credits screen and > the command history window), then all disappears, and I'm left with > only the GRASS prompt. Finally noticed that this was using the > Aqua wish - so setting env vbls to use X11 wish, and it seems to be > working fine. > > Will keep playing, just wanted to send some feedback. > > Cheers, > Scott ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From kwythers at umn.edu Sun Aug 6 23:46:12 2006 From: kwythers at umn.edu (Kirk R. Wythers) Date: Sun Aug 6 23:46:24 2006 Subject: [GRASS-dev] creating new modules In-Reply-To: <680746D3-6D9C-46A5-B131-A02027ADEA8F@unity.ncsu.edu> References: <3080786D-9DBF-493E-94E4-66D4C54D202D@umn.edu> <680746D3-6D9C-46A5-B131-A02027ADEA8F@unity.ncsu.edu> Message-ID: <9FE82898-0BCA-4F29-97BC-3FB8BE477F04@umn.edu> On Aug 5, 2006, at 11:03 PM, Helena Mitasova wrote: > > On Aug 4, 2006, at 10:35 AM, Kirk R. Wythers wrote: > >> I am interested in porting an ecosystem model (carbon balance >> model) to a grass module. Currently my simulation model consists >> of 4 .cpp files (essentially a "main" file, a vegetation >> parameters file, and climate file, and a io file), and then 3 >> associated header files. I found the link: >> >> http://grass.itc.it/intro/modelintegration.html >> >> Which describes simulation models that have been incorporated into >> grass. > > those models are pretty old and the integration was done mostly for > GRASS4* > some have been rewritten from fortran code (including the not > listed simwe) so they may not > be such good examples. Thanks for the info Helena. I found a soil water model (MODFLOW) that a grass module has been written for r.gmtg However, the README file for it says that it was written for grass 5.4. Does anyone know if there are particular coding issue when writing a module for 6.1 relative to 5.4? > >> >> But could also use some general advice as to "best practices" new >> module structure. Has anyone put together a grass module howto? >> Perhaps the programmers guide? I've been digging around on the >> wiki, but haven't found what I'm looking for yet. What I am >> basically asking for is to be pointed to a well done example that >> I should follow as "simulation model module template" > > I am curious to see whether somebody will provide it - I would love > to have it too! > > Helena >> >> Any suggestions? >> >> Thanks, >> >> Kirk >> >> >> >> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > From ychemin at gmail.com Mon Aug 7 05:39:09 2006 From: ychemin at gmail.com (Yann Chemin) Date: Mon Aug 7 05:39:11 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> References: <20060804082947.GA6031@localdomain> <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> Message-ID: <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> Sorry it was a typo indeed, grass-interface.dtd and grassgui.py are the two files to be copied over to py_gm/ Would it be possible to drop py_gm/ into grass6/gui/wxpython/ ? since they both can interoperate, it should facilitate the temptation of a python programmer to "plug" them together through the py_gm/ buttons... Another thought, would it be interesting to develop a program to convert the .tcl code into python interface? or is it better to recode directly in Python? Yann On 05/08/06, Agustin Diez Castillo wrote: > > Do you mean grass-interface.dtd? I have no grass-interface.py > > > > grass6/gui/wxpython/grass-interface.py into py_gm/ from which you run > > From mlennert at club.worldonline.be Mon Aug 7 10:21:19 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Aug 7 10:21:26 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17620.51752.396232.734623@cerise.gclements.plus.com> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> Message-ID: <44D6F7FF.3070409@club.worldonline.be> Glynn Clements wrote: > Glynn Clements wrote: > >>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules >>> work without X11 or there is a TclTk replacement for critical modules. >>> v.digit is the only major exception now. NVIZ without X11 may still be in >>> transition. It still has problems on Intel Macs and I'm not sure about where >>> it is for Windows. Using the grass-cvs binaries from http://geni.ath.cx/grass.html which according to the web page date from April 17, 2006, even the gis.m seems to use X. At least, there is a large X in the top left of all the windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat) starts Xwin and then launches an xterm within that Xwin session. So, how can I use the guis without X ? > Having finally managed to compile a recent version under Cygwin (since > updating Cygwin, --enable-shared no longer works), I've found another > reason to make gis.m use immediate rendering. > > Cygwin implements Unix-domain sockets using TCP sockets. On my system, > the result is that running any d.* command pops up a ZoneAlarm dialog > asking me if the command should be allowed to make network > connections. This starts to get annoying rather quickly. I can confirm this. Moritz From soerengebbert at gmx.de Mon Aug 7 12:45:18 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Mon Aug 7 12:45:24 2006 Subject: [GRASS-dev] GRASS C function names Message-ID: <200608071245.18383.soerengebbert@gmx.de> Dear devs, i have a question about the function naming guidline of GRASS. I would like to add a guidline to the SUBMITTING file. But the problem is that we have two naming conventions for library functions in GRASS. The common convention is: G_fatal_error(), to place a "_" between the function description strings, but within the G3D library a different convention was used: G3d_fatalError(). Personally i like the function name convention of the G3D lib, because this convention is used in other libraries i am programming with and i think its better readable. So i named all the functions in my r3.* modules like the G3D lib standard. But i would like to see a uniform programming standard/API within GRASS, so what to do? Should the G3D library API be an exception and all the user defined function names should use the common API (G_name_name), or should the module developer decide on his own what convention to use? Or should we/i rename all G3D function names to meet the common convention? Well thats not impossible, but a huge amount of work (the testing and the docs). In my opinion a function naming guidline is important, like the coding standards of VTK: http://www.vtk.org/Wiki/VTK_Coding_Standards Also a clear guidline how to name a module (not more than 2 dots in name?) and how to name the command line variables would be helpful. What do you think? Best regards Soeren From Thomas.Adams at noaa.gov Mon Aug 7 14:20:58 2006 From: Thomas.Adams at noaa.gov (Thomas Adams) Date: Mon Aug 7 14:21:00 2006 Subject: [GRASS-dev] [Fwd: Grass cvs-6.1 very slow on imac intel] In-Reply-To: <56360.164.15.134.162.1154700400.squirrel@geog-pc40.ulb.ac.be> References: <56360.164.15.134.162.1154700400.squirrel@geog-pc40.ulb.ac.be> Message-ID: <44D7302A.8030108@noaa.gov> Didier, Which model iMac are you using; which CPU (Power PC G3, G4, G5, Intel??) and what speed is the CPU? Tom Moritz Lennert wrote: > Maybe some other Mac users have something to say ? > > Moritz > > ---------------------------- Original Message ---------------------------- > Subject: Grass cvs-6.1 very slow on imac intel > From: "Didier Peeters" > Date: Fri, August 4, 2006 14:32 > To: lorenzo.moretti@bologna.enea.it > Cc: "Moritz Lennert" > -------------------------------------------------------------------------- > > Dear Lorenzo, > > Thank you for providing GRASS binaries for Mac OS X. I'm trying to > use the last cvs 6.1 version downloaded from http:// > wwwamb.bologna.enea.it/forgrass/downloadcvs.htm on an Imac with an > Intel processor and it seems to be very slow, displaying a simple > vector map takes about 20 seconds, which is far more slowly than on > the Debian system of my colleague. Do you have any explanation for > that ? Is this due to the Rosetta emulation ? > > Best wishes. > > Didier Peeters > Institut de Gestion de l'Environnement et d'Am?nagement du Territoire > Universit? Libre de Bruxelles > CP246 - Acc?s 5 - Campus Plaine > Boulevard du Triomphe > B-1050 Bruxelles > T?l : 32-2-650 65 16 > Fax : 32-2-650 50 92 > > > > > > ------------------------------------------------------------------------ > > Dear Lorenzo, > > Thank you for providing GRASS binaries for Mac OS X. I'm trying to > use the last cvs 6.1 version downloaded > from http://wwwamb.bologna.enea.it/forgrass/downloadcvs.htm on an Imac > with an Intel processor and it seems to be very slow, displaying a > simple vector map takes about 20 seconds, which is far more slowly > than on the Debian system of my colleague. Do you have any > explanation for that ? Is this due to the Rosetta emulation ? > > Best wishes. > > Didier Peeters > Institut de Gestion de l'Environnement et d'Am?nagement du Territoire > Universit? Libre de Bruxelles > CP246 - Acc?s 5 - Campus Plaine > Boulevard du Triomphe > B-1050 Bruxelles > T?l : 32-2-650 65 16 > Fax : 32-2-650 50 92 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL: thomas.adams@noaa.gov VOICE: 937-383-0528 FAX: 937-383-0033 From mlennert at club.worldonline.be Mon Aug 7 15:38:51 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Aug 7 15:38:53 2006 Subject: [GRASS-dev] [Fwd: Grass cvs-6.1 very slow on imac intel] In-Reply-To: <44D7302A.8030108@noaa.gov> References: <56360.164.15.134.162.1154700400.squirrel@geog-pc40.ulb.ac.be> <44D7302A.8030108@noaa.gov> Message-ID: <44D7426B.4080903@club.worldonline.be> Thomas Adams wrote: > Didier, > > Which model iMac are you using; which CPU (Power PC G3, G4, G5, Intel??) > and what speed is the CPU? iMac Intel 1.83 Mhz, Core Duo, 1.5 Gb RAM. Moritz (as Didier is not on the list) > > Tom > > > > Moritz Lennert wrote: >> Maybe some other Mac users have something to say ? >> >> Moritz >> >> ---------------------------- Original Message >> ---------------------------- >> Subject: Grass cvs-6.1 very slow on imac intel >> From: "Didier Peeters" >> Date: Fri, August 4, 2006 14:32 >> To: lorenzo.moretti@bologna.enea.it >> Cc: "Moritz Lennert" >> -------------------------------------------------------------------------- >> >> >> Dear Lorenzo, >> >> Thank you for providing GRASS binaries for Mac OS X. I'm trying to >> use the last cvs 6.1 version downloaded from http:// >> wwwamb.bologna.enea.it/forgrass/downloadcvs.htm on an Imac with an >> Intel processor and it seems to be very slow, displaying a simple >> vector map takes about 20 seconds, which is far more slowly than on >> the Debian system of my colleague. Do you have any explanation for >> that ? Is this due to the Rosetta emulation ? >> >> Best wishes. >> >> Didier Peeters >> Institut de Gestion de l'Environnement et d'Am?nagement du Territoire >> Universit? Libre de Bruxelles >> CP246 - Acc?s 5 - Campus Plaine >> Boulevard du Triomphe >> B-1050 Bruxelles >> T?l : 32-2-650 65 16 >> Fax : 32-2-650 50 92 >> >> >> >> >> ------------------------------------------------------------------------ >> >> Dear Lorenzo, >> >> Thank you for providing GRASS binaries for Mac OS X. I'm trying to >> use the last cvs 6.1 version downloaded from >> http://wwwamb.bologna.enea.it/forgrass/downloadcvs.htm on an Imac with >> an Intel processor and it seems to be very slow, displaying a simple >> vector map takes about 20 seconds, which is far more slowly than on >> the Debian system of my colleague. Do you have any explanation for >> that ? Is this due to the Rosetta emulation ? >> >> Best wishes. >> >> Didier Peeters >> Institut de Gestion de l'Environnement et d'Am?nagement du Territoire >> Universit? Libre de Bruxelles >> CP246 - Acc?s 5 - Campus Plaine >> Boulevard du Triomphe >> B-1050 Bruxelles >> T?l : 32-2-650 65 16 >> Fax : 32-2-650 50 92 >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > > From ychemin at gmail.com Mon Aug 7 17:44:36 2006 From: ychemin at gmail.com (Yann Chemin) Date: Mon Aug 7 17:44:39 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> References: <20060804082947.GA6031@localdomain> <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> Message-ID: <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> Made some menus in the raster module, try them out... took me 10 minutes, quite easy. r.mapcalc bombs... but others work fine (did not try them all though). yann -------------- next part -------------- A non-text attachment was scrubbed... Name: gism.py Type: text/x-python Size: 17292 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060807/a1d0eefa/gism.py From Thomas.Adams at noaa.gov Mon Aug 7 17:46:40 2006 From: Thomas.Adams at noaa.gov (Thomas Adams) Date: Mon Aug 7 17:46:47 2006 Subject: [GRASS-dev] [Fwd: Grass cvs-6.1 very slow on imac intel] In-Reply-To: <44D7426B.4080903@club.worldonline.be> References: <56360.164.15.134.162.1154700400.squirrel@geog-pc40.ulb.ac.be> <44D7302A.8030108@noaa.gov> <44D7426B.4080903@club.worldonline.be> Message-ID: <44D76060.4090306@noaa.gov> Moritz, Running GRASS 6.1 CVS on a Dual 1.8 GHz G4 PowerPC (2.1 GB RAM) at home I have no problems such as those described. The redraw speeds are a little slower than on the Dual 2.4 GHz Intel/Linux machines at work. I have not quantified the speeds, however. I have noticed, however, that with the writing of the history information, redraw is noticeably slower with 6.1 than with 6.0.x with the new GIS manager (gis.m) Hope this helps! Cheers! Tom Moritz Lennert wrote: > Thomas Adams wrote: >> Didier, >> >> Which model iMac are you using; which CPU (Power PC G3, G4, G5, >> Intel??) and what speed is the CPU? > > iMac Intel 1.83 Mhz, Core Duo, 1.5 Gb RAM. > > Moritz > (as Didier is not on the list) > >> >> Tom >> >> >> >> Moritz Lennert wrote: >>> Maybe some other Mac users have something to say ? >>> >>> Moritz >>> >>> ---------------------------- Original Message >>> ---------------------------- >>> Subject: Grass cvs-6.1 very slow on imac intel >>> From: "Didier Peeters" >>> Date: Fri, August 4, 2006 14:32 >>> To: lorenzo.moretti@bologna.enea.it >>> Cc: "Moritz Lennert" >>> -------------------------------------------------------------------------- >>> >>> >>> Dear Lorenzo, >>> >>> Thank you for providing GRASS binaries for Mac OS X. I'm trying to >>> use the last cvs 6.1 version downloaded from http:// >>> wwwamb.bologna.enea.it/forgrass/downloadcvs.htm on an Imac with an >>> Intel processor and it seems to be very slow, displaying a simple >>> vector map takes about 20 seconds, which is far more slowly than on >>> the Debian system of my colleague. Do you have any explanation for >>> that ? Is this due to the Rosetta emulation ? >>> >>> Best wishes. >>> >>> Didier Peeters >>> Institut de Gestion de l'Environnement et d'Am?nagement du Territoire >>> Universit? Libre de Bruxelles >>> CP246 - Acc?s 5 - Campus Plaine >>> Boulevard du Triomphe >>> B-1050 Bruxelles >>> T?l : 32-2-650 65 16 >>> Fax : 32-2-650 50 92 >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> Dear Lorenzo, >>> >>> Thank you for providing GRASS binaries for Mac OS X. I'm trying to >>> use the last cvs 6.1 version downloaded from >>> http://wwwamb.bologna.enea.it/forgrass/downloadcvs.htm on an Imac >>> with an Intel processor and it seems to be very slow, displaying a >>> simple vector map takes about 20 seconds, which is far more slowly >>> than on the Debian system of my colleague. Do you have any >>> explanation for that ? Is this due to the Rosetta emulation ? >>> >>> Best wishes. >>> >>> Didier Peeters >>> Institut de Gestion de l'Environnement et d'Am?nagement du Territoire >>> Universit? Libre de Bruxelles >>> CP246 - Acc?s 5 - Campus Plaine >>> Boulevard du Triomphe >>> B-1050 Bruxelles >>> T?l : 32-2-650 65 16 >>> Fax : 32-2-650 50 92 >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev@grass.itc.it >>> http://grass.itc.it/mailman/listinfo/grass-dev >> >> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL: thomas.adams@noaa.gov VOICE: 937-383-0528 FAX: 937-383-0033 From michael.barton at asu.edu Mon Aug 7 19:18:43 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 7 19:18:56 2006 Subject: [GRASS-dev] Updates to gism.py - autogenerated gui for all commands. Message-ID: I just uploaded a new version of gism.py and related files. I'll keep an archive and so changed the link in the GRASS WIKI (development/python section) to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes: *The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands. This can now be called from the command console (just type in the command name with no arguments as you do now) or the prototype menus. I updated grassgui.py to current wxPython syntax (mostly ? event bindings need to change to new Bind method) and added methods to make it callable from other modules. I also added scroll bars. We need to add buttons (and relevant module or method like select.tcl) to browse GRASS ?elements? (i.e., rasters, vectors, files, etc.). Thanks very much to Yann Chemin for showing that grassgui.py worked. *Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac. *Change to subprocess module for running commands in the shell--seems to have stopped the double dialog boxes. Important things to do. I?d like to start thinking about moving this to the cvs so that we can work on it collaboratively in a more controlled way. It should go into the grass6/gui/wxpython folder in the cvs. In the compiled binary, I?m guessing that it should end up in its own directory (e.g., wxp or gmwxp) like gm and dm. But I have a BIG PROBLEM. I can?t get gism.py to run from another directory, even though python is in my path and runs fine. That is, when in my home directory, if I try to run... > pythonw $GISBASE/etc/wxp/gism.py ...my Mac crashes with a bus error?even though $GISBASE has a value and even when I expand it to type out the full path. I?ve tried setting $PYTHONPATH (i.e., for module search path) and it makes no difference. I don?t know whether this is a Mac problem, something weird with my system, or something I don?t know about yet with Python. Anyone have any thoughts? If this were fixed, we could easily make a script (e.g., gismpy) that could launch it from the GRASS command prompt. I can?t yet get d.* commands to work from the new autodialogs, but they work from the command line. It?s a parameter passing issue. Other commands seem to work fine. I think we?re ready to do the layer manager, layer options panels, and menu or toolbox. Michael __________________________________________ Michael Barton, Professor of Anthropology 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/20060807/a3bef944/attachment.html From michael.barton at asu.edu Mon Aug 7 19:22:46 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 7 19:22:56 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <44D3053F.7020402@club.worldonline.be> Message-ID: Moritz and Yann, I forgot to ask you. Are you using whatever came with Debian unstable, or did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) and wxPython 2.6.3.x? Image dragging works very smoothly on my Mac. How does resizing look? A buffered DC can be used to reduce flicker, but is a bit of a pain to implement. Need to know if it is needed on some systems or the problem is an issue of different versions of the software. Check out the new version I just uploaded. Cheers Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Moritz Lennert > Date: Fri, 04 Aug 2006 10:28:47 +0200 > To: Michael Barton > Cc: Grass Developers List , Jachym Cepicky > , Trevor Wiens , David > Finlayson > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > Panning however causes problems for me: > > - first the screen flashes very frequently while the map moves > - once the map is in its new position, I cannot use the mouse anymore, > only my keyboard. However, when I change to another workspace of my > Gnome desktop and then switch back again, the map display is empty, but > I can use my mouse again. From michael.barton at asu.edu Mon Aug 7 19:37:47 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 7 19:37:52 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> Message-ID: > Sorry it was a typo indeed, > grass-interface.dtd and grassgui.py are the two files to be copied > over to py_gm/ > Yes. I quickly found you you need grassgui.py and grassgui.dtd. Is the latter an xml schema??? > > Would it be possible to drop py_gm/ into grass6/gui/wxpython/ ? since > they both can interoperate, it should facilitate the temptation of a > python programmer to "plug" them together through the py_gm/ > buttons... See my post from today. I agree with putting this in that local. If there is general agreement, I can do so. But also see the problem I had with running it from something like $GISBASE/etc/wxp. Maybe you know what I am doing wrong there. I just did plug them together. Works pretty slick. > > Another thought, would it be interesting to develop a program to > convert the .tcl code into python interface? or is it better to recode > directly in Python? > For me at least, it is easier to just recode. But maybe someone out there is clever enough to do this. It would be a big time saver. Michael > > Yann > > On 05/08/06, Agustin Diez Castillo wrote: >> >> Do you mean grass-interface.dtd? I have no grass-interface.py >> >> >> >> grass6/gui/wxpython/grass-interface.py into py_gm/ from which you run >> >> __________________________________________ Michael Barton, Professor of Anthropology 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 Mon Aug 7 19:39:27 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 7 19:39:32 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> Message-ID: Yann, We need to merge this with the new version I just posted on the WIKI. Definitely need to move this into the CVS. Markus, procedure? Michale __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Mon, 7 Aug 2006 22:44:36 +0700 > To: Grass Developers List > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > Made some menus in the raster module, try them out... > took me 10 minutes, quite easy. > > r.mapcalc bombs... > but others work fine (did not try them all though). > > yann From grass-bugs at intevation.de Mon Aug 7 19:42:13 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Aug 7 19:42:18 2006 Subject: [GRASS-dev] [bug #4981] (grass) GRASS startup exited abnormally Message-ID: <20060807174213.C20081005A3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4981 ------------------------------------------------------------------------- Subject: GRASS startup exited abnormally Platform: WindowsNT/2000/XP grass obtained from: CVS grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.1.cvs (2006) Sorry about my question - I am a new user. I got the following messages while starting GRASS: Welcome to GRASS 6.1.cvs (2006) GRASS 6.1.cvs (2006) (spearfish60):~>Error in startup script:child process excited abnormally while executing "exec ps.map -p" (procedure "DmPrint::init" line 14) invoked from within "DmPrint::init" (procedure "main" line 34) invoked from within "main $argc $argv" file (/usr/local/grass6.1.cvs-i686-pc-cygwin-17_04_2006/etc/dm/d.m.tcl" line 1627) What I have done wrong? What can I do to solve my problem? Many thanks for your help in advance Best regards Peter -------------------------------------------- Managed by Request Tracker From ychemin at gmail.com Mon Aug 7 20:02:07 2006 From: ychemin at gmail.com (Yann Chemin) Date: Mon Aug 7 20:02:13 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> Message-ID: <6278879c0608071102q6ab66f0cx11223e73b037a5e5@mail.gmail.com> Hi, i just finished the whole raster module, here is the file attached, please try it. Few commands missing (remarked IN BOLD in the dialog). Looks quite nice. I am using python 2.4.3 on Mandriva 2007.0, not sure about wxpython. I am going to be busy up to next week, Yann On 08/08/06, Michael Barton wrote: > Yann, > > We need to merge this with the new version I just posted on the WIKI. > Definitely need to move this into the CVS. > > Markus, procedure? > > Michale > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Yann Chemin > > Date: Mon, 7 Aug 2006 22:44:36 +0700 > > To: Grass Developers List > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > > Made some menus in the raster module, try them out... > > took me 10 minutes, quite easy. > > > > r.mapcalc bombs... > > but others work fine (did not try them all though). > > > > yann > > -------------- next part -------------- A non-text attachment was scrubbed... Name: gism.py Type: text/x-python Size: 33865 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060808/d29b78f6/gism-0001.py From michael.barton at asu.edu Mon Aug 7 20:57:37 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 7 20:57:46 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608071102q6ab66f0cx11223e73b037a5e5@mail.gmail.com> Message-ID: Thanks very much! I'll try to merge this in over the next couple days and repost. We should probably move the menu definitions data object to a separate module, because it will get large. Also, it could then be used to transition all or part to a tool-box metaphor. Once I get the word that it's OK, I can go ahead and move this to the cvs for easier updates and versioning. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Tue, 8 Aug 2006 01:02:07 +0700 > To: Grass Developers List , Michael Barton > > Cc: Markus Neteler > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > Hi, i just finished the whole raster module, > here is the file attached, please try it. > Few commands missing (remarked IN BOLD in the dialog). > Looks quite nice. > > I am using python 2.4.3 on Mandriva 2007.0, not sure about wxpython. > > > I am going to be busy up to next week, > > Yann > > > On 08/08/06, Michael Barton wrote: >> Yann, >> >> We need to merge this with the new version I just posted on the WIKI. >> Definitely need to move this into the CVS. >> >> Markus, procedure? >> >> Michale >> __________________________________________ >> Michael Barton, Professor of Anthropology >> 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: Yann Chemin >>> Date: Mon, 7 Aug 2006 22:44:36 +0700 >>> To: Grass Developers List >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>> >>> Made some menus in the raster module, try them out... >>> took me 10 minutes, quite easy. >>> >>> r.mapcalc bombs... >>> but others work fine (did not try them all though). >>> >>> yann >> >> From ychemin at gmail.com Mon Aug 7 21:03:29 2006 From: ychemin at gmail.com (Yann Chemin) Date: Mon Aug 7 21:03:32 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <6278879c0608071102q6ab66f0cx11223e73b037a5e5@mail.gmail.com> Message-ID: <6278879c0608071203i6f00e764m33ae1a1484762199@mail.gmail.com> I'd like to think we can make a C code to automatically create a menu description file instead of making it by hand all the time. If you could separate it well from the other coding, it should make that task easier when we'll come to it. Additionally, since Python GUI does not need recompiling, it should then be possible to generate "flavors" of GRASS, i.e. for image processing or for GIS analysis, etc on the fly by modifying menu contents. Yann On 08/08/06, Michael Barton wrote: > Thanks very much! > > I'll try to merge this in over the next couple days and repost. We should > probably move the menu definitions data object to a separate module, because > it will get large. Also, it could then be used to transition all or part to > a tool-box metaphor. Once I get the word that it's OK, I can go ahead and > move this to the cvs for easier updates and versioning. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Yann Chemin > > Date: Tue, 8 Aug 2006 01:02:07 +0700 > > To: Grass Developers List , Michael Barton > > > > Cc: Markus Neteler > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > > Hi, i just finished the whole raster module, > > here is the file attached, please try it. > > Few commands missing (remarked IN BOLD in the dialog). > > Looks quite nice. > > > > I am using python 2.4.3 on Mandriva 2007.0, not sure about wxpython. > > > > > > I am going to be busy up to next week, > > > > Yann > > > > > > On 08/08/06, Michael Barton wrote: > >> Yann, > >> > >> We need to merge this with the new version I just posted on the WIKI. > >> Definitely need to move this into the CVS. > >> > >> Markus, procedure? > >> > >> Michale > >> __________________________________________ > >> Michael Barton, Professor of Anthropology > >> 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: Yann Chemin > >>> Date: Mon, 7 Aug 2006 22:44:36 +0700 > >>> To: Grass Developers List > >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > >>> > >>> Made some menus in the raster module, try them out... > >>> took me 10 minutes, quite easy. > >>> > >>> r.mapcalc bombs... > >>> but others work fine (did not try them all though). > >>> > >>> yann > >> > >> > > From neteler at itc.it Mon Aug 7 21:37:22 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Aug 7 21:37:24 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608071203i6f00e764m33ae1a1484762199@mail.gmail.com> References: <6278879c0608071102q6ab66f0cx11223e73b037a5e5@mail.gmail.com> <6278879c0608071203i6f00e764m33ae1a1484762199@mail.gmail.com> Message-ID: <20060807193721.GB7943@bartok.itc.it> On Tue, Aug 08, 2006 at 02:03:29AM +0700, Yann Chemin wrote: > I'd like to think we can make a C code to automatically create a menu > description file instead of making it by hand all the time. If you > could separate it well from the other coding, it should make that task > easier when we'll come to it. > > > Additionally, since Python GUI does not need recompiling, it should > then be possible to generate "flavors" of GRASS, i.e. for image > processing or for GIS analysis, etc on the fly by modifying menu > contents. > > Yann I was always thinking of having a "keyword" section in the module/manual. Like this commands could be easily grouped (searched). Probably this could be also used for autogenerating such dedicated menus more easily. Markus From glynn at gclements.plus.com Mon Aug 7 21:39:18 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 7 21:40:32 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <44D6F7FF.3070409@club.worldonline.be> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> Message-ID: <17623.38630.975948.118205@cerise.gclements.plus.com> Moritz Lennert wrote: > >>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules > >>> work without X11 or there is a TclTk replacement for critical modules. > >>> v.digit is the only major exception now. NVIZ without X11 may still be in > >>> transition. It still has problems on Intel Macs and I'm not sure about where > >>> it is for Windows. > > Using the grass-cvs binaries from http://geni.ath.cx/grass.html which > according to the web page date from April 17, 2006, even the gis.m seems > to use X. At least, there is a large X in the top left of all the > windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat) > starts Xwin and then launches an xterm within that Xwin session. > > So, how can I use the guis without X ? 1. Download the Tcl/Tk source code, and compile it. You might be able to use the ActiveState Tcl/Tk package for gis.m, although I haven't tried it. It's less likely that it would work with NVIZ. Cygwin's Tcl/Tk *definitely* won't work with GRASS, due to the way it handles filenames. 2. Download the GRASS source code, and compile it. -- Glynn Clements From ychemin at gmail.com Mon Aug 7 21:42:32 2006 From: ychemin at gmail.com (Yann Chemin) Date: Mon Aug 7 21:42:33 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <20060807193721.GB7943@bartok.itc.it> References: <6278879c0608071102q6ab66f0cx11223e73b037a5e5@mail.gmail.com> <6278879c0608071203i6f00e764m33ae1a1484762199@mail.gmail.com> <20060807193721.GB7943@bartok.itc.it> Message-ID: <6278879c0608071242i672b2c3eyfbcdf6ae451883fd@mail.gmail.com> On 08/08/06, Markus Neteler wrote: > On Tue, Aug 08, 2006 at 02:03:29AM +0700, Yann Chemin wrote: > > I'd like to think we can make a C code to automatically create a menu > > description file instead of making it by hand all the time. If you > > could separate it well from the other coding, it should make that task > > easier when we'll come to it. > > > > > > Additionally, since Python GUI does not need recompiling, it should > > then be possible to generate "flavors" of GRASS, i.e. for image > > processing or for GIS analysis, etc on the fly by modifying menu > > contents. > > > > Yann > > I was always thinking of having a "keyword" section in the module/manual. > Like this commands could be easily grouped (searched). Probably this > could be also used for autogenerating such dedicated menus more easily. > > Markus Yes, i guess you put a structure to that thing that was tickling my brain. It should be possible to use such a feature to make autogeneration of menus... If this could be started somehow it should be beneficial in the longer term. Yann From glynn at gclements.plus.com Mon Aug 7 21:45:46 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 7 21:45:50 2006 Subject: [GRASS-dev] GRASS C function names In-Reply-To: <200608071245.18383.soerengebbert@gmx.de> References: <200608071245.18383.soerengebbert@gmx.de> Message-ID: <17623.39018.604382.803737@cerise.gclements.plus.com> Soeren Gebbert wrote: > i have a question about the function naming guidline of GRASS. > I would like to add a guidline to the SUBMITTING file. > > But the problem is that we have two naming conventions > for library functions in GRASS. > The common convention is: G_fatal_error(), to place a "_" between the function description strings, > but within the G3D library a different convention was used: G3d_fatalError(). > > Personally i like the function name convention of the G3D lib, because this > convention is used in other libraries i am programming with and i think its better readable. > So i named all the functions in my r3.* modules like the G3D lib standard. > > But i would like to see a uniform programming standard/API within GRASS, so what to do? > > Should the G3D library API be an exception and all the user defined function names should use > the common API (G_name_name), or should the module developer decide on his own what convention to use? All of the core libraries use underscores rather than mixed case. The only libraries which use mixed case are third-party add-ons which were developed separately then incorporated into GRASS later. FWIW, I strongly prefer underscores; it's also the official GNU naming convention. > Or should we/i rename all G3D function names to meet the common convention? > Well thats not impossible, but a huge amount of work (the testing and the docs). I don't consider renaming to be a priority. It might be worth doing if the library was undergoing a major overhaul, but otherwise there are better uses of developer time. -- Glynn Clements From glynn at gclements.plus.com Mon Aug 7 21:58:04 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Aug 7 21:58:09 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> References: <20060804082947.GA6031@localdomain> <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> Message-ID: <17623.39756.932838.514987@cerise.gclements.plus.com> Yann Chemin wrote: > r.mapcalc bombs... r.mapcalc doesn't use G_parser(); anything other than "help" or "--help" will be parsed as an expression. -- Glynn Clements From grass4u at gmail.com Mon Aug 7 23:03:01 2006 From: grass4u at gmail.com (Huidae Cho) Date: Mon Aug 7 23:03:38 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17623.38630.975948.118205@cerise.gclements.plus.com> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> <17623.38630.975948.118205@cerise.gclements.plus.com> Message-ID: <20060807210300.GA25702@localhost> I found the latest CVS version does not compile under the last week's Cygwin for some reasons. Maybe this problem has to do with the way of building DLLs. Has anyone tried to compile CVS sources under Cygwin? Huidae Cho On Mon, Aug 07, 2006 at 08:39:18PM +0100, Glynn Clements wrote: > > Moritz Lennert wrote: > > > >>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules > > >>> work without X11 or there is a TclTk replacement for critical modules. > > >>> v.digit is the only major exception now. NVIZ without X11 may still be in > > >>> transition. It still has problems on Intel Macs and I'm not sure about where > > >>> it is for Windows. > > > > Using the grass-cvs binaries from http://geni.ath.cx/grass.html which > > according to the web page date from April 17, 2006, even the gis.m seems > > to use X. At least, there is a large X in the top left of all the > > windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat) > > starts Xwin and then launches an xterm within that Xwin session. > > > > So, how can I use the guis without X ? > > 1. Download the Tcl/Tk source code, and compile it. You might be able > to use the ActiveState Tcl/Tk package for gis.m, although I haven't > tried it. It's less likely that it would work with NVIZ. Cygwin's > Tcl/Tk *definitely* won't work with GRASS, due to the way it handles > filenames. > > 2. Download the GRASS source code, and compile it. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From patricioantoniotoledo at gmail.com Mon Aug 7 23:04:05 2006 From: patricioantoniotoledo at gmail.com (=?ISO-8859-1?Q?Patricio_Antonio_Toledo_Pe=F1a?=) Date: Mon Aug 7 23:04:08 2006 Subject: [GRASS-dev] A few ideas about development tools... In-Reply-To: <20060804084210.GI30796@bartok.itc.it> References: <20060804084210.GI30796@bartok.itc.it> Message-ID: GRASS developers should consider also the use of GIT, the content tracker currently in use by the Linux kernel community. Currently the Xorg source code is managed with git also. Indeed i am tracking the CVS repository with GIT in my laptop, and there is no pain at all. Take a look at: http://www.kernel.org/pub/software/scm/git/docs/ http://www.kernel.org/pub/software/scm/cogito/README And the CVS migration http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html Of course is packaged in debian http://packages.debian.org/unstable/devel/git-core Best Regards 2006/8/4, Markus Neteler : > > On Thu, Aug 03, 2006 at 01:13:22PM +0200, Francesco P. Lovergine wrote: > > Markus asked me to report the list about some ideas I have... > > > > Well, a CVS repo could be easily converted to a SVN one by cvs2svn, > subversion > > is currently the mainstream for a cetralized SCM. Honestly, CVS has > > a series of defects for management, maybe it's time to use a more > > advanced tool, without loosing past history. > > Yes, I agree. I have recently migrated my own CVS (was running > for several years and quite fat) to SVN with cvs2svn. No big deal. > > SVN would finally offer the possibility to create a GRASS Addon > repository with granular access rights. > > > It is also well integrated > > with Trac which is a very nice bug tracker in respect with WebRT. That > > could be a major pain for migration, anyway. > > RT is pretty limited. We observe that developers don't like/use it. > This is obviously bad. In particular, the lack of patch support > (which is nice in trac) is a major pain. > > > Ideas? > > The OSGeo foundation considers to offer SVN/trac etc support for > foundation projects. This could be interesting since moving bugs > among projects will (hopefully) be possible. Example: if an apparent > GRASS bug turns out to be a GDAL bug, we just move it there. No need > to write everything again. Also code leverage will be simplified > (no need to reinvent the wheel for many GIS tasks given the same > programming language is used). > > > PS: did the Google Summer of Code be considered for sponsored students > > efforts about grass activities? I think grass is eligible as mentor for > > that... The new year is not so far, indeed :) > > Good point! > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Patricio Toledo Pe?a Dpto. de Geof?sica - Universidad de Chile Blanco Encalada 2002-Casilla 2777 Santiago-Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20060807/209fd0b3/attachment-0001.html From michael.barton at asu.edu Mon Aug 7 23:13:51 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 7 23:13:58 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608071203i6f00e764m33ae1a1484762199@mail.gmail.com> Message-ID: > > I'd like to think we can make a C code to automatically create a menu > description file instead of making it by hand all the time. If you > could separate it well from the other coding, it should make that task > easier when we'll come to it. Making the description file should be fairly easy. It could even be done in Python, using the xml output from [grass-command] --interface-description. The complicating factor is where to put each menu item in some kind of a meaningful arrangement. The latter probably needs to be human organized to work best. However, it could perhaps be semi-automated if we could make some kind of organized menu template (xml file?) by hand and an automated procedure could fill in the gory details. > > > Additionally, since Python GUI does not need recompiling, it should > then be possible to generate "flavors" of GRASS, i.e. for image > processing or for GIS analysis, etc on the fly by modifying menu > contents. Yes. But I'm betting that most people will want it all. Michael __________________________________________ Michael Barton, Professor of Anthropology 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 Mon Aug 7 23:17:19 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Aug 7 23:17:24 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <20060807193721.GB7943@bartok.itc.it> Message-ID: Agreeing with Yann, some kind of well-thought-out keyword structure could be the basis for automatic menu generation at compile time or even runtime. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Markus Neteler > Date: Mon, 7 Aug 2006 21:37:22 +0200 > To: Grass Developers List > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > On Tue, Aug 08, 2006 at 02:03:29AM +0700, Yann Chemin wrote: >> I'd like to think we can make a C code to automatically create a menu >> description file instead of making it by hand all the time. If you >> could separate it well from the other coding, it should make that task >> easier when we'll come to it. >> >> >> Additionally, since Python GUI does not need recompiling, it should >> then be possible to generate "flavors" of GRASS, i.e. for image >> processing or for GIS analysis, etc on the fly by modifying menu >> contents. >> >> Yann > > I was always thinking of having a "keyword" section in the module/manual. > Like this commands could be easily grouped (searched). Probably this > could be also used for autogenerating such dedicated menus more easily. > > Markus > > From ychemin at gmail.com Mon Aug 7 23:27:24 2006 From: ychemin at gmail.com (Yann Chemin) Date: Mon Aug 7 23:27:27 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <6278879c0608071203i6f00e764m33ae1a1484762199@mail.gmail.com> Message-ID: <6278879c0608071427t145c26feuf1f80ba1e5072c28@mail.gmail.com> On 08/08/06, Michael Barton wrote: > > > > > > I'd like to think we can make a C code to automatically create a menu > > description file instead of making it by hand all the time. If you > > could separate it well from the other coding, it should make that task > > easier when we'll come to it. > > Making the description file should be fairly easy. It could even be done in > Python, using the xml output from [grass-command] --interface-description. > The complicating factor is where to put each menu item in some kind of a > meaningful arrangement. The latter probably needs to be human organized to > work best. However, it could perhaps be semi-automated if we could make some > kind of organized menu template (xml file?) by hand and an automated > procedure could fill in the gory details. > Yes, something like this, a kind of meta-level. Think about hydrological related modules could be self identified by the internal description or keywords that Markus mentioned. Then you could "switch on" this group, then all modules answering to the call could be grouped into the same dialog and it could then be available at a higher place (i.e. very visible) in the GUI layout. > > > > > > Additionally, since Python GUI does not need recompiling, it should > > then be possible to generate "flavors" of GRASS, i.e. for image > > processing or for GIS analysis, etc on the fly by modifying menu > > contents. > > Yes. But I'm betting that most people will want it all. Yes they want it all, but they also want to find easily what they use more commonly, i guess all can be there at all times, it is just how the users choose the visibility of their "pet" groups of modules/submodules/specific functions. :-) (head-scratching ...) > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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 Tue Aug 8 00:02:45 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 8 00:02:56 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608071102q6ab66f0cx11223e73b037a5e5@mail.gmail.com> Message-ID: Yann, I just added in your raster menu items. It looks very impressive. I updated the package and posted on the WIKI again. We've got to move the menu to another file, however, before it grows enormous. Thanks again Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Tue, 8 Aug 2006 01:02:07 +0700 > To: Grass Developers List , Michael Barton > > Cc: Markus Neteler > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > Hi, i just finished the whole raster module, > here is the file attached, please try it. > Few commands missing (remarked IN BOLD in the dialog). > Looks quite nice. > > I am using python 2.4.3 on Mandriva 2007.0, not sure about wxpython. > > > I am going to be busy up to next week, > > Yann > > > On 08/08/06, Michael Barton wrote: >> Yann, >> >> We need to merge this with the new version I just posted on the WIKI. >> Definitely need to move this into the CVS. >> >> Markus, procedure? >> >> Michale >> __________________________________________ >> Michael Barton, Professor of Anthropology >> 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: Yann Chemin >>> Date: Mon, 7 Aug 2006 22:44:36 +0700 >>> To: Grass Developers List >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>> >>> Made some menus in the raster module, try them out... >>> took me 10 minutes, quite easy. >>> >>> r.mapcalc bombs... >>> but others work fine (did not try them all though). >>> >>> yann >> >> From michael.barton at asu.edu Tue Aug 8 00:14:02 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 8 00:14:09 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608071427t145c26feuf1f80ba1e5072c28@mail.gmail.com> Message-ID: Yann, Just tried your menu in more detail. You no longer have to add the --interface-description | python grassgui.py after each command. Just put in the command. gism.py and the command parser does the rest. I uploaded it again with this fixed. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Tue, 8 Aug 2006 04:27:24 +0700 > To: Michael Barton > Cc: Grass Developers List , Markus Neteler > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > On 08/08/06, Michael Barton wrote: >> >> >>> >>> I'd like to think we can make a C code to automatically create a menu >>> description file instead of making it by hand all the time. If you >>> could separate it well from the other coding, it should make that task >>> easier when we'll come to it. >> >> Making the description file should be fairly easy. It could even be done in >> Python, using the xml output from [grass-command] --interface-description. >> The complicating factor is where to put each menu item in some kind of a >> meaningful arrangement. The latter probably needs to be human organized to >> work best. However, it could perhaps be semi-automated if we could make some >> kind of organized menu template (xml file?) by hand and an automated >> procedure could fill in the gory details. >> > Yes, something like this, a kind of meta-level. Think about > hydrological related modules could be self identified by the internal > description or keywords that Markus mentioned. Then you could "switch > on" this group, then all modules answering to the call could be > grouped into the same dialog and it could then be available at a > higher place (i.e. very visible) in the GUI layout. >>> >>> >>> Additionally, since Python GUI does not need recompiling, it should >>> then be possible to generate "flavors" of GRASS, i.e. for image >>> processing or for GIS analysis, etc on the fly by modifying menu >>> contents. >> >> Yes. But I'm betting that most people will want it all. > > Yes they want it all, but they also want to find easily what they use > more commonly, i guess all can be there at all times, it is just how > the users choose the visibility of their "pet" groups of > modules/submodules/specific functions. > :-) (head-scratching ...) >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> 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 ychemin at gmail.com Tue Aug 8 00:33:47 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 00:33:50 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <6278879c0608071427t145c26feuf1f80ba1e5072c28@mail.gmail.com> Message-ID: <6278879c0608071533q679c4032s549c9e721911279a@mail.gmail.com> Thanks Michael, :-) Looks good! On 08/08/06, Michael Barton wrote: > Yann, > > Just tried your menu in more detail. You no longer have to add the > --interface-description | python grassgui.py after each command. Just put in > the command. gism.py and the command parser does the rest. > > I uploaded it again with this fixed. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Yann Chemin > > Date: Tue, 8 Aug 2006 04:27:24 +0700 > > To: Michael Barton > > Cc: Grass Developers List , Markus Neteler > > > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > > On 08/08/06, Michael Barton wrote: > >> > >> > >>> > >>> I'd like to think we can make a C code to automatically create a menu > >>> description file instead of making it by hand all the time. If you > >>> could separate it well from the other coding, it should make that task > >>> easier when we'll come to it. > >> > >> Making the description file should be fairly easy. It could even be done in > >> Python, using the xml output from [grass-command] --interface-description. > >> The complicating factor is where to put each menu item in some kind of a > >> meaningful arrangement. The latter probably needs to be human organized to > >> work best. However, it could perhaps be semi-automated if we could make some > >> kind of organized menu template (xml file?) by hand and an automated > >> procedure could fill in the gory details. > >> > > Yes, something like this, a kind of meta-level. Think about > > hydrological related modules could be self identified by the internal > > description or keywords that Markus mentioned. Then you could "switch > > on" this group, then all modules answering to the call could be > > grouped into the same dialog and it could then be available at a > > higher place (i.e. very visible) in the GUI layout. > >>> > >>> > >>> Additionally, since Python GUI does not need recompiling, it should > >>> then be possible to generate "flavors" of GRASS, i.e. for image > >>> processing or for GIS analysis, etc on the fly by modifying menu > >>> contents. > >> > >> Yes. But I'm betting that most people will want it all. > > > > Yes they want it all, but they also want to find easily what they use > > more commonly, i guess all can be there at all times, it is just how > > the users choose the visibility of their "pet" groups of > > modules/submodules/specific functions. > > :-) (head-scratching ...) > >> > >> Michael > >> __________________________________________ > >> Michael Barton, Professor of Anthropology > >> 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 grass4u at gmail.com Tue Aug 8 01:43:47 2006 From: grass4u at gmail.com (Huidae Cho) Date: Tue Aug 8 01:44:33 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17620.59460.354001.833248@cerise.gclements.plus.com> References: <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.52951.348154.527585@cerise.gclements.plus.com> <17620.59460.354001.833248@cerise.gclements.plus.com> Message-ID: <20060807234347.GA51489@localhost.tamu.edu> On Sat, Aug 05, 2006 at 07:49:40PM +0100, Glynn Clements wrote: > > Glynn Clements wrote: > > > > > Executing external programs (e.g. using g.list to generate a list of > > > > maps) doesn't work. The actual OpenGL rendering works fine. > > > > > > This bombs in the prototype wxPython UI too. Is this somehow different from > > > other GRASS modules? > > > > Oops. The NVIZ map browser uses "ls", not g.list. > > But that's irrelevant; it was getting stuck on calling g.gisenv to get > GISDBASE etc. I've discovered that it seems to blocking on stdin; > pressing Return in the terminal allows it to continue, until the next > exec. Furthermore, running nviz as "nviz ... the problem. However, putting a redirection in the exec command itself > doesn't help. > > Another major problem with MSys is that it uses its own virtual > filesystem rooted at e.g. c:/msys/1.0. The shell takes care of > translating command-line arguments, but this causes problems with > scripts which write pathnames to files. E.g. etc/Init.sh sets GISDBASE > in $GISRC to an MSys pathname (e.g. /home/glynn/grass-data) while the > executables (being native Windows programs) need the real pathname > (e.g. c:/msys/1.0/home/glynn/grass-data). Windows path name conflicts with the ":" path separator used in many shell scripts. Is the native Windows version of GRASS supposed to run only under MSys? If so, we can add /c/msys/1.0 prefix to all path names stored in GISRC. I think it's reasonable to require MSys to run GRASS on Windows. Huidae Cho > > I suspect that we'll need to replace Init.sh with a .bat/.cmd file for > Windows. Either that, or find a shell which doesn't mess around with > filenames. > > I'm not sure how this will affect other shell scripts. MSys' bash can > recognise Windows pathnames, and doesn't attempt to translate them, so > using e.g. GISDBASE=`g.gisenv GISDBASE` shouldn't be a problem. I > don't know whether any other scripts write pathnames to files, though. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Tue Aug 8 01:59:19 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 02:00:17 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <20060807210300.GA25702@localhost> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> <17623.38630.975948.118205@cerise.gclements.plus.com> <20060807210300.GA25702@localhost> Message-ID: <17623.54231.988479.503249@cerise.gclements.plus.com> Huidae Cho wrote: > I found the latest CVS version does not compile under the last week's > Cygwin for some reasons. Maybe this problem has to do with the way of > building DLLs. Has anyone tried to compile CVS sources under Cygwin? Yes. The --enable-shared stopped working after upgrading Cygwin. The DLLs are built, the programs are built against them, but trying to run a program results in nothing happening (no errors). Running the program via gdb/strace results in a segfault. AFAICT, this is a Cygwin issue. As it affects all programs, the only GRASS changes to affect it would have to be related to libgis or the build system, and I can't see anything suspicious in that area. -- Glynn Clements From ychemin at gmail.com Tue Aug 8 03:28:30 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 03:28:33 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <17623.54892.25909.47549@cerise.gclements.plus.com> References: <20060804082947.GA6031@localdomain> <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> <17623.39756.932838.514987@cerise.gclements.plus.com> <6278879c0608071314x4cee441sd51478c4bebaf060@mail.gmail.com> <17623.54892.25909.47549@cerise.gclements.plus.com> Message-ID: <6278879c0608071828i4d3a6bf8m2f5251b195ca138b@mail.gmail.com> Hello Glynn, Sorry to ask this new bie question, but you mean that the front-end should be a file called from the GUI and this front-end will somehow launch r.mapcalc, don't you? thanks, Yann On 08/08/06, Glynn Clements wrote: > > Yann Chemin wrote: > > > > r.mapcalc doesn't use G_parser(); anything other than "help" or > > > "--help" will be parsed as an expression. > > > > by removing "--interface-description | python grassguy.py" and just > > calling r.mapcalc, then the terminal from which we launched "python > > gism.py" gets the r.mapcalc session opened. > > > > There must be a way to (at least) make it run from the GUI integrated CLI. > > Write a front-end script, e.g.: > > #!/bin/bash > #%Module > #% description: r.mapcalc - Raster map layer data calculator > #%End > #%option > #% key: expression > #% type: string > #% description: mapcalc expression > #% required : yes > #%end > > if [ "$1" != "@ARGS_PARSED@" ] > then > exec g.parser "$0" "$@" > fi > > exec r.mapcalc "$GIS_OPT_EXPRESSION" > > Changing r.mapcalc itself to use G_parser() isn't practical. > > -- > Glynn Clements > From glynn at gclements.plus.com Tue Aug 8 04:05:08 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 04:05:15 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608071828i4d3a6bf8m2f5251b195ca138b@mail.gmail.com> References: <20060804082947.GA6031@localdomain> <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> <17623.39756.932838.514987@cerise.gclements.plus.com> <6278879c0608071314x4cee441sd51478c4bebaf060@mail.gmail.com> <17623.54892.25909.47549@cerise.gclements.plus.com> <6278879c0608071828i4d3a6bf8m2f5251b195ca138b@mail.gmail.com> Message-ID: <17623.61780.399268.780334@cerise.gclements.plus.com> Yann Chemin wrote: > Sorry to ask this new bie question, but you mean that the front-end > should be a file called from the GUI and this front-end will somehow > launch r.mapcalc, don't you? Yes. The front-end would be a g.parser script with one option, expression=, and it would invoke r.mapcalc on that expression. Unlike r.mapcalc, a script which uses g.parser will accept all G_parser() options, e.g. --interface-description. -- Glynn Clements From ychemin at gmail.com Tue Aug 8 04:07:39 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 04:07:41 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <17623.61780.399268.780334@cerise.gclements.plus.com> References: <20060804082947.GA6031@localdomain> <6278879c0608050012m1ada36efv3b138fdfde8f8cd4@mail.gmail.com> <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> <17623.39756.932838.514987@cerise.gclements.plus.com> <6278879c0608071314x4cee441sd51478c4bebaf060@mail.gmail.com> <17623.54892.25909.47549@cerise.gclements.plus.com> <6278879c0608071828i4d3a6bf8m2f5251b195ca138b@mail.gmail.com> <17623.61780.399268.780334@cerise.gclements.plus.com> Message-ID: <6278879c0608071907v31980ec1l1b02b46de2807ae3@mail.gmail.com> nice! ok, i'll try. thanks, Yann On 08/08/06, Glynn Clements wrote: > > Yann Chemin wrote: > > > Sorry to ask this new bie question, but you mean that the front-end > > should be a file called from the GUI and this front-end will somehow > > launch r.mapcalc, don't you? > > Yes. The front-end would be a g.parser script with one option, > expression=, and it would invoke r.mapcalc on that expression. > > Unlike r.mapcalc, a script which uses g.parser will accept all > G_parser() options, e.g. --interface-description. > > -- > Glynn Clements > From glynn at gclements.plus.com Tue Aug 8 04:20:16 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 04:21:35 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <20060807234347.GA51489@localhost.tamu.edu> References: <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.52951.348154.527585@cerise.gclements.plus.com> <17620.59460.354001.833248@cerise.gclements.plus.com> <20060807234347.GA51489@localhost.tamu.edu> Message-ID: <17623.62688.894218.222409@cerise.gclements.plus.com> Huidae Cho wrote: > > > > > Executing external programs (e.g. using g.list to generate a list of > > > > > maps) doesn't work. The actual OpenGL rendering works fine. > > > > > > > > This bombs in the prototype wxPython UI too. Is this somehow different from > > > > other GRASS modules? > > > > > > Oops. The NVIZ map browser uses "ls", not g.list. > > > > But that's irrelevant; it was getting stuck on calling g.gisenv to get > > GISDBASE etc. I've discovered that it seems to blocking on stdin; > > pressing Return in the terminal allows it to continue, until the next > > exec. Furthermore, running nviz as "nviz ... > the problem. However, putting a redirection in the exec command itself > > doesn't help. > > > > Another major problem with MSys is that it uses its own virtual > > filesystem rooted at e.g. c:/msys/1.0. The shell takes care of > > translating command-line arguments, but this causes problems with > > scripts which write pathnames to files. E.g. etc/Init.sh sets GISDBASE > > in $GISRC to an MSys pathname (e.g. /home/glynn/grass-data) while the > > executables (being native Windows programs) need the real pathname > > (e.g. c:/msys/1.0/home/glynn/grass-data). > > Windows path name conflicts with the ":" path separator used in many > shell scripts. Is the native Windows version of GRASS supposed to run only > under MSys? If so, we can add /c/msys/1.0 prefix to all path names > stored in GISRC. It would have to be c:/msys/1.0; the /c/ syntax won't work with MSVCRT functions (open() etc). The main question is: in how many different places does this issue arise? If it's just Init.sh, we can add a hack for MSys. If it's going to keep cropping up, we need a more general solution. -- Glynn Clements From ychemin at gmail.com Tue Aug 8 04:21:48 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 04:21:50 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608071907v31980ec1l1b02b46de2807ae3@mail.gmail.com> References: <20060804082947.GA6031@localdomain> <07134C7B-C2BC-4C69-B04D-124FACA90785@uv.es> <6278879c0608062039o53034c14g7639657ee30f03ca@mail.gmail.com> <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> <17623.39756.932838.514987@cerise.gclements.plus.com> <6278879c0608071314x4cee441sd51478c4bebaf060@mail.gmail.com> <17623.54892.25909.47549@cerise.gclements.plus.com> <6278879c0608071828i4d3a6bf8m2f5251b195ca138b@mail.gmail.com> <17623.61780.399268.780334@cerise.gclements.plus.com> <6278879c0608071907v31980ec1l1b02b46de2807ae3@mail.gmail.com> Message-ID: <6278879c0608071921k2f676706ybaa85ac38222431d@mail.gmail.com> Thanks Glynn ! It works well. here are the modifications: in gism.py replace: ("Map calculator", "Map calculator", self.runMenuCmd, "r.mapcalc"), with this: ("Map calculator", "Map calculator", self.runMenuCmd, "mapcalc_gparser.sh"), and add the Glynn file attached (mapcalc_gparser.sh) to the py_gm directory. it opens a r.mapcalc dialog box where one can enter equations. :-) Yann On 08/08/06, Yann Chemin wrote: > nice! > > ok, i'll try. > > thanks, > Yann > > On 08/08/06, Glynn Clements wrote: > > > > Yann Chemin wrote: > > > > > Sorry to ask this new bie question, but you mean that the front-end > > > should be a file called from the GUI and this front-end will somehow > > > launch r.mapcalc, don't you? > > > > Yes. The front-end would be a g.parser script with one option, > > expression=, and it would invoke r.mapcalc on that expression. > > > > Unlike r.mapcalc, a script which uses g.parser will accept all > > G_parser() options, e.g. --interface-description. > > > > -- > > Glynn Clements > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: mapcalc_gparser.sh Type: application/x-sh Size: 295 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060808/8653a5f6/mapcalc_gparser.sh From grass4u at gmail.com Tue Aug 8 04:21:55 2006 From: grass4u at gmail.com (Huidae Cho) Date: Tue Aug 8 04:22:30 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17623.54231.988479.503249@cerise.gclements.plus.com> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> <17623.38630.975948.118205@cerise.gclements.plus.com> <20060807210300.GA25702@localhost> <17623.54231.988479.503249@cerise.gclements.plus.com> Message-ID: <20060808022155.GA78791@localhost.tamu.edu> (cd grass6 && make) stops at lib/vector/diglib when executing the test program. It seems like it takes forever for executables to find DLL exported symbols such as dig_set_cur_port(). It just stops there and holds terminal. Killing the process four times in the Task Manager actually stops it, but it happens again at some point (maybe it's libgrass_dig again). Huidae Cho On Tue, Aug 08, 2006 at 12:59:19AM +0100, Glynn Clements wrote: > > Huidae Cho wrote: > > > I found the latest CVS version does not compile under the last week's > > Cygwin for some reasons. Maybe this problem has to do with the way of > > building DLLs. Has anyone tried to compile CVS sources under Cygwin? > > Yes. The --enable-shared stopped working after upgrading Cygwin. The > DLLs are built, the programs are built against them, but trying to run > a program results in nothing happening (no errors). Running the > program via gdb/strace results in a segfault. > > AFAICT, this is a Cygwin issue. As it affects all programs, the only > GRASS changes to affect it would have to be related to libgis or the > build system, and I can't see anything suspicious in that area. > > -- > Glynn Clements From grass4u at gmail.com Tue Aug 8 05:24:56 2006 From: grass4u at gmail.com (Huidae Cho) Date: Tue Aug 8 05:25:31 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17623.62688.894218.222409@cerise.gclements.plus.com> References: <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.52951.348154.527585@cerise.gclements.plus.com> <17620.59460.354001.833248@cerise.gclements.plus.com> <20060807234347.GA51489@localhost.tamu.edu> <17623.62688.894218.222409@cerise.gclements.plus.com> Message-ID: <20060808032456.GA78963@localhost.tamu.edu> On Tue, Aug 08, 2006 at 03:20:16AM +0100, Glynn Clements wrote: > > Huidae Cho wrote: > > > > > > > Executing external programs (e.g. using g.list to generate a list of > > > > > > maps) doesn't work. The actual OpenGL rendering works fine. > > > > > > > > > > This bombs in the prototype wxPython UI too. Is this somehow different from > > > > > other GRASS modules? > > > > > > > > Oops. The NVIZ map browser uses "ls", not g.list. > > > > > > But that's irrelevant; it was getting stuck on calling g.gisenv to get > > > GISDBASE etc. I've discovered that it seems to blocking on stdin; > > > pressing Return in the terminal allows it to continue, until the next > > > exec. Furthermore, running nviz as "nviz ... > > the problem. However, putting a redirection in the exec command itself > > > doesn't help. > > > > > > Another major problem with MSys is that it uses its own virtual > > > filesystem rooted at e.g. c:/msys/1.0. The shell takes care of > > > translating command-line arguments, but this causes problems with > > > scripts which write pathnames to files. E.g. etc/Init.sh sets GISDBASE > > > in $GISRC to an MSys pathname (e.g. /home/glynn/grass-data) while the > > > executables (being native Windows programs) need the real pathname > > > (e.g. c:/msys/1.0/home/glynn/grass-data). > > > > Windows path name conflicts with the ":" path separator used in many > > shell scripts. Is the native Windows version of GRASS supposed to run only > > under MSys? If so, we can add /c/msys/1.0 prefix to all path names > > stored in GISRC. > > It would have to be c:/msys/1.0; the /c/ syntax won't work with > MSVCRT functions (open() etc). You're right. I overlooked that only c:/ is working with MSVCRT. > > The main question is: in how many different places does this issue > arise? If it's just Init.sh, we can add a hack for MSys. If it's going > to keep cropping up, we need a more general solution. Another problem is with the path separator. PATH="c:/msys/1.0/.../grass/bin" does not work since it's translated to PATH="c;c:\msys\1.0\msys\1.0\...\grass\bin". MSVCRT functions use the c:/msys/1.0 syntax, but once modules are compiled, they need PATH=/c/msys/1.0 to find DLLs. What I'm thinking is that everything can be done with the c:/msys/1.0 syntax including file I/O, but paths need to be converted to the /c/msys/1.0 syntax whenever they are exported with putenv(). Huidae Cho > > -- > Glynn Clements From ychemin at gmail.com Tue Aug 8 05:54:10 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 05:54:13 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608071931j6b5005a3wef3a9652501778a3@mail.gmail.com> References: <20060804082947.GA6031@localdomain> <6278879c0608070844q1731f5dgd79b53f49881ac9e@mail.gmail.com> <17623.39756.932838.514987@cerise.gclements.plus.com> <6278879c0608071314x4cee441sd51478c4bebaf060@mail.gmail.com> <17623.54892.25909.47549@cerise.gclements.plus.com> <6278879c0608071828i4d3a6bf8m2f5251b195ca138b@mail.gmail.com> <17623.61780.399268.780334@cerise.gclements.plus.com> <6278879c0608071907v31980ec1l1b02b46de2807ae3@mail.gmail.com> <6278879c0608071921k2f676706ybaa85ac38222431d@mail.gmail.com> <6278879c0608071931j6b5005a3wef3a9652501778a3@mail.gmail.com> Message-ID: <6278879c0608072054o425e58a8vad22030489078b71@mail.gmail.com> Hi Michael, Here is an updated gism.py with the vector module completed, enjoy! Yann On 08/08/06, Yann Chemin wrote: > Hi Michael, > please incorporate the r.mapcalc fix from Glynn. > :-) > Yann > > ---------- Forwarded message ---------- > From: Yann Chemin > Date: 08-Aug-2006 09:21 > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > To: Glynn Clements > Cc: Grass Developers List > > > Thanks Glynn ! > It works well. > > here are the modifications: > in gism.py replace: > ("Map calculator", "Map calculator", self.runMenuCmd, "r.mapcalc"), > with this: > ("Map calculator", "Map calculator", self.runMenuCmd, "mapcalc_gparser.sh"), > > and add the Glynn file attached (mapcalc_gparser.sh) to the py_gm directory. > > it opens a r.mapcalc dialog box where one can enter equations. > > :-) > Yann > > On 08/08/06, Yann Chemin wrote: > > nice! > > > > ok, i'll try. > > > > thanks, > > Yann > > > > On 08/08/06, Glynn Clements wrote: > > > > > > Yann Chemin wrote: > > > > > > > Sorry to ask this new bie question, but you mean that the front-end > > > > should be a file called from the GUI and this front-end will somehow > > > > launch r.mapcalc, don't you? > > > > > > Yes. The front-end would be a g.parser script with one option, > > > expression=, and it would invoke r.mapcalc on that expression. > > > > > > Unlike r.mapcalc, a script which uses g.parser will accept all > > > G_parser() options, e.g. --interface-description. > > > > > > -- > > > Glynn Clements > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: gism.py Type: text/x-python Size: 40416 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060808/ff6cca81/gism-0001.py From grass-bugs at intevation.de Tue Aug 8 09:05:28 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Aug 8 09:05:31 2006 Subject: [GRASS-dev] [bug #4982] (grass) r.his: the -n flag - leftover or wrong description Message-ID: <20060808070528.9EAF7100161@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4982 ------------------------------------------------------------------------- Subject: r.his: the -n flag - leftover or wrong description Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: 2006.08.02 r.his has an -n option for "Respect NULL values while drawing". It refers to *drawing* while r.his doesn't draw but creates rasters. d.his has an identical flag, maybe this is some sort of an leftover (as r.his is based on d.his)? Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Tue Aug 8 09:20:19 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Aug 8 09:20:21 2006 Subject: [GRASS-dev] [bug #4983] (grass) r.blend: the output name check is to strict Message-ID: <20060808072019.68214100161@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4983 ------------------------------------------------------------------------- Subject: r.blend: the output name check is to strict Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources GRASS Version: 2006.08.02 If the output *base* name is identical to input name, an error is issued: r.blend first=map1 second=map2 output=map1 Error: option : exists. This is *wrong* - r.blend *won't* be overwriting , it will be *creating* map1.r map1.b and map1.g, OTW, using the as a *base* name only ("Base name for red, green, & blue output maps containing the blend", like manuall says). Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Tue Aug 8 09:31:19 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Tue Aug 8 09:31:20 2006 Subject: [GRASS-dev] [bug #4983] (grass) r.blend: the output name check is to strict Message-ID: <20060808073119.48F74100161@lists.intevation.de> Moreover, r.blend ignores --ovewrite flag: $ g.list rast | grep map1_blend map1_blend.b map1_blend.g map1_blend.r $ r.blend --o first=map1 second=map2 output=map1_blend Raster map already exists. *I know* it *exists* - that's why I'm using --o switch; but it's ignored for some reason. I'm changing the subject to 'r.blend: the output name check doesn't work'. Maciek -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Tue Aug 8 09:34:32 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Aug 8 09:34:34 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: Message-ID: <44D83E88.6010808@club.worldonline.be> Michael Barton wrote: > Moritz and Yann, > > I forgot to ask you. Are you using whatever came with Debian unstable, or > did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) > and wxPython 2.6.3.x? I have tried it with python 2.4.3-7 and wxptyhon 2.6.1.2 (from Ubuntu as the debian version is still compiled against python2.3) and I still have the same problem with panning. To test with newer version I will have to compile myself. I'll do that when I find the time. > > Image dragging works very smoothly on my Mac. How does resizing look? I assume you mean window resizing. It doesn't work: I can see the map flicker at the correct, resized size, but then the display is grey. When I click on the "display map" button, it appears at the original size, thus only filling a part of the screen. > A > buffered DC can be used to reduce flicker, but is a bit of a pain to > implement. Need to know if it is needed on some systems or the problem is an > issue of different versions of the software. > > Check out the new version I just uploaded. > > Cheers > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Moritz Lennert >> Date: Fri, 04 Aug 2006 10:28:47 +0200 >> To: Michael Barton >> Cc: Grass Developers List , Jachym Cepicky >> , Trevor Wiens , David >> Finlayson >> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >> >> Panning however causes problems for me: >> >> - first the screen flashes very frequently while the map moves >> - once the map is in its new position, I cannot use the mouse anymore, >> only my keyboard. However, when I change to another workspace of my >> Gnome desktop and then switch back again, the map display is empty, but >> I can use my mouse again. > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From ychemin at gmail.com Tue Aug 8 09:48:04 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 09:48:06 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <44D83E88.6010808@club.worldonline.be> References: <44D83E88.6010808@club.worldonline.be> Message-ID: <6278879c0608080048q3f492050jd4c071ae988ef42a@mail.gmail.com> Using the pan mode works with 1 second delay, but then i cannot exit from it, the button is always selected (does not give back control to other buttons), have to kill it (Alt+F4). using "zoom in" produces a blank map. Using "Zoom out" works well. On 08/08/06, Moritz Lennert wrote: > Michael Barton wrote: > > Moritz and Yann, > > > > I forgot to ask you. Are you using whatever came with Debian unstable, or > > did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) > > and wxPython 2.6.3.x? > > I have tried it with > > python 2.4.3-7 > and wxptyhon 2.6.1.2 (from Ubuntu as the debian version is still > compiled against python2.3) > > and I still have the same problem with panning. > > To test with newer version I will have to compile myself. I'll do that > when I find the time. > > > > > Image dragging works very smoothly on my Mac. How does resizing look? > > I assume you mean window resizing. It doesn't work: I can see the map > flicker at the correct, resized size, but then the display is grey. When > I click on the "display map" button, it appears at the original size, > thus only filling a part of the screen. > > > A > > buffered DC can be used to reduce flicker, but is a bit of a pain to > > implement. Need to know if it is needed on some systems or the problem is an > > issue of different versions of the software. > > > > Check out the new version I just uploaded. > > > > Cheers > > Michael > > __________________________________________ > > Michael Barton, Professor of Anthropology > > 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: Moritz Lennert > >> Date: Fri, 04 Aug 2006 10:28:47 +0200 > >> To: Michael Barton > >> Cc: Grass Developers List , Jachym Cepicky > >> , Trevor Wiens , David > >> Finlayson > >> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > >> > >> Panning however causes problems for me: > >> > >> - first the screen flashes very frequently while the map moves > >> - once the map is in its new position, I cannot use the mouse anymore, > >> only my keyboard. However, when I change to another workspace of my > >> Gnome desktop and then switch back again, the map display is empty, but > >> I can use my mouse again. > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > From neteler at itc.it Tue Aug 8 09:49:48 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 8 09:49:50 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: Message-ID: <44D8421C.7050307@itc.it> Michael Barton wrote on 08/07/2006 07:39 PM: > Yann, > > We need to merge this with the new version I just posted on the WIKI. > Definitely need to move this into the CVS. > > Markus, procedure? > > Yes, development via CVS is certainly easier. But I think that it should not be added to GRASS 6.2. Proposal: - I release GRASS 6.1.0 now - and create the 6.2 release branch - and rename CVS-HEAD to 6.3.cvs Then you could submit the new GUI to CVS. Makes sense? Markus From glynn at gclements.plus.com Tue Aug 8 10:02:19 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 10:03:54 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <20060808032456.GA78963@localhost.tamu.edu> References: <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.52951.348154.527585@cerise.gclements.plus.com> <17620.59460.354001.833248@cerise.gclements.plus.com> <20060807234347.GA51489@localhost.tamu.edu> <17623.62688.894218.222409@cerise.gclements.plus.com> <20060808032456.GA78963@localhost.tamu.edu> Message-ID: <17624.17675.581373.92000@cerise.gclements.plus.com> Huidae Cho wrote: > > The main question is: in how many different places does this issue > > arise? If it's just Init.sh, we can add a hack for MSys. If it's going > > to keep cropping up, we need a more general solution. > > Another problem is with the path separator. > PATH="c:/msys/1.0/.../grass/bin" does not work since it's translated to > PATH="c;c:\msys\1.0\msys\1.0\...\grass\bin". MSVCRT functions use the > c:/msys/1.0 syntax, but once modules are compiled, they need > PATH=/c/msys/1.0 to find DLLs. MSys (bash) automatically translates filenames when it thinks that's the correct thing to do, so you set PATH=/c/msys/1.0/.../grass/bin (or just PATH=/.../grass/bin) and the program will actually get the Windows syntax. E.g.: $ cat env.c #include int main(void) { printf("%s\n", getenv("PATH")); return 0; } $ echo $PATH /usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem $ ./env.exe C:\msys\1.0\local\bin;c:\mingw\bin;C:\msys\1.0\bin;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem The problem is that it can't always figure out if something is meant to be translated or not. E.g. with: echo "GISDBASE: $GISDBASE" > "$GISRC" it doesn't treat the string as a filename, so it gets written literally. Some examples: $ GISDBASE=/home/glynn/grass-data $ echo $GISDBASE /home/glynn/grass-data $ /bin/echo $GISDBASE /home/glynn/grass-data $ ls -d $GISDBASE /home/glynn/grass-data $ /c/Cygwin/bin/ls.exe -d $GISDBASE C:/msys/1.0/home/glynn/grass-data $ /c/Cygwin/bin/echo.exe $GISDBASE C:/msys/1.0/home/glynn/grass-data $ /c/Cygwin/bin/echo.exe "GISDBASE:" $GISDBASE GISDBASE: C:/msys/1.0/home/glynn/grass-data $ /c/Cygwin/bin/echo.exe "GISDBASE: $GISDBASE" GISDBASE: /home/glynn/grass-data $ /c/Cygwin/bin/echo.exe foo=$GISDBASE foo=C:/msys/1.0/home/glynn/grass-data It appears that: 1. When calling a built-in, running a bash script (e.g. /bin/echo), or running an MSys executable, no translation occurs. 2. When running a non-MSys executable (e.g. Cygwin's echo.exe or ls.exe), translation is performed if a complete argument looks like a filename. 3. Where a filename is only part of an argument, translation may or may not be performed depending upon the exact form of the argument. I have no idea whether the specifics are documented anywhere. So the issue comes down to determining cases where pathnames may passed through mechanisms which aren't subject to the necessary conversions (or possibly which are converted but shouldn't be). -- Glynn Clements From ychemin at gmail.com Tue Aug 8 10:07:55 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 10:07:57 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <44D8421C.7050307@itc.it> References: <44D8421C.7050307@itc.it> Message-ID: <6278879c0608080107g644a8b97laa4f251798ecd0db@mail.gmail.com> yep, makes sense. :-) On 08/08/06, Markus Neteler wrote: > Michael Barton wrote on 08/07/2006 07:39 PM: > > Yann, > > > > We need to merge this with the new version I just posted on the WIKI. > > Definitely need to move this into the CVS. > > > > Markus, procedure? > > > > > Yes, development via CVS is certainly easier. But I think that it should > not be added to GRASS 6.2. > > Proposal: > - I release GRASS 6.1.0 now > - and create the 6.2 release branch > - and rename CVS-HEAD to 6.3.cvs > > Then you could submit the new GUI to CVS. > Makes sense? > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From glynn at gclements.plus.com Tue Aug 8 10:11:43 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 10:11:53 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <20060808022155.GA78791@localhost.tamu.edu> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> <17623.38630.975948.118205@cerise.gclements.plus.com> <20060807210300.GA25702@localhost> <17623.54231.988479.503249@cerise.gclements.plus.com> <20060808022155.GA78791@localhost.tamu.edu> Message-ID: <17624.18239.542010.99951@cerise.gclements.plus.com> Huidae Cho wrote: > > > I found the latest CVS version does not compile under the last week's > > > Cygwin for some reasons. Maybe this problem has to do with the way of > > > building DLLs. Has anyone tried to compile CVS sources under Cygwin? > > > > Yes. The --enable-shared stopped working after upgrading Cygwin. The > > DLLs are built, the programs are built against them, but trying to run > > a program results in nothing happening (no errors). Running the > > program via gdb/strace results in a segfault. > > > > AFAICT, this is a Cygwin issue. As it affects all programs, the only > > GRASS changes to affect it would have to be related to libgis or the > > build system, and I can't see anything suspicious in that area. > > (cd grass6 && make) stops at lib/vector/diglib when executing the test > program. It seems like it takes forever for executables to find DLL > exported symbols such as dig_set_cur_port(). It just stops there and > holds terminal. Killing the process four times in the Task Manager > actually stops it, but it happens again at some point (maybe it's > libgrass_dig again). That's the first point in the build process where a GRASS executable is run. I don't get a hang; the programs just do nothing. No output, no error message, no delay. I don't want to spend too much time on this right now in case it just goes away by itself in the next Cygwin update. Cygwin does appear to have adopted a slightly relaxed definition of "stable" recently (e.g. changing the "stable" X release from 6.8.2 to 6.8.99.901). -- Glynn Clements From mlennert at club.worldonline.be Tue Aug 8 10:44:31 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Aug 8 10:44:32 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17623.38630.975948.118205@cerise.gclements.plus.com> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> <17623.38630.975948.118205@cerise.gclements.plus.com> Message-ID: <44D84EEF.1070607@club.worldonline.be> Glynn Clements wrote: > Moritz Lennert wrote: > >>>>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules >>>>> work without X11 or there is a TclTk replacement for critical modules. >>>>> v.digit is the only major exception now. NVIZ without X11 may still be in >>>>> transition. It still has problems on Intel Macs and I'm not sure about where >>>>> it is for Windows. >> Using the grass-cvs binaries from http://geni.ath.cx/grass.html which >> according to the web page date from April 17, 2006, even the gis.m seems >> to use X. At least, there is a large X in the top left of all the >> windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat) >> starts Xwin and then launches an xterm within that Xwin session. >> >> So, how can I use the guis without X ? > > 1. Download the Tcl/Tk source code, and compile it. You might be able > to use the ActiveState Tcl/Tk package for gis.m, although I haven't > tried it. It's less likely that it would work with NVIZ. Cygwin's > Tcl/Tk *definitely* won't work with GRASS, due to the way it handles > filenames. > > 2. Download the GRASS source code, and compile it. > Just to make sure: to do this, I need MinGW or MSys, or both ? Moritz From grass-bugs at intevation.de Tue Aug 8 11:20:58 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Tue Aug 8 11:21:01 2006 Subject: [GRASS-dev] [bug #3680] (grass) r.out.tiff, GUI: no progress indicator Message-ID: <20060808092058.AB0741005B1@lists.intevation.de> > GRASS Version: cvs 07.09.2005 > > There is no progress bar in GUI for r.out.tiff. As of current CVS there is progress indicator now in GUI, though still a redundant message is printed under the progress bar (both while module is working and after that) "r.out.tiff: complete ...". It shouldn't be there, should it? Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Tue Aug 8 12:53:38 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Aug 8 12:53:40 2006 Subject: [GRASS-dev] [bug #4986] (grass) NVIZ freeze on Debian Sarge Message-ID: <20060808105338.4BB9C10015A@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4986 ------------------------------------------------------------------------- Subject: NVIZ freeze on Debian Sarge Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: CVS checked out at 20060808 Calling up NVIZ both from the command line or by the map display button results in a NVIT-freeze. The initial windows pop up and the "Please wait" message is printed. If NVIZ is called up from a map display (with some raster data), the "translating colors for fp 99%" message ist printed before the freeze occurs. Peter -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Tue Aug 8 16:16:28 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Aug 8 16:16:30 2006 Subject: [GRASS-dev] [bug #4987] (grass) malloc errors/declaration - 64 bit problems Message-ID: <20060808141628.1DC7410016A@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4987 ------------------------------------------------------------------------- Subject: malloc errors/declaration - 64 bit problems grass obtained from: CVS grass binary for platform: Compiled from Sources Copied to bugtracker by MN. ------- On Tue, Aug 08, 2006 at 04:10:04PM +0200, Roberto Flor wrote: Here my findings on 64 bit problems: Simple, potential error on 64 bit machines, really only for float case: ./raster/simwe/r.sim.sediment/main.c: si = (double **)G_malloc (sizeof(double)*(my)); ./raster/simwe/r.sim.sediment/main.c: sigma = (double **)G_malloc (sizeof(double)*(my)); ./raster/simwe/r.sim.sediment/main.c: dif = (float **)G_malloc (sizeof(float)*(my)); ./raster/simwe/r.sim.sediment/main.c: er = (float **)G_malloc (sizeof(float)*(my)); ./vector/v.surf.idw/main.c: npoints_currcell = (long **)G_malloc(window.rows * sizeof(long)); Overzealous but should'nt be a problem: ./raster/r.param.scale/nrutil.c: t = (float ***) G_malloc (((nrow+NR_END) * sizeof(float**))); ./imagery/i.smap/bouman/multialloc.c: r[0]=(char *)G_malloc(max*sizeof(char **)); ./lib/imagery/alloc.c: x = (double ***)G_malloc((a+1) * sizeof(double **)); Hyper allocation, requires more memory than necessary: ./vector/v.surf.idw/main.c: search_list = (struct cell_list **)G_malloc(max_radius * sizeof(struct cell_list)); ./vector/v.surf.idw/main.c: search_list_start = (struct cell_list **)G_malloc(max_radius * sizeof(struct cell_list)); ./vector/v.surf.idw/main.c: points = (struct Point ***)G_malloc(window.rows * sizeof(struct Point)); ./vector/v.surf.idw/main.c: points[row] = (struct Point **)G_malloc(window.cols * sizeof(struct Point)); In all the case the sizeof shoul to be of a pointer. -------------------------------------------- Managed by Request Tracker From paul-grass at stjohnspoint.co.uk Tue Aug 8 16:45:17 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Aug 8 16:45:30 2006 Subject: [GRASS-dev] [bug #4987] (grass) malloc errors/declaration - 64 bit problems In-Reply-To: <20060808141628.1DC7410016A@lists.intevation.de> References: <20060808141628.1DC7410016A@lists.intevation.de> Message-ID: On Tue, 8 Aug 2006, Request Tracker wrote: > On Tue, Aug 08, 2006 at 04:10:04PM +0200, Roberto Flor wrote: > Here my findings on 64 bit problems: > > Simple, potential error on 64 bit machines, really only for float case: > [...] > ./vector/v.surf.idw/main.c: npoints_currcell = (long **)G_malloc(window.rows * sizeof(long)); > [...] > > Hyper allocation, requires more memory than necessary: > > ./vector/v.surf.idw/main.c: search_list = (struct cell_list **)G_malloc(max_radius * sizeof(struct cell_list)); > ./vector/v.surf.idw/main.c: search_list_start = (struct cell_list **)G_malloc(max_radius * sizeof(struct cell_list)); > ./vector/v.surf.idw/main.c: points = (struct Point ***)G_malloc(window.rows * sizeof(struct Point)); > ./vector/v.surf.idw/main.c: points[row] = (struct Point **)G_malloc(window.cols * sizeof(struct Point)); > > In all the case the sizeof shoul to be of a pointer. The v.surf.idw are all my mistakes; well spotted and thanks for pointing them out. To fix them, I guess the size of a pointer is always the same no matter what type it points to, so is there a standard way of representing it always, e.g. like sizeof(char *)? Or should we always write sizeof(long *), sizeof(struct Point *) etc. as appropriate? Is it just a question of programming style? Paul From michael.barton at asu.edu Tue Aug 8 17:08:18 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 8 17:08:29 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608080107g644a8b97laa4f251798ecd0db@mail.gmail.com> Message-ID: Markus, Didn't see this. OK. We can wait. But this will make work on this difficult for awhile. Do we still not have a 'workshop' area in the cvs where we can put things to work on that don't get distributed in the normal source release? Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Tue, 8 Aug 2006 15:07:55 +0700 > To: Markus Neteler > Cc: Grass Developers List > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > yep, makes sense. > :-) > > On 08/08/06, Markus Neteler wrote: >> Michael Barton wrote on 08/07/2006 07:39 PM: >>> Yann, >>> >>> We need to merge this with the new version I just posted on the WIKI. >>> Definitely need to move this into the CVS. >>> >>> Markus, procedure? >>> >>> >> Yes, development via CVS is certainly easier. But I think that it should >> not be added to GRASS 6.2. >> >> Proposal: >> - I release GRASS 6.1.0 now >> - and create the 6.2 release branch >> - and rename CVS-HEAD to 6.3.cvs >> >> Then you could submit the new GUI to CVS. >> Makes sense? >> >> Markus >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> > > From michael.barton at asu.edu Tue Aug 8 17:11:34 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 8 17:11:42 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <44D83E88.6010808@club.worldonline.be> Message-ID: Moritz and Yann, I hope to be able to test this on FC4 and Debian soon here. I'll let you know if we have the same issues. My guess is that if it's a version issue, it's with wxPython, since we're all using Python 2.4.3. You might check the change log of 2.6.1 to 2.6.3 changes. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Moritz Lennert > Date: Tue, 08 Aug 2006 09:34:32 +0200 > To: Michael Barton > Cc: Yann Chemin , Trevor Wiens , > David Finlayson , Jachym Cepicky > , Grass Developers List > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > Michael Barton wrote: >> Moritz and Yann, >> >> I forgot to ask you. Are you using whatever came with Debian unstable, or >> did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) >> and wxPython 2.6.3.x? > > I have tried it with > > python 2.4.3-7 > and wxptyhon 2.6.1.2 (from Ubuntu as the debian version is still > compiled against python2.3) > > and I still have the same problem with panning. > > To test with newer version I will have to compile myself. I'll do that > when I find the time. > >> >> Image dragging works very smoothly on my Mac. How does resizing look? > > I assume you mean window resizing. It doesn't work: I can see the map > flicker at the correct, resized size, but then the display is grey. When > I click on the "display map" button, it appears at the original size, > thus only filling a part of the screen. > >> A >> buffered DC can be used to reduce flicker, but is a bit of a pain to >> implement. Need to know if it is needed on some systems or the problem is an >> issue of different versions of the software. >> >> Check out the new version I just uploaded. >> >> Cheers >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> 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: Moritz Lennert >>> Date: Fri, 04 Aug 2006 10:28:47 +0200 >>> To: Michael Barton >>> Cc: Grass Developers List , Jachym Cepicky >>> , Trevor Wiens , David >>> Finlayson >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>> >>> Panning however causes problems for me: >>> >>> - first the screen flashes very frequently while the map moves >>> - once the map is in its new position, I cannot use the mouse anymore, >>> only my keyboard. However, when I change to another workspace of my >>> Gnome desktop and then switch back again, the map display is empty, but >>> I can use my mouse again. >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > From neteler at itc.it Tue Aug 8 17:30:40 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 8 17:30:41 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <6278879c0608080107g644a8b97laa4f251798ecd0db@mail.gmail.com> Message-ID: <20060808153040.GJ28523@bartok.itc.it> On Tue, Aug 08, 2006 at 08:08:18AM -0700, Michael Barton wrote: > Markus, > > Didn't see this. OK. We can wait. But this will make work on this difficult > for awhile. Michael, I was proposing "now". Not sure about difficulties with waiting for 1 day... > Do we still not have a 'workshop' area in the cvs where we can > put things to work on that don't get distributed in the normal source > release? No, we don't have that. I had contacted Bernhard again, but he didn't give me a time frame about migration. Anyway, I suggested to do it now, so I hope that it's fast enough :) Since I don't consider release preparations as my private thing, I always try to stimulate some discussions before. Markus > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Yann Chemin > > Date: Tue, 8 Aug 2006 15:07:55 +0700 > > To: Markus Neteler > > Cc: Grass Developers List > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > > yep, makes sense. > > :-) > > > > On 08/08/06, Markus Neteler wrote: > >> Michael Barton wrote on 08/07/2006 07:39 PM: > >>> Yann, > >>> > >>> We need to merge this with the new version I just posted on the WIKI. > >>> Definitely need to move this into the CVS. > >>> > >>> Markus, procedure? > >>> > >>> > >> Yes, development via CVS is certainly easier. But I think that it should > >> not be added to GRASS 6.2. > >> > >> Proposal: > >> - I release GRASS 6.1.0 now > >> - and create the 6.2 release branch > >> - and rename CVS-HEAD to 6.3.cvs > >> > >> Then you could submit the new GUI to CVS. > >> Makes sense? > >> > >> Markus From ychemin at gmail.com Tue Aug 8 17:32:25 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 17:32:31 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <44D83E88.6010808@club.worldonline.be> Message-ID: <6278879c0608080832r3030d326n5b945ccfa1768673@mail.gmail.com> Hi Michael, here is the gism.py with image module completed. Yann On 08/08/06, Michael Barton wrote: > Moritz and Yann, > > I hope to be able to test this on FC4 and Debian soon here. I'll let you > know if we have the same issues. > > My guess is that if it's a version issue, it's with wxPython, since we're > all using Python 2.4.3. > > You might check the change log of 2.6.1 to 2.6.3 changes. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Moritz Lennert > > Date: Tue, 08 Aug 2006 09:34:32 +0200 > > To: Michael Barton > > Cc: Yann Chemin , Trevor Wiens , > > David Finlayson , Jachym Cepicky > > , Grass Developers List > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > > Michael Barton wrote: > >> Moritz and Yann, > >> > >> I forgot to ask you. Are you using whatever came with Debian unstable, or > >> did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) > >> and wxPython 2.6.3.x? > > > > I have tried it with > > > > python 2.4.3-7 > > and wxptyhon 2.6.1.2 (from Ubuntu as the debian version is still > > compiled against python2.3) > > > > and I still have the same problem with panning. > > > > To test with newer version I will have to compile myself. I'll do that > > when I find the time. > > > >> > >> Image dragging works very smoothly on my Mac. How does resizing look? > > > > I assume you mean window resizing. It doesn't work: I can see the map > > flicker at the correct, resized size, but then the display is grey. When > > I click on the "display map" button, it appears at the original size, > > thus only filling a part of the screen. > > > >> A > >> buffered DC can be used to reduce flicker, but is a bit of a pain to > >> implement. Need to know if it is needed on some systems or the problem is an > >> issue of different versions of the software. > >> > >> Check out the new version I just uploaded. > >> > >> Cheers > >> Michael > >> __________________________________________ > >> Michael Barton, Professor of Anthropology > >> 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: Moritz Lennert > >>> Date: Fri, 04 Aug 2006 10:28:47 +0200 > >>> To: Michael Barton > >>> Cc: Grass Developers List , Jachym Cepicky > >>> , Trevor Wiens , David > >>> Finlayson > >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > >>> > >>> Panning however causes problems for me: > >>> > >>> - first the screen flashes very frequently while the map moves > >>> - once the map is in its new position, I cannot use the mouse anymore, > >>> only my keyboard. However, when I change to another workspace of my > >>> Gnome desktop and then switch back again, the map display is empty, but > >>> I can use my mouse again. > >> > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: gism.py Type: text/x-python Size: 45460 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20060808/6ad9a149/gism-0001.py From ychemin at gmail.com Tue Aug 8 18:07:06 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 18:07:10 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <44D83E88.6010808@club.worldonline.be> Message-ID: <6278879c0608080907k5e44f41dud8238b3186d74ce7@mail.gmail.com> the version installed here is wxPythonGTK2.6-2.6.3.3-2mdv2007.0 from wxpython www: last changes from 2.6.2.1 are dealing with : ----------- Added wx.SizerItem.SetUserData A variety of updates to wx.lib.floatcanvas, including Added DrawObjects, including a ScaledTextBox, with auto-wrapping, etc, and Scaled and Unscaled Bitmap Objects. WARNING: Changed all DrawObjects to take an (x,y) pair rather than individual x,y parameters. Also changed rectangles and ellipses to take (w,h) pair. This is an API change, but should be easy to accommodate, all you need to do is add a parenthesis pair: (...x, y, ...) ---> (...(x,y), ...) ---------- maybe somebody can understand more than i can... :-) On 08/08/06, Michael Barton wrote: > Moritz and Yann, > > I hope to be able to test this on FC4 and Debian soon here. I'll let you > know if we have the same issues. > > My guess is that if it's a version issue, it's with wxPython, since we're > all using Python 2.4.3. > > You might check the change log of 2.6.1 to 2.6.3 changes. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Moritz Lennert > > Date: Tue, 08 Aug 2006 09:34:32 +0200 > > To: Michael Barton > > Cc: Yann Chemin , Trevor Wiens , > > David Finlayson , Jachym Cepicky > > , Grass Developers List > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > > Michael Barton wrote: > >> Moritz and Yann, > >> > >> I forgot to ask you. Are you using whatever came with Debian unstable, or > >> did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) > >> and wxPython 2.6.3.x? > > > > I have tried it with > > > > python 2.4.3-7 > > and wxptyhon 2.6.1.2 (from Ubuntu as the debian version is still > > compiled against python2.3) > > > > and I still have the same problem with panning. > > > > To test with newer version I will have to compile myself. I'll do that > > when I find the time. > > > >> > >> Image dragging works very smoothly on my Mac. How does resizing look? > > > > I assume you mean window resizing. It doesn't work: I can see the map > > flicker at the correct, resized size, but then the display is grey. When > > I click on the "display map" button, it appears at the original size, > > thus only filling a part of the screen. > > > >> A > >> buffered DC can be used to reduce flicker, but is a bit of a pain to > >> implement. Need to know if it is needed on some systems or the problem is an > >> issue of different versions of the software. > >> > >> Check out the new version I just uploaded. > >> > >> Cheers > >> Michael > >> __________________________________________ > >> Michael Barton, Professor of Anthropology > >> 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: Moritz Lennert > >>> Date: Fri, 04 Aug 2006 10:28:47 +0200 > >>> To: Michael Barton > >>> Cc: Grass Developers List , Jachym Cepicky > >>> , Trevor Wiens , David > >>> Finlayson > >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > >>> > >>> Panning however causes problems for me: > >>> > >>> - first the screen flashes very frequently while the map moves > >>> - once the map is in its new position, I cannot use the mouse anymore, > >>> only my keyboard. However, when I change to another workspace of my > >>> Gnome desktop and then switch back again, the map display is empty, but > >>> I can use my mouse again. > >> > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > > > > From michael.barton at asu.edu Tue Aug 8 18:25:20 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 8 18:25:38 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608080907k5e44f41dud8238b3186d74ce7@mail.gmail.com> Message-ID: These changes, especially the scaled bitmap (which I use for window resizing) would significantly affect how the app works. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Tue, 8 Aug 2006 23:07:06 +0700 > To: Michael Barton > Cc: Moritz Lennert , Trevor Wiens > , David Finlayson , Jachym > Cepicky , Grass Developers List > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > the version installed here is wxPythonGTK2.6-2.6.3.3-2mdv2007.0 > > from wxpython www: > last changes from 2.6.2.1 are dealing with : > > ----------- > Added wx.SizerItem.SetUserData > > A variety of updates to wx.lib.floatcanvas, including Added > DrawObjects, including a ScaledTextBox, with auto-wrapping, etc, and > Scaled and Unscaled Bitmap Objects. > > WARNING: Changed all DrawObjects to take an (x,y) pair rather than > individual x,y parameters. Also changed rectangles and ellipses to > take (w,h) pair. This is an API change, but should be easy to > accommodate, all you need to do is add a parenthesis pair: (...x, y, > ...) ---> (...(x,y), ...) > > ---------- > > maybe somebody can understand more than i can... :-) > > > > On 08/08/06, Michael Barton wrote: >> Moritz and Yann, >> >> I hope to be able to test this on FC4 and Debian soon here. I'll let you >> know if we have the same issues. >> >> My guess is that if it's a version issue, it's with wxPython, since we're >> all using Python 2.4.3. >> >> You might check the change log of 2.6.1 to 2.6.3 changes. >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> 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: Moritz Lennert >>> Date: Tue, 08 Aug 2006 09:34:32 +0200 >>> To: Michael Barton >>> Cc: Yann Chemin , Trevor Wiens , >>> David Finlayson , Jachym Cepicky >>> , Grass Developers List >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>> >>> Michael Barton wrote: >>>> Moritz and Yann, >>>> >>>> I forgot to ask you. Are you using whatever came with Debian unstable, or >>>> did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) >>>> and wxPython 2.6.3.x? >>> >>> I have tried it with >>> >>> python 2.4.3-7 >>> and wxptyhon 2.6.1.2 (from Ubuntu as the debian version is still >>> compiled against python2.3) >>> >>> and I still have the same problem with panning. >>> >>> To test with newer version I will have to compile myself. I'll do that >>> when I find the time. >>> >>>> >>>> Image dragging works very smoothly on my Mac. How does resizing look? >>> >>> I assume you mean window resizing. It doesn't work: I can see the map >>> flicker at the correct, resized size, but then the display is grey. When >>> I click on the "display map" button, it appears at the original size, >>> thus only filling a part of the screen. >>> >>>> A >>>> buffered DC can be used to reduce flicker, but is a bit of a pain to >>>> implement. Need to know if it is needed on some systems or the problem is >>>> an >>>> issue of different versions of the software. >>>> >>>> Check out the new version I just uploaded. >>>> >>>> Cheers >>>> Michael >>>> __________________________________________ >>>> Michael Barton, Professor of Anthropology >>>> 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: Moritz Lennert >>>>> Date: Fri, 04 Aug 2006 10:28:47 +0200 >>>>> To: Michael Barton >>>>> Cc: Grass Developers List , Jachym Cepicky >>>>> , Trevor Wiens , David >>>>> Finlayson >>>>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>>>> >>>>> Panning however causes problems for me: >>>>> >>>>> - first the screen flashes very frequently while the map moves >>>>> - once the map is in its new position, I cannot use the mouse anymore, >>>>> only my keyboard. However, when I change to another workspace of my >>>>> Gnome desktop and then switch back again, the map display is empty, but >>>>> I can use my mouse again. >>>> >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev@grass.itc.it >>>> http://grass.itc.it/mailman/listinfo/grass-dev >>> >> >> From ychemin at gmail.com Tue Aug 8 18:28:37 2006 From: ychemin at gmail.com (Yann Chemin) Date: Tue Aug 8 18:28:42 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: References: <6278879c0608080907k5e44f41dud8238b3186d74ce7@mail.gmail.com> Message-ID: <6278879c0608080928r2e5ec6bfu8f08dd4efb15629f@mail.gmail.com> It seems that it has been discussed on this www: http://blog.gmane.org/gmane.comp.python.wxpython.devel/month=20060101 On 08/08/06, Michael Barton wrote: > These changes, especially the scaled bitmap (which I use for window > resizing) would significantly affect how the app works. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > 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: Yann Chemin > > Date: Tue, 8 Aug 2006 23:07:06 +0700 > > To: Michael Barton > > Cc: Moritz Lennert , Trevor Wiens > > , David Finlayson , Jachym > > Cepicky , Grass Developers List > > > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > > > the version installed here is wxPythonGTK2.6-2.6.3.3-2mdv2007.0 > > > > from wxpython www: > > last changes from 2.6.2.1 are dealing with : > > > > ----------- > > Added wx.SizerItem.SetUserData > > > > A variety of updates to wx.lib.floatcanvas, including Added > > DrawObjects, including a ScaledTextBox, with auto-wrapping, etc, and > > Scaled and Unscaled Bitmap Objects. > > > > WARNING: Changed all DrawObjects to take an (x,y) pair rather than > > individual x,y parameters. Also changed rectangles and ellipses to > > take (w,h) pair. This is an API change, but should be easy to > > accommodate, all you need to do is add a parenthesis pair: (...x, y, > > ...) ---> (...(x,y), ...) > > > > ---------- > > > > maybe somebody can understand more than i can... :-) > > > > > > > > On 08/08/06, Michael Barton wrote: > >> Moritz and Yann, > >> > >> I hope to be able to test this on FC4 and Debian soon here. I'll let you > >> know if we have the same issues. > >> > >> My guess is that if it's a version issue, it's with wxPython, since we're > >> all using Python 2.4.3. > >> > >> You might check the change log of 2.6.1 to 2.6.3 changes. > >> > >> Michael > >> __________________________________________ > >> Michael Barton, Professor of Anthropology > >> 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: Moritz Lennert > >>> Date: Tue, 08 Aug 2006 09:34:32 +0200 > >>> To: Michael Barton > >>> Cc: Yann Chemin , Trevor Wiens , > >>> David Finlayson , Jachym Cepicky > >>> , Grass Developers List > >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > >>> > >>> Michael Barton wrote: > >>>> Moritz and Yann, > >>>> > >>>> I forgot to ask you. Are you using whatever came with Debian unstable, or > >>>> did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) > >>>> and wxPython 2.6.3.x? > >>> > >>> I have tried it with > >>> > >>> python 2.4.3-7 > >>> and wxptyhon 2.6.1.2 (from Ubuntu as the debian version is still > >>> compiled against python2.3) > >>> > >>> and I still have the same problem with panning. > >>> > >>> To test with newer version I will have to compile myself. I'll do that > >>> when I find the time. > >>> > >>>> > >>>> Image dragging works very smoothly on my Mac. How does resizing look? > >>> > >>> I assume you mean window resizing. It doesn't work: I can see the map > >>> flicker at the correct, resized size, but then the display is grey. When > >>> I click on the "display map" button, it appears at the original size, > >>> thus only filling a part of the screen. > >>> > >>>> A > >>>> buffered DC can be used to reduce flicker, but is a bit of a pain to > >>>> implement. Need to know if it is needed on some systems or the problem is > >>>> an > >>>> issue of different versions of the software. > >>>> > >>>> Check out the new version I just uploaded. > >>>> > >>>> Cheers > >>>> Michael > >>>> __________________________________________ > >>>> Michael Barton, Professor of Anthropology > >>>> 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: Moritz Lennert > >>>>> Date: Fri, 04 Aug 2006 10:28:47 +0200 > >>>>> To: Michael Barton > >>>>> Cc: Grass Developers List , Jachym Cepicky > >>>>> , Trevor Wiens , David > >>>>> Finlayson > >>>>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > >>>>> > >>>>> Panning however causes problems for me: > >>>>> > >>>>> - first the screen flashes very frequently while the map moves > >>>>> - once the map is in its new position, I cannot use the mouse anymore, > >>>>> only my keyboard. However, when I change to another workspace of my > >>>>> Gnome desktop and then switch back again, the map display is empty, but > >>>>> I can use my mouse again. > >>>> > >>>> _______________________________________________ > >>>> grass-dev mailing list > >>>> grass-dev@grass.itc.it > >>>> http://grass.itc.it/mailman/listinfo/grass-dev > >>> > >> > >> > > From michael.barton at asu.edu Tue Aug 8 18:45:55 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Aug 8 18:46:09 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <6278879c0608080928r2e5ec6bfu8f08dd4efb15629f@mail.gmail.com> Message-ID: Well, that seems to be what is going on. I guess we need to require wxPython 2.6.3. Also, for the moment, I've put a py_gm folder and individual files on my website so that I don't have to repackage everything when a new update comes in. I've put in your very nice menu updates. I put Glynn's script into a scripts folder inside py_gm and changed the reference in the menu accordingly. There are several other scripts I'm putting in there as well. These are commands that won't run correctly using their normal interface descriptions (e.g., r.reclass with the rules flag checked). I made them so that they have a proper interface in the GIS Manager. They will work just the same with the wxPython version. Thanks again for your help. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Tue, 8 Aug 2006 23:28:37 +0700 > To: Michael Barton > Cc: Moritz Lennert , Trevor Wiens > , David Finlayson , Jachym > Cepicky , Grass Developers List > > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 > > It seems that it has been discussed on this www: > http://blog.gmane.org/gmane.comp.python.wxpython.devel/month=20060101 > > > On 08/08/06, Michael Barton wrote: >> These changes, especially the scaled bitmap (which I use for window >> resizing) would significantly affect how the app works. >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> 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: Yann Chemin >>> Date: Tue, 8 Aug 2006 23:07:06 +0700 >>> To: Michael Barton >>> Cc: Moritz Lennert , Trevor Wiens >>> , David Finlayson , >>> Jachym >>> Cepicky , Grass Developers List >>> >>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>> >>> the version installed here is wxPythonGTK2.6-2.6.3.3-2mdv2007.0 >>> >>> from wxpython www: >>> last changes from 2.6.2.1 are dealing with : >>> >>> ----------- >>> Added wx.SizerItem.SetUserData >>> >>> A variety of updates to wx.lib.floatcanvas, including Added >>> DrawObjects, including a ScaledTextBox, with auto-wrapping, etc, and >>> Scaled and Unscaled Bitmap Objects. >>> >>> WARNING: Changed all DrawObjects to take an (x,y) pair rather than >>> individual x,y parameters. Also changed rectangles and ellipses to >>> take (w,h) pair. This is an API change, but should be easy to >>> accommodate, all you need to do is add a parenthesis pair: (...x, y, >>> ...) ---> (...(x,y), ...) >>> >>> ---------- >>> >>> maybe somebody can understand more than i can... :-) >>> >>> >>> >>> On 08/08/06, Michael Barton wrote: >>>> Moritz and Yann, >>>> >>>> I hope to be able to test this on FC4 and Debian soon here. I'll let you >>>> know if we have the same issues. >>>> >>>> My guess is that if it's a version issue, it's with wxPython, since we're >>>> all using Python 2.4.3. >>>> >>>> You might check the change log of 2.6.1 to 2.6.3 changes. >>>> >>>> Michael >>>> __________________________________________ >>>> Michael Barton, Professor of Anthropology >>>> 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: Moritz Lennert >>>>> Date: Tue, 08 Aug 2006 09:34:32 +0200 >>>>> To: Michael Barton >>>>> Cc: Yann Chemin , Trevor Wiens , >>>>> David Finlayson , Jachym Cepicky >>>>> , Grass Developers List >>>>> >>>>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>>>> >>>>> Michael Barton wrote: >>>>>> Moritz and Yann, >>>>>> >>>>>> I forgot to ask you. Are you using whatever came with Debian unstable, or >>>>>> did you install the latest and greatest Python 2.4.2.xx (I'm on 2.4.3.11) >>>>>> and wxPython 2.6.3.x? >>>>> >>>>> I have tried it with >>>>> >>>>> python 2.4.3-7 >>>>> and wxptyhon 2.6.1.2 (from Ubuntu as the debian version is still >>>>> compiled against python2.3) >>>>> >>>>> and I still have the same problem with panning. >>>>> >>>>> To test with newer version I will have to compile myself. I'll do that >>>>> when I find the time. >>>>> >>>>>> >>>>>> Image dragging works very smoothly on my Mac. How does resizing look? >>>>> >>>>> I assume you mean window resizing. It doesn't work: I can see the map >>>>> flicker at the correct, resized size, but then the display is grey. When >>>>> I click on the "display map" button, it appears at the original size, >>>>> thus only filling a part of the screen. >>>>> >>>>>> A >>>>>> buffered DC can be used to reduce flicker, but is a bit of a pain to >>>>>> implement. Need to know if it is needed on some systems or the problem is >>>>>> an >>>>>> issue of different versions of the software. >>>>>> >>>>>> Check out the new version I just uploaded. >>>>>> >>>>>> Cheers >>>>>> Michael >>>>>> __________________________________________ >>>>>> Michael Barton, Professor of Anthropology >>>>>> 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: Moritz Lennert >>>>>>> Date: Fri, 04 Aug 2006 10:28:47 +0200 >>>>>>> To: Michael Barton >>>>>>> Cc: Grass Developers List , Jachym Cepicky >>>>>>> , Trevor Wiens , David >>>>>>> Finlayson >>>>>>> Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 >>>>>>> >>>>>>> Panning however causes problems for me: >>>>>>> >>>>>>> - first the screen flashes very frequently while the map moves >>>>>>> - once the map is in its new position, I cannot use the mouse anymore, >>>>>>> only my keyboard. However, when I change to another workspace of my >>>>>>> Gnome desktop and then switch back again, the map display is empty, but >>>>>>> I can use my mouse again. >>>>>> >>>>>> _______________________________________________ >>>>>> grass-dev mailing list >>>>>> grass-dev@grass.itc.it >>>>>> http://grass.itc.it/mailman/listinfo/grass-dev >>>>> >>>> >>>> >> >> From glynn at gclements.plus.com Tue Aug 8 19:18:43 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 19:18:46 2006 Subject: [GRASS-dev] [bug #4983] (grass) r.blend: the output name check is to strict In-Reply-To: <20060808073119.48F74100161@lists.intevation.de> References: <20060808073119.48F74100161@lists.intevation.de> Message-ID: <17624.51059.716209.350444@cerise.gclements.plus.com> Maciek Sieczka via RT wrote: > Moreover, r.blend ignores --ovewrite flag: > > $ g.list rast | grep map1_blend > > map1_blend.b map1_blend.g > map1_blend.r > > $ r.blend --o first=map1 second=map2 output=map1_blend > Raster map already exists. > > *I know* it *exists* - that's why I'm using --o switch; but it's ignored for > some reason. r.blend performs its own check for the output maps: for MAP in r g b ; do g.findfile elem=cell file=${GIS_OPT_OUTPUT}.$MAP > /dev/null if [ $? -eq 0 ] ; then echo "Raster map <${GIS_OPT_OUTPUT}.$MAP> already exists." 1>&2 exit 1 fi done I've committed fixes for both issues (checking the base name, ignoring --overwrite). -- Glynn Clements From glynn at gclements.plus.com Tue Aug 8 19:31:51 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 19:33:09 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <44D84EEF.1070607@club.worldonline.be> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> <17623.38630.975948.118205@cerise.gclements.plus.com> <44D84EEF.1070607@club.worldonline.be> Message-ID: <17624.51847.501435.796125@cerise.gclements.plus.com> Moritz Lennert wrote: > >>>>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules > >>>>> work without X11 or there is a TclTk replacement for critical modules. > >>>>> v.digit is the only major exception now. NVIZ without X11 may still be in > >>>>> transition. It still has problems on Intel Macs and I'm not sure about where > >>>>> it is for Windows. > >> Using the grass-cvs binaries from http://geni.ath.cx/grass.html which > >> according to the web page date from April 17, 2006, even the gis.m seems > >> to use X. At least, there is a large X in the top left of all the > >> windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat) > >> starts Xwin and then launches an xterm within that Xwin session. > >> > >> So, how can I use the guis without X ? > > > > 1. Download the Tcl/Tk source code, and compile it. You might be able > > to use the ActiveState Tcl/Tk package for gis.m, although I haven't > > tried it. It's less likely that it would work with NVIZ. Cygwin's > > Tcl/Tk *definitely* won't work with GRASS, due to the way it handles > > filenames. > > > > 2. Download the GRASS source code, and compile it. > > Just to make sure: to do this, I need MinGW or MSys, or both ? Both. You also need to build GDAL, PROJ, XDR, zlib from source (XDR has to be the xdr-4.0-mingw2 package; the standard SunRPC distribution uses socket functions which aren't present in the MSVC runtime). For NVIZ, you also need to build Tcl/Tk. -- Glynn Clements From wollez at gmx.net Tue Aug 8 19:39:23 2006 From: wollez at gmx.net (Wolfgang) Date: Tue Aug 8 19:39:40 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: <17624.51847.501435.796125@cerise.gclements.plus.com> References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> <17623.38630.975948.118205@cerise.gclements.plus.com> <44D84EEF.1070607@club.worldonline.be> <17624.51847.501435.796125@cerise.gclements.plus.com> Message-ID: Glynn Clements schrieb: > Moritz Lennert wrote: > >>>>>>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules >>>>>>> work without X11 or there is a TclTk replacement for critical modules. >>>>>>> v.digit is the only major exception now. NVIZ without X11 may still be in >>>>>>> transition. It still has problems on Intel Macs and I'm not sure about where >>>>>>> it is for Windows. >>>> Using the grass-cvs binaries from http://geni.ath.cx/grass.html which >>>> according to the web page date from April 17, 2006, even the gis.m seems >>>> to use X. At least, there is a large X in the top left of all the >>>> windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat) >>>> starts Xwin and then launches an xterm within that Xwin session. >>>> >>>> So, how can I use the guis without X ? >>> 1. Download the Tcl/Tk source code, and compile it. You might be able >>> to use the ActiveState Tcl/Tk package for gis.m, although I haven't >>> tried it. It's less likely that it would work with NVIZ. Cygwin's >>> Tcl/Tk *definitely* won't work with GRASS, due to the way it handles >>> filenames. >>> >>> 2. Download the GRASS source code, and compile it. >> Just to make sure: to do this, I need MinGW or MSys, or both ? > > Both. You also need to build GDAL, PROJ, XDR, zlib from source (XDR > has to be the xdr-4.0-mingw2 package; the standard SunRPC distribution > uses socket functions which aren't present in the MSVC runtime). For > NVIZ, you also need to build Tcl/Tk. > Hi, could anybody put somewhere a detailed description how to compile grass on Cygwin (which packages, compilers, ...)? Not that I also would have problems with speed, but I would like use some features which are not (yet) in the prebuilt cygwin grass. Wolfgang From glynn at gclements.plus.com Tue Aug 8 19:43:12 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 19:43:19 2006 Subject: [GRASS-dev] [bug #4987] (grass) malloc errors/declaration - 64 bit problems In-Reply-To: <20060808141628.1DC7410016A@lists.intevation.de> References: <20060808141628.1DC7410016A@lists.intevation.de> Message-ID: <17624.52528.19731.687397@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=4987 > Subject: malloc errors/declaration - 64 bit problems > > grass obtained from: CVS > grass binary for platform: Compiled from Sources > > Copied to bugtracker by MN. > ------- > > On Tue, Aug 08, 2006 at 04:10:04PM +0200, Roberto Flor wrote: > Here my findings on 64 bit problems: > > Simple, potential error on 64 bit machines, really only for float case: > > ./raster/simwe/r.sim.sediment/main.c: si = (double **)G_malloc (sizeof(double)*(my)); > ./raster/simwe/r.sim.sediment/main.c: sigma = (double **)G_malloc (sizeof(double)*(my)); > ./raster/simwe/r.sim.sediment/main.c: dif = (float **)G_malloc (sizeof(float)*(my)); > ./raster/simwe/r.sim.sediment/main.c: er = (float **)G_malloc (sizeof(float)*(my)); > ./vector/v.surf.idw/main.c: npoints_currcell = (long **)G_malloc(window.rows * sizeof(long)); > ./vector/v.surf.idw/main.c: search_list = (struct cell_list **)G_malloc(max_radius * sizeof(struct cell_list)); > ./vector/v.surf.idw/main.c: search_list_start = (struct cell_list **)G_malloc(max_radius * sizeof(struct cell_list)); > ./vector/v.surf.idw/main.c: points = (struct Point ***)G_malloc(window.rows * sizeof(struct Point)); > ./vector/v.surf.idw/main.c: points[row] = (struct Point **)G_malloc(window.cols * sizeof(struct Point)); > > In all the case the sizeof shoul to be of a pointer. I've fixed these in CVS. -- Glynn Clements From grass-bugs at intevation.de Tue Aug 8 19:44:15 2006 From: grass-bugs at intevation.de (guest user via RT) Date: Tue Aug 8 19:44:17 2006 Subject: [GRASS-dev] [bug #4983] (grass) r.blend: the output name check doesn't work Message-ID: <20060808174415.6ABF41006C6@lists.intevation.de> Great, I conform it's fixed now. Closing it. Thanks, Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Tue Aug 8 19:46:48 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Tue Aug 8 19:46:50 2006 Subject: [GRASS-dev] [bug #4981] (grass) GRASS startup exited abnormally Message-ID: <20060808174648.B67611006C6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=4981 Request number 4981 was commented on by 'msieczka' (Maciek Sieczka). Responding to this message will send mail to the requestor. Request Tracker rt@intevation.de -------------------------------------------------------------- Cc: grass-dev@grass.itc.it guest wrote (Tue, Aug 8 2006 11:08:50): > The problem ist solved. After loading the PROJ package from cygwin setup GRASS > is working. Thanks for the feedback! Closing bug. Maciek -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Tue Aug 8 19:49:13 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 19:49:16 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <44D8421C.7050307@itc.it> References: <44D8421C.7050307@itc.it> Message-ID: <17624.52889.380949.901831@cerise.gclements.plus.com> Markus Neteler wrote: > > We need to merge this with the new version I just posted on the WIKI. > > Definitely need to move this into the CVS. > > > > Markus, procedure? > > Yes, development via CVS is certainly easier. But I think that it should > not be added to GRASS 6.2. > > Proposal: > - I release GRASS 6.1.0 now > - and create the 6.2 release branch > - and rename CVS-HEAD to 6.3.cvs > > Then you could submit the new GUI to CVS. > Makes sense? Not to me. 3 active versions is one too many. Release 6.1.0 now, 6.1.x is stable (bugfix only), CVS HEAD is unstable (no restrictions). -- Glynn Clements From neteler at itc.it Tue Aug 8 20:31:00 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 8 20:31:03 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <17624.52889.380949.901831@cerise.gclements.plus.com> References: <44D8421C.7050307@itc.it> <17624.52889.380949.901831@cerise.gclements.plus.com> Message-ID: <20060808183100.GA31665@bartok.itc.it> On Tue, Aug 08, 2006 at 06:49:13PM +0100, Glynn Clements wrote: > Markus Neteler wrote: > > > > We need to merge this with the new version I just posted on the WIKI. > > > Definitely need to move this into the CVS. > > > > > > Markus, procedure? > > > > Yes, development via CVS is certainly easier. But I think that it should > > not be added to GRASS 6.2. > > > > Proposal: > > - I release GRASS 6.1.0 now > > - and create the 6.2 release branch > > - and rename CVS-HEAD to 6.3.cvs > > > > Then you could submit the new GUI to CVS. > > Makes sense? > > Not to me. 3 active versions is one too many. > > Release 6.1.0 now, ... as suggested. > 6.1.x is stable (bugfix only), There are numerous fixes in CVS HEAD which are missing in 6.1.x branch. That's why I suggested to make a new branch for 6.2 (now!). I forgot to write that the current 6.1.x release branch won't be maintained any more. > CVS HEAD is unstable (no restrictions). ... as suggested. (My) summary: By tomorrow, we can have - 6.1.0 released, branch no longer used - 6.2.x new branch - CVS HEAD, unstable, called 6.3.cvs This gives two versions to be maintained. Markus From glynn at gclements.plus.com Tue Aug 8 22:42:14 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 22:42:18 2006 Subject: [GRASS-dev] GRASS & cygwin quite slow In-Reply-To: References: <44D33A08.7000405@club.worldonline.be> <17619.49252.581045.981257@cerise.gclements.plus.com> <17620.51752.396232.734623@cerise.gclements.plus.com> <44D6F7FF.3070409@club.worldonline.be> <17623.38630.975948.118205@cerise.gclements.plus.com> <44D84EEF.1070607@club.worldonline.be> <17624.51847.501435.796125@cerise.gclements.plus.com> Message-ID: <17624.63270.53623.603281@cerise.gclements.plus.com> Wolfgang wrote: > could anybody put somewhere a detailed description how to compile grass > on Cygwin (which packages, compilers, ...)? Not that I also would have > problems with speed, but I would like use some features which are not > (yet) in the prebuilt cygwin grass. Building on Cygwin isn't significantly different from building on a Unix system, except that you will probably need to build more of the dependent libraries yourself. In particular, note that Cygwin's Tcl/Tk isn't suitable for GRASS; you need to download the Tcl/Tk source and compile it yourself. Also, the latest Cygwin appears to have a problem with DLLs, so use --disable-shared. -- Glynn Clements From glynn at gclements.plus.com Tue Aug 8 22:56:31 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 8 22:56:34 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <20060808183100.GA31665@bartok.itc.it> References: <44D8421C.7050307@itc.it> <17624.52889.380949.901831@cerise.gclements.plus.com> <20060808183100.GA31665@bartok.itc.it> Message-ID: <17624.64127.559636.798029@cerise.gclements.plus.com> Markus Neteler wrote: > > > > We need to merge this with the new version I just posted on the WIKI. > > > > Definitely need to move this into the CVS. > > > > > > > > Markus, procedure? > > > > > > Yes, development via CVS is certainly easier. But I think that it should > > > not be added to GRASS 6.2. > > > > > > Proposal: > > > - I release GRASS 6.1.0 now > > > - and create the 6.2 release branch > > > - and rename CVS-HEAD to 6.3.cvs > > > > > > Then you could submit the new GUI to CVS. > > > Makes sense? > > > > Not to me. 3 active versions is one too many. > > > > Release 6.1.0 now, > > ... as suggested. > > > 6.1.x is stable (bugfix only), > > There are numerous fixes in CVS HEAD which are missing in 6.1.x > branch. That's why I suggested to make a new branch for 6.2 > (now!). I forgot to write that the current 6.1.x release branch > won't be maintained any more. But the 6.1 branch is less than a month old. How many fixes can there be which can't easily be merged into 6.1.x? I'm not sure that having two stable versions based upon HEAD snapshots only a month apart makes sense. -- Glynn Clements From neteler at itc.it Tue Aug 8 23:33:28 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Aug 8 23:33:30 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <17624.64127.559636.798029@cerise.gclements.plus.com> References: <44D8421C.7050307@itc.it> <17624.52889.380949.901831@cerise.gclements.plus.com> <20060808183100.GA31665@bartok.itc.it> <17624.64127.559636.798029@cerise.gclements.plus.com> Message-ID: <20060808213328.GC32069@bartok.itc.it> On Tue, Aug 08, 2006 at 09:56:31PM +0100, Glynn Clements wrote: > > Markus Neteler wrote: > > > > > > We need to merge this with the new version I just posted on the WIKI. > > > > > Definitely need to move this into the CVS. > > > > > > > > > > Markus, procedure? > > > > > > > > Yes, development via CVS is certainly easier. But I think that it should > > > > not be added to GRASS 6.2. > > > > > > > > Proposal: > > > > - I release GRASS 6.1.0 now > > > > - and create the 6.2 release branch > > > > - and rename CVS-HEAD to 6.3.cvs > > > > > > > > Then you could submit the new GUI to CVS. > > > > Makes sense? > > > > > > Not to me. 3 active versions is one too many. > > > > > > Release 6.1.0 now, > > > > ... as suggested. > > > > > 6.1.x is stable (bugfix only), > > > > There are numerous fixes in CVS HEAD which are missing in 6.1.x > > branch. That's why I suggested to make a new branch for 6.2 > > (now!). I forgot to write that the current 6.1.x release branch > > won't be maintained any more. > > But the 6.1 branch is less than a month old. How many fixes can there > be which can't easily be merged into 6.1.x? > > I'm not sure that having two stable versions based upon HEAD snapshots > only a month apart makes sense. I don't see a big difference (result) between (a) branching again (b) merging many things back The latter is much more effort. I currently have no time to do more backporting of changes. That's why I proposed (a). Markus From michael.barton at asu.edu Wed Aug 9 00:55:57 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Aug 9 00:56:11 2006 Subject: [GRASS-dev] New installation for wxPython GUI In-Reply-To: <6278879c0608080928r2e5ec6bfu8f08dd4efb15629f@mail.gmail.com> Message-ID: I figured out how to run gism.py from outside the directory where it lives. So now we can run it from a script on the GRASS command line without changing directories. There is a new distribution on my website (both tarzipped package and non-compressed files). For now, just drop the gmwxp folder into your $GISBASE/etc folder and the script "gm.wxp" into the $GISBASE/scripts folder. Then you can just type gm.wxp& from the GRASS command line to start the new GUI. It also reads the existing icon files, so you don't need the separate icon directory anymore. Michael __________________________________________ Michael Barton, Professor of Anthropology 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 ychemin at gmail.com Wed Aug 9 05:14:37 2006 From: ychemin at gmail.com (Yann Chemin) Date: Wed Aug 9 05:15:23 2006 Subject: [GRASS-dev] Re: New installation for wxPython GUI In-Reply-To: References: <6278879c0608080928r2e5ec6bfu8f08dd4efb15629f@mail.gmail.com> Message-ID: <6278879c0608082014x57eb480dra8b63797f1f48047@mail.gmail.com> Works nicely on my system! About "Zoom in" behaviour, i can replicate the reason why it displays a blank screen. 1-type d.rast elevation.dem 2-click in any point of the elevation map 3-becomes blank screen Now, here is the catch, if instead you try; 1-type d.rast elevation.dem 2-POINT and DRAG to create a (invisible on my computer) box in any AREA of the elevation map 3-map zooms in properly So it must be that "zom in" functionality should be allowed to zoom in by factor X (2?) if only a click in a point is made, or something like that... y On 09/08/06, Michael Barton wrote: > I figured out how to run gism.py from outside the directory where it lives. > So now we can run it from a script on the GRASS command line without > changing directories. > > There is a new distribution on my website (both tarzipped package and > non-compressed files). > > For now, just drop the gmwxp folder into your $GISBASE/etc folder and the > script "gm.wxp" into the $GISBASE/scripts folder. > > Then you can just type gm.wxp& from the GRASS command line to start the new > GUI. It also reads the existing icon files, so you don't need the separate > icon directory anymore. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > From glynn at gclements.plus.com Wed Aug 9 06:08:08 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Aug 9 06:08:30 2006 Subject: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <20060808213328.GC32069@bartok.itc.it> References: <44D8421C.7050307@itc.it> <17624.52889.380949.901831@cerise.gclements.plus.com> <20060808183100.GA31665@bartok.itc.it> <17624.64127.559636.798029@cerise.gclements.plus.com> <20060808213328.GC32069@bartok.itc.it> Message-ID: <17625.24488.15167.985808@cerise.gclements.plus.com> Markus Neteler wrote: > > But the 6.1 branch is less than a month old. How many fixes can there > > be which can't easily be merged into 6.1.x? > > > > I'm not sure that having two stable versions based upon HEAD snapshots > > only a month apart makes sense. > > I don't see a big difference (result) between > (a) branching again > (b) merging many things back The difference is that (b) allows you to choose which changes to merge, i.e. include simple bug fixes but not more destabilising changes. > The latter is much more effort. I currently have no time to > do more backporting of changes. That's why I proposed (a). In that case, my inclination would have been to simply move the 6.1 branch tag to the point where 6.2 would have been created. There doesn't appear to be much point in having an isolated 6.1 release for which any bugs will never be fixed. For me, the main question is: what would be the reason for a user to choose 6.1.0 over 6.2.0? -- Glynn Clements From michael.barton at asu.edu Wed Aug 9 06:46:09 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Aug 9 06:46:40 2006 Subject: [GRASS-dev] Re: New installation for wxPython GUI In-Reply-To: <6278879c0608082014x57eb480dra8b63797f1f48047@mail.gmail.com> Message-ID: Just tried it on a new Debian installation of one of my students today. He compiled wxPython from source today. Zoom works OK. Pan works but flickers a lot. Window resizing causes the window to blank. I'd like to try it on our Fedora Core 4 workstation too. For the pan, there is a slightly different kind of bitmap drag to try. If that doesn't work, I guess we'll have to try a buffered device context and see if it helps. Window resizing uses image scaling to give a visual image of the shrinking image during resizing. After resizing stops, GRASS (render.py) re-renders the image to fit the new window size. We can turn off image scaling and see what happens there. Michael __________________________________________ Michael Barton, Professor of Anthropology 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: Yann Chemin > Date: Wed, 9 Aug 2006 10:14:37 +0700 > To: Michael Barton , Grass Developers List > > Subject: Re: New installation for wxPython GUI > > Works nicely on my system! > > About "Zoom in" behaviour, i can replicate the reason why it displays > a blank screen. > > 1-type d.rast elevation.dem > 2-click in any point of the elevation map > 3-becomes blank screen > > Now, here is the catch, if instead you try; > 1-type d.rast elevation.dem > 2-POINT and DRAG to create a (invisible on my computer) box in any > AREA of the elevation map > 3-map zooms in properly > > So it must be that "zom in" functionality should be allowed to zoom in > by factor X (2?) if only a click in a point is made, or something like > that... > > y > > > On 09/08/06, Michael Barton wrote: >> I figured out how to run gism.py from outside the directory where it lives. >> So now we can run it from a script on the GRASS command line without >> changing directories. >> >> There is a new distribution on my website (both tarzipped package and >> non-compressed files). >> >> For now, just drop the gmwxp folder into your $GISBASE/etc folder and the >> script "gm.wxp" into the $GISBASE/scripts folder. >> >> Then you can just type gm.wxp& from the GRASS command line to start the new >> GUI. It also reads the existing icon files, so you don't need the separate >> icon directory anymore. >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> 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 soerengebbert at gmx.de Wed Aug 9 09:22:52 2006 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Wed Aug 9 09:22:59 2006 Subject: [GRASS-dev] GRASS C function names In-Reply-To: <17623.39018.604382.803737@cerise.gclements.plus.com> References: <200608071245.18383.soerengebbert@gmx.de> <17623.39018.604382.803737@cerise.gclements.plus.com> Message-ID: <200608090922.53137.soerengebbert@gmx.de> Hello Glynn, thank you for your suggestions. On Monday 07 August 2006 21:45, Glynn Clements wrote: > > Soeren Gebbert wrote: > > > i have a question about the function naming guidline of GRASS. > > I would like to add a guidline to the SUBMITTING file. > > > > But the problem is that we have two naming conventions > > for library functions in GRASS. > > The common convention is: G_fatal_error(), to place a "_" between the function description strings, > > but within the G3D library a different convention was used: G3d_fatalError(). > > > > Personally i like the function name convention of the G3D lib, because this > > convention is used in other libraries i am programming with and i think its better readable. > > So i named all the functions in my r3.* modules like the G3D lib standard. > > > > But i would like to see a uniform programming standard/API within GRASS, so what to do? > > > > Should the G3D library API be an exception and all the user defined function names should use > > the common API (G_name_name), or should the module developer decide on his own what convention to use? > > All of the core libraries use underscores rather than mixed case. The > only libraries which use mixed case are third-party add-ons which were > developed separately then incorporated into GRASS later. > > FWIW, I strongly prefer underscores; it's also the official GNU naming > convention. Very good, a clear statement. :) I will rename all functions i have created in my modules. I will also add this as coding standard to the submission guidline. > > > Or should we/i rename all G3D function names to meet the common convention? > > Well thats not impossible, but a huge amount of work (the testing and the docs). > > I don't consider renaming to be a priority. It might be worth doing if > the library was undergoing a major overhaul, but otherwise there are > better uses of developer time. I will put the "renaming" to the todo list for grass7, because i plan to extent/rewrite the documentation of this lib. Best regards Soeren From radim.blazek at gmail.com Wed Aug 9 09:58:46 2006 From: radim.blazek at gmail.com (Radim Blazek) Date: Wed Aug 9 09:58:52 2006 Subject: [GRASS-dev] G_list_element / G_popen Message-ID: <340505ef0608090058q501bbe4i5560d43cad783792@mail.gmail.com> Hi. There is a bug in G_list_element or G_popen, if GRASS_PAGER enviroment variable is not set g.list prints nothing because G_popen returns some a pipe (what pipe if cmd is empty?) instead of NULL. Try unset GRASS_PAGER g.list rast Radim From neteler at itc.it Wed Aug 9 10:06:45 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Aug 9 10:06:48 2006 Subject: Branching - was Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2 In-Reply-To: <17625.24488.15167.985808@cerise.gclements.plus.com> References: <44D8421C.7050307@itc.it> <17624.52889.380949.901831@cerise.gclements.plus.com> <20060808183100.GA31665@bartok.itc.it> <17624.64127.559636.798029@cerise.gclements.plus.com> <20060808213328.GC32069@bartok.itc.it> <17625.24488.15167.985808@cerise.gclements.plus.com> Message-ID: <20060809080645.GB4513@bartok.itc.it> On Wed, Aug 09, 2006 at 05:08:08AM +0100, Glynn Clements wrote: > Markus Neteler wrote: > > > > But the 6.1 branch is less than a month old. How many fixes can there > > > be which can't easily be merged into 6.1.x? > > > > > > I'm not sure that having two stable versions based upon HEAD snapshots > > > only a month apart makes sense. > > > > I don't see a big difference (result) between > > (a) branching again > > (b) merging many things back > > The difference is that (b) allows you to choose which changes to > merge, i.e. include simple bug fixes but not more destabilising > changes. > > > The latter is much more effort. I currently have no time to > > do more backporting of changes. That's why I proposed (a). > > In that case, my inclination would have been to simply move the 6.1 > branch tag to the point where 6.2 would have been created. There > doesn't appear to be much point in having an isolated 6.1 release for > which any bugs will never be fixed. Sounds absolutely reasonable to me. It wasn't clear to me that this is possible (I only knew about tag shifting; since a branch is more or less a tag it maybe works the same way?). Have to get out my CVS book for that if noone else shifts the branch. > For me, the main question is: what would be the reason for a user to > choose 6.1.0 over 6.2.0? No real reason despite the time lag (6.1.0 we can have today, for 6.2.0 we would make a beta first). Again, I think that there are some relevant changes which 6.2.0 do not want to miss (means: no simple rename of 6.1.0 to 6.2.0) such as no more low limit of open raster maps, MingW/Cygwin fixes and other recent things. We should keep in mind that 6.2.x will be around for a while and that e.g. QGIS builds on top of it. For distros like Debian, Gentoo, Mandriva where packages depend on each other this makes a difference. But that's maybe only my opinion. Probably our opinions aren't that far from each other? Markus From mlennert at club.worldonline.be Wed Aug 9 11:28:01 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Aug 9 11:28:03 2006 Subject: [GRASS-dev] New installation for wxPython GUI In-Reply-To: References: Message-ID: <44D9AAA1.2000305@club.worldonline.be> Michael, Michael Barton wrote: > I figured out how to run gism.py from outside the directory where it lives. > So now we can run it from a script on the GRASS command line without > changing directories. great ! A few issues (using python 2.4.3 and wxpython 2.6.3.3 - installed on Debian from rpms using alien - so there might be some problems with that - I'll compile from source when I find the time): - the display does not automatically redraw when I drag another window over it. I have to click the display map button. - I still have the panning problem. What it seems to be is that the program does not release the mouse, so even if the mouse is outside the window it still continues to pan. The only solution still is to switch to another workspace and back. Then the map is gone, but the mouse is usable again. - When I launch a command I get the correct command window, but any subsequent command launched will give me the same window (i.e. containing the options of the first command launched) except for the title which correctly indicates the name of the command launched. Seems like there needs to be some reinitialisation done. - Are the add raster and add vector buttons already supposed to do anything else then add to the list in the layers tab ? - It would be great if the console could react to 'Enter', except having to take up the mouse again and click run. From mlennert at club.worldonline.be Wed Aug 9 12:14:12 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Aug 9 12:14:13 2006 Subject: [GRASS-dev] Re: New installation for wxPython GUI In-Reply-To: <6278879c0608082014x57eb480dra8b63797f1f48047@mail.gmail.com> References: <6278879c0608080928r2e5ec6bfu8f08dd4efb15629f@mail.gmail.com> <6278879c0608082014x57eb480dra8b63797f1f48047@mail.gmail.com> Message-ID: <44D9B574.9080502@club.worldonline.be> Yann Chemin wrote: > Works nicely on my system! > > About "Zoom in" behaviour, i can replicate the reason why it displays > a blank screen. > > 1-type d.rast elevation.dem > 2-click in any point of the elevation map > 3-becomes blank screen Same here > > Now, here is the catch, if instead you try; > 1-type d.rast elevation.dem > 2-POINT and DRAG to create a (invisible on my computer) box in any > AREA of the elevation map > 3-map zooms in properly Same here. But the box is only invisible in zoom in, and only as long as I have not used zoom out. In zoom out mode, I see the box. However, I actually see many boxes within each other which is not very beautiful (see http://moritz.homelinux.org/grass/gmwxp_zoomin1.png). Probably just a question of erasing the previous box before redrawing the newly sized one. Another problem with zooming in: the displayed area does not always correspond to the rectangle. Compare http://moritz.homelinux.org/grass/gmwxp_zoomin1.png to http://moritz.homelinux.org/grass/gmwxp_zoomin2.png which is the state after the zooming defined in zoomin1.png. Mouse wheel zooming works perfectly ! Moritz From hamish_nospam at yahoo.com Wed Aug 9 12:39:45 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Aug 9 12:39:48 2006 Subject: Branching - was Re: [GRASS-dev] WxPython prototype GRASS GUI. Message-ID: <20060809103945.31128.qmail@web52705.mail.yahoo.com> Hi & greetings from the top of a rainforest clad mountain in northern Australia. (wireless internet access in the darnedest of places these days) >> For me, the main question is: what would be the reason for a user to >> choose 6.1.0 over 6.2.0? > > No real reason despite the time lag (6.1.0 we can have today, > for 6.2.0 we would make a beta first). As soon as 6.1.0 is released that branch is dead*, and we focus on the 6.2 release. I don't expect anyone wants to work on a 6.1.1. Much less confusing to release 6.1 now, then 6.2 in a month, than the mess of renaming branches. We know releasebranch6.1 isn't perfect. Well, so what?? I can live with that knowing that 6.2 will be out soon. * (no 6.1.1 unless there is some horrible bug) Perhaps we should think of 6.1.0 as a beta 6.2 release in practice if not in name. I suggest we amend the 6.1.0 release announcement/blurb to make it clear that 6.2 is /just/ around the corner (it already sort of says this in the first sentence of the announcement), then release 6.1.0 in the next days. Maybe change "feature release" to "preview release". Then I'd consider the 6.1.0 release as getting packagers ready for 6.2, not as requiring them to do two repeat packagings (packaging 6.2 should be trivial after they've done 6.1). We are so close to a 6.1.0 release, and I see no compelling reason not to release it now. go! go! go! Hamish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From blackhex at post.cz Wed Aug 9 13:54:25 2006 From: blackhex at post.cz (Radek =?iso-8859-2?q?Barto=F2?=) Date: Wed Aug 9 13:54:33 2006 Subject: [GRASS-dev] Project management software. Message-ID: <200608091354.26525.blackhex@post.cz> Hello everyone. I'm starting to be a GRASS programmer but one thing that really surprised me is that such a big project isn't using any project management software. Some time ago I was looking for such a tool and found great opensource project Trac - http://trac.edgewall.org/ . Even there are a lot of features which should has that kind of software I was really nicely surprised when get known that Trac offers smart components architecture which makes easy to extend it. So I become developer of five of them (ScreenshotsPlugin, DoxygenPlugin, DiscussionPlugin, ...) which are placed on http://trac-hack.org with many others. Please consider this oportunity to make a good choice to speed up and clearify GRASS development using this or some other project management software. To explain what features Trac offers here is a simple list: - All is written in Python with sqlite or PosgreSQL database backend and Apache, FastCGI or even its own web server. - Tickets (similar to bug reports) which can be assigned to any registered developer and component with given priority and severity. - Milestones which are made of tickets, whent tickets are performed milestones' progres is rising. - Easy extensible wiki with syntax highlighting. - Subversion support with web-based source browsing (Subversion might be problem). - A lot of gorgeous plugins and macros. I can make any others of your neeeds. Thank you for reading this e-mail, Radek Barto?. From mlennert at club.worldonline.be Wed Aug 9 14:11:13 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Aug 9 14:11:14 2006 Subject: [GRASS-dev] New installation for wxPython GUI In-Reply-To: <44D9AAA1.2000305@club.worldonline.be> References: <44D9AAA1.2000305@club.worldonline.be> Message-ID: <44D9D0E1.7040701@club.worldonline.be> Moritz Lennert wrote: > Michael, > > Michael Barton wrote: >> I figured out how to run gism.py from outside the directory where it >> lives. >> So now we can run it from a script on the GRASS command line without >> changing directories. > > great ! > > A few issues (using python 2.4.3 and wxpython 2.6.3.3 - installed on > Debian from rpms using alien - so there might be some problems with that > - I'll compile from source when I find the time): > > - the display does not automatically redraw when I drag another window > over it. I have to click the display map button. Adding a simple self.ReDraw(event=None) at the end of def onFocus(self, event) in mapdisp.py at least displays the map automatically when I refocus on the map display. > > - I still have the panning problem. What it seems to be is that the > program does not release the mouse, so even if the mouse is outside the > window it still continues to pan. The only solution still is to switch > to another workspace and back. Then the map is gone, but the mouse is > usable again. Actually, the fact that the map is gone is the same problem as the previous. So whenever the map display is not visible (beneath another window or on another workspace) and then becomes visible again, it is empty. The little ReDraw hack above allows to get it back just through focus, but that's not much different from clicking on display map. > > - When I launch a command I get the correct command window, but any > subsequent command launched will give me the same window (i.e. > containing the options of the first command launched) except for the > title which correctly indicates the name of the command launched. Seems > like there needs to be some reinitialisation done. > > - Are the add raster and add vector buttons already supposed to do > anything else then add to the list in the layers tab ? > > - It would be great if the console could react to 'Enter', except having > to take up the mouse again and click run. Here's a small hack to do this. As the command window is not defined as multiline, I don't think that Enter has any other usage. --- gism.py 2006-08-09 00:38:38.000000000 +0200 +++ ../../py_gm_new/gmwxp/gism.py 2006-08-09 14:08:15.000000000 +0200 @@ -56,7 +56,8 @@ self.notebook_1_pane_2 = wx.Panel(self.notebook_1, -1, style=wx.FULL_REPAINT_ON_RESIZE) self.console_output = wx.TextCtrl(self.notebook_1_pane_3, -1, "", style=wx.TE_MULTILINE|wx.TE_READONLY|wx.HSCROLL) - self.console_command = wx.TextCtrl(self.notebook_1_pane_3, -1, "", style=wx.HSCROLL|wx.TE_LINEWRAP) + self.console_command = wx.TextCtrl(self.notebook_1_pane_3, -1, "", style=wx.HSCROLL|wx.TE_LINEWRAP|wx.TE_PROCESS_ENTER) + wx.EVT_TEXT_ENTER ( self.notebook_1_pane_3, -1, self.RunCmd ) self.console_run = wx.Bu