Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, (using this to hide the info :) we seem to be ready for the public announcement, no complaints so far and a large number of binaries are meanwhile online. Martin and me (and others) are here in Barcelona at the FOSS4G2010, so we will send out the announcement in a few hours if there aren't any objections. cheers Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Sat, Sep 4, 2010 at 1:13 AM, Helmut Kudrnovsky hel...@web.de wrote: Done and done :) Once the relevant binaries are online, we can post the big announcement and upload the updated rss.xml for the news box. cheers Markus WinGRASS-6.4.0-1-Setup.exe is ready. :o) In the server now. On Sat, Sep 4, 2010 at 2:58 AM, William Kyngesburye wokl...@kyngchaos.com wrote: Mac package is ready. We can go official soon, right? thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Wed, Sep 1, 2010 at 11:02 PM, Helmut Kudrnovsky hel...@web.de wrote: maybe http://trac.osgeo.org/grass/ticket/1143 should be fixed? since this one was also fixed. I suggest to release later today. Few hours left before FOSS4G 2010! Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Fri, 2010-09-03 at 12:25 +0200, Martin Landa wrote: Hi, 2010/9/3 Markus Neteler nete...@osgeo.org: On Wed, Sep 1, 2010 at 11:02 PM, Helmut Kudrnovsky hel...@web.de wrote: maybe http://trac.osgeo.org/grass/ticket/1143 should be fixed? since this one was also fixed. I suggest to release later today. Few hours left before FOSS4G 2010! +1 for today. Martin +1 for today from me as well. Anne -- http://wiki.osgeo.org/wiki/Anne_Ghisla signature.asc Description: This is a digitally signed message part ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Anne Ghisla: Martin Landa: Hi, Markus Neteler: Helmut Kudrnovsky: maybe http://trac.osgeo.org/grass/ticket/1143 should be fixed? since this one was also fixed. I suggest to release later today. Few hours left before FOSS4G 2010! +1 for today. Martin +1 for today from me as well. +1 for today from me too. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Date: Fri, 3 Sep 2010 17:09:04 +0200 From: Markus Metz markus.metz.gisw...@googlemail.com Subject: Re: [GRASS-dev] 6.4.0 blocker bugs To: GRASS developers list grass-dev@lists.osgeo.org Message-ID: aanlktikx+h1pnpkevzabvnqwcvftt4uj07tegxxtd...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Anne Ghisla: Martin Landa: Hi, Markus Neteler: Helmut Kudrnovsky: maybe http://trac.osgeo.org/grass/ticket/1143 should be fixed? since this one was also fixed. I suggest to release later today. Few hours left before FOSS4G 2010! +1 for today. Martin +1 for today from me as well. +1 for today from me too. Markus M +1 for me. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Done and done :) Once the relevant binaries are online, we can post the big announcement and upload the updated rss.xml for the news box. cheers Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Mac package is ready. On Sep 3, 2010, at 3:55 PM, Markus Neteler wrote: Done and done :) Once the relevant binaries are online, we can post the big announcement and upload the updated rss.xml for the news box. cheers Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, we get close to one week after release (and close to FOSS4G 2010). In trac http://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalmilestone=6.4.0 the known reports remained so far, non blocker. It seems that we are at a good point, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/23 Helmut Kudrnovsky hel...@web.de: Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with ~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with the wxGUI. At this point we should do it for the rest of the users, too. I'd really like to avoid to be flooded with messages of where is the new GUI?? content since the standard Linux distros will package whatever is set in the software. Markus there was so much effort to create a new and working gui (wxgui) which will be the next generation user interface. from my point of view is unacceptable to change the default GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e. before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0. IMHO this should be honored a lot and the wxgui should be considered as the default in the upcoming grass64-release, mainly to get feedback and being able to improve this interface. on windows - I've played a lot with grass64/65/70-versions - I've almost never used the tcltk-gui. so I vote for wxgui as the default for all os-platforms. As a wxGUI developer I cannot judge which GUI should be default. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Martin wrote: from my point of view is unacceptable to change the default GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e. before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0. I don't think it harms backwards compatibility too badly to adjust GUI things (scripts+code will still work), but y'all make a good point that tutorials and screenshot guides will suffer in this case. We can get around the don't make big policy changes right before release rule by shipping one last RC; I would hope the the final 6.4.0 could go out after that rather quickly (maybe a week?). So RC7 in the next 24 hrs and 6.4.0 some time before Helena's plenary session on Sept 8th? (as long as no problems are found within that time..) (comments? objections? better ideas?) I think we all agree that by 6.4.1 wx should be the default, and that big changes are bad within a stable release. Since we have had so many RCs wx is now in good shape in the stable branch, ready for more eyeballs. so ok with me to be the default, so long as that change gets tested. I would note that besides init.sh there is also line 83 of g.gui/main.c to change in relbr64 to alter the default GUI (which GUI to start if GRASS_GUI=text), and a grep of the docs/announcements. We would have to check that it fail-overs back to tcltk if tcl is there but wx is not. (I have a Debian/etch machine sitting around I can test that on) fwiw, changing it manually is not /too/ hard to find: Config - GRASS working enivronment - Change default GUI ... but you have to know about it before you'd ever think to look. As for ctypes backports, AFAICT that is not well tested in 6.5 yet, so I'm a bit worried to put it into 6.4 yet. Is it just copying in lib/python/ctypes/, or are other structural changes that need to be coordinated with that? As AFAIK it is only a new feature, and not really a policy change or bugfix, so I see no problem to wait for 6.4.1, 4 weeks or so after the main release. cheers, Hamish ps- I wonder if we should really expose g.mapset in the GUI menu? Some Advanced features are best hidden from new users.. ( I take it that works well from the now?) or at least only let them change mapset from there, to limit damage/confusion. (??) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/24 Hamish hamis...@yahoo.com: from my point of view is unacceptable to change the default GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e. before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0. I don't think it harms backwards compatibility too badly to adjust GUI things (scripts+code will still work), but y'all make a good point that tutorials and screenshot guides will suffer in this case. We can get around the don't make big policy changes right before release rule by shipping one last RC; I would hope the the final 6.4.0 could go out after that rather quickly (maybe a week?). So RC7 in the next 24 hrs and 6.4.0 some time before Helena's plenary session on Sept 8th? (as long as no problems are found within that time..) (comments? objections? better ideas?) I think we all agree that by 6.4.1 wx should be the default, and that big changes are bad within a stable release. Since we have had so many RCs wx is now in good shape in the stable branch, ready for more eyeballs. so ok with me to be the default, so long as that change gets tested. I would note that besides init.sh there is also line 83 of g.gui/main.c to change in relbr64 to alter the default GUI (which GUI to start if GRASS_GUI=text), and a grep of the docs/announcements. We would have to check that it fail-overs back to tcltk if tcl is there but wx is not. (I have a Debian/etch machine sitting around I can test that on) fwiw, changing it manually is not /too/ hard to find: Config - GRASS working enivronment - Change default GUI ... but you have to know about it before you'd ever think to look. OK, if I understand well, you are suggesting to change the default GUI to wxpython, release today/tomorrow RC7 and within one week to release 6.4.0, is it right? If so, I agree. As for ctypes backports, AFAICT that is not well tested in 6.5 yet, so I'm a bit worried to put it into 6.4 yet. Is it just copying in lib/python/ctypes/, or are other structural changes that need to be coordinated with that? As AFAIK it is only a new feature, and not really a policy change or bugfix, so I see no problem to wait for 6.4.1, 4 weeks or so after the main release. OK, ctypes is quite advance feature and will be used by wxNviz and wxVdigit (not ready). So it can wait for 6.4.1. It's just not a standard approach to add new features within x.y.z. On the other hand, 1.5 year for RCs is also not standard ;-) Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Tue, Aug 24, 2010 at 11:28 AM, Hamish hamis...@yahoo.com wrote: We can get around the don't make big policy changes right before release rule by shipping one last RC; I would hope the the final 6.4.0 could go out after that rather quickly (maybe a week?). So RC7 in the next 24 hrs and 6.4.0 some time before Helena's plenary session on Sept 8th? Yes. Please change the default GUI and I'll prepare RC7 then immediately. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus wrote: Please change the default GUI and I'll prepare RC7 then immediately. the change is now done. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus wrote: Please change the default GUI and I'll prepare RC7 then immediately. release summary now prepared from svn log: https://trac.osgeo.org/grass/wiki/Release/6.4.0RC7-News (except for final details of course..) clean as needed, enjoy the new trac wiki edit-by-section, just click on the hidden [edit] to the right of each section heading. e.g. I'm sure r.watershed: upgraded to improved version and r.out.gdal improvements could be better explained. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/24 Hamish hamis...@yahoo.com: Please change the default GUI and I'll prepare RC7 then immediately. winGRASS for quick testing is available at http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r43230-1-Setup.exe Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Aug 24, 2010, at 7:55 AM, Hamish wrote: Markus wrote: Please change the default GUI and I'll prepare RC7 then immediately. release summary now prepared from svn log: https://trac.osgeo.org/grass/wiki/Release/6.4.0RC7-News (except for final details of course..) clean as needed, enjoy the new trac wiki edit-by-section, just click on the hidden [edit] to the right of each section heading. e.g. I'm sure r.watershed: upgraded to improved version and r.out.gdal improvements could be better explained. Hamish I updated the Mac startup so it should let init.sh set the default. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
I'm OK with this plan too. I just don't want to see 6.4 delayed OR released broken. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Aug 24, 2010, at 2:28 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Tue, 24 Aug 2010 02:28:29 -0700 (PDT) From: Hamish hamis...@yahoo.com Subject: Re: [GRASS-dev] 6.4.0 blocker bugs To: Martin Landa landa.mar...@gmail.com Cc: grass-dev@lists.osgeo.org Message-ID: 108761.7...@web110005.mail.gq1.yahoo.com Content-Type: text/plain; charset=us-ascii Martin wrote: from my point of view is unacceptable to change the default GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e. before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0. I don't think it harms backwards compatibility too badly to adjust GUI things (scripts+code will still work), but y'all make a good point that tutorials and screenshot guides will suffer in this case. We can get around the don't make big policy changes right before release rule by shipping one last RC; I would hope the the final 6.4.0 could go out after that rather quickly (maybe a week?). So RC7 in the next 24 hrs and 6.4.0 some time before Helena's plenary session on Sept 8th? (as long as no problems are found within that time..) (comments? objections? better ideas?) I think we all agree that by 6.4.1 wx should be the default, and that big changes are bad within a stable release. Since we have had so many RCs wx is now in good shape in the stable branch, ready for more eyeballs. so ok with me to be the default, so long as that change gets tested. I would note that besides init.sh there is also line 83 of g.gui/main.c to change in relbr64 to alter the default GUI (which GUI to start if GRASS_GUI=text), and a grep of the docs/announcements. We would have to check that it fail-overs back to tcltk if tcl is there but wx is not. (I have a Debian/etch machine sitting around I can test that on) fwiw, changing it manually is not /too/ hard to find: Config - GRASS working enivronment - Change default GUI ... but you have to know about it before you'd ever think to look. As for ctypes backports, AFAICT that is not well tested in 6.5 yet, so I'm a bit worried to put it into 6.4 yet. Is it just copying in lib/python/ctypes/, or are other structural changes that need to be coordinated with that? As AFAIK it is only a new feature, and not really a policy change or bugfix, so I see no problem to wait for 6.4.1, 4 weeks or so after the main release. cheers, Hamish ps- I wonder if we should really expose g.mapset in the GUI menu? Some Advanced features are best hidden from new users.. ( I take it that works well from the now?) or at least only let them change mapset from there, to limit damage/confusion. (??) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/18 Helena Mitasova hmit...@unity.ncsu.edu: as Hamish has noted the choice of the default GUI is decided by whoever does the binary package (?). the default (or initial) GUI is set in init.sh [1]. The packager can include rc file to overwrite the settings. My suggestion is to change the default GUI directly in init.sh. Changing this variable between 6.4.0 and 6.4.1 seems to big quite big change when considering releasing policy. Martin [1] http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/init/init.sh#L28 -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Mon, Aug 23, 2010 at 5:07 PM, Martin Landa landa.mar...@gmail.com wrote: 2010/8/18 Helena Mitasova hmit...@unity.ncsu.edu: ... My suggestion is to change the default GUI directly in init.sh. Changing this variable between 6.4.0 and 6.4.1 seems to big quite big change when considering releasing policy. Additionally it is a pain to prepare tutorial - you don't want to replicate everything with then quickly outdating screenshots for Mac + Linux users when a new GUI is there and already default on winGRASS... On Wed, Aug 18, 2010 at 5:26 AM, Hamish hamis...@yahoo.com wrote: ... Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with ~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with the wxGUI. At this point we should do it for the rest of the users, too. I'd really like to avoid to be flooded with messages of where is the new GUI?? content since the standard Linux distros will package whatever is set in the software. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
I got similar expierience with my students during last spring - those, who where able to wrap their minds around GRASS concepts, found old TCL/Tk GUI to be faster and thus better than Wx one on Windows. Some issues they hit then now are solved, still wxgui doesn't perform as good as tcl/tk one (can I select multiple maps at once?). TCL/Tk one has (serious) issues and wx one is way to go, still not yet today. As a developer I would vote no for GUI change. As of ctypes - if it delays release, then also no - it has been too long release cycle. There are some other more important problems than ctypes (v.buffer issues etc.). Just my 0.02, Maris. 2010/8/18, Michael Barton michael.bar...@asu.edu: While I echo some of Helena's sentiments, I find that (surprisingly) even some of my students still prefer the TclTk interface of the wxPython one. That aside, it doesn't bother me if TclTk comes as a default on Mac and Linux, as this gives people a very smooth transition into the new GUI. They can easily turn it on as the default when they are ready, but they can start out with what they are more used to with prior versions. For MS Windows there really hasn't been a widely used prior version. So starting out with wxPython will make future updates easier. Beyond this, the Mac version works fine. TclTk nviz is a richer environment than the embedded wxPython one. The wxPython digitizing module works well. AFAICT, the rest works fine too. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Helmut: regarding ctypes, IMHO we are on a good way that compiling ctypes on windows is solved now. see http://trac.osgeo.org/grass/ticket/1125#comment:31 so I would opt to include ctypes in grass64 It is very good news/work indeed, and I fully support its inclusion in 6.4.x, but as it hasn't even been backported yet, let alone had more than 1 day's testing in trunk it means yet another delay. For starters it needs to be backported to 6.5svn and tested there. I think the main point to consider is if this is a critical bug or not. And if it is not a RC bug, on what grounds are we delaying release for it? 6.4.1 could be released just 4 weeks after 6.4.0, and IMO it is rather valuable to have the solid/ known good delta to compare against. += 2c, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/18 Hamish hamis...@yahoo.com: 2010/8/12 Markus Neteler: So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1, this option has my vote. Release now, as-is, and add ctypes for 6.4.1. (ok, I've just gotten off an airplane, gimme 24 hours for final tests on linux and windowsXP now that swig is removed :) did swig/examples/ get moved away before the rm? or even make a separate package which works with 6.4.0 no thanks, too messy. Just release 6.4.1 with it in 3-5 weeks +1 RC. what's difference RC7 now and in 2 two weeks 6.4.0? re. default GUI, again my vote is to release now, as-is. aka don't make major code or policy changes in the last moments before release, no matter how attractive it seems short-term. I would note that we are default tcl/tk; only the downstream packagers for WinGrass and Mac have decided to change it to Wx in their packages. (Ok, with the possible exception of j...@osgeo4w downstream is mostly just us anyway, but technically speaking..) actually WinGrass is only default as for the icon it sticks on the desktop. from the menu there is a grass64 -tcltk option and a grass64 -wxpython option. Each will technically reset the default GUI each time you call it. Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with ~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with the wxGUI. Switching the GUI is very easy from the Config menu, and even if it is step 1. it shows the user that other avenues exist if they run into a problem with e.g. the wx digitizer tool. Changing default GUI in 6.4.1 released in 3-5 weeks seems to be strange to me. The question is whether to change default GUI in 6.4. I cannot tell if wxGUI is robust enough. It should decide the community. To summarize: 6.4.0 release now and in 3-5 weeks release 6.4.1 with quite *major* changes (ctypes added, default GUI changes) seems to me as an overkill. Just my opinion. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Aug 17, 2010, at 11:24 PM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org wrote: Date: Tue, 17 Aug 2010 20:26:42 -0700 (PDT) From: Hamish hamis...@yahoo.com Subject: Re: [GRASS-dev] 6.4.0 blocker bugs To: GRASS developers list grass-dev@lists.osgeo.org Message-ID: 64190.6834...@web110015.mail.gq1.yahoo.com Content-Type: text/plain; charset=us-ascii 2010/8/12 Markus Neteler: So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1, this option has my vote. Release now, as-is, and add ctypes for 6.4.1. (ok, I've just gotten off an airplane, gimme 24 hours for final tests on linux and windowsXP now that swig is removed :) did swig/examples/ get moved away before the rm? or even make a separate package which works with 6.4.0 no thanks, too messy. Just release 6.4.1 with it in 3-5 weeks +1 RC. re. default GUI, again my vote is to release now, as-is. aka don't make major code or policy changes in the last moments before release, no matter how attractive it seems short-term. I would note that we are default tcl/tk; only the downstream packagers for WinGrass and Mac have decided to change it to Wx in their packages. (Ok, with the possible exception of j...@osgeo4w downstream is mostly just us anyway, but technically speaking..) actually WinGrass is only default as for the icon it sticks on the desktop. from the menu there is a grass64 -tcltk option and a grass64 -wxpython option. Each will technically reset the default GUI each time you call it. Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with ~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with the wxGUI. Switching the GUI is very easy from the Config menu, and even if it is step 1. it shows the user that other avenues exist if they run into a problem with e.g. the wx digitizer tool. thanks, Hamish I have to agree with Hamish here. We have delayed for over a year. Getting GRASS to run robustly on Windows is worth it. But I'm not convinced that moving ctypes into 6.4 would be all that easy. Watching the issues for Windows compiling of GRASS 7 is worrisome in this regard. 6.4 works fine as is now. Let's release it and make it a bit better with 6.4.1 Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Wed, Aug 18, 2010 at 7:39 PM, Michael Barton michael.bar...@asu.edu wrote: On Aug 17, 2010, at 11:24 PM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org wrote: ... I have to agree with Hamish here. We have delayed for over a year. Getting GRASS to run robustly on Windows is worth it. But I'm not convinced that moving ctypes into 6.4 would be all that easy. Watching the issues for Windows compiling of GRASS 7 is worrisome in this regard. 6.4 works fine as is now. Let's release it and make it a bit better with 6.4.1 Please also post your opinion about (Mac, Linux): - Release 6.4.0 with TclTK default GUI and switch in 6.4.1 to wxGUI as default; - Do first RC7 with wxGUI as default, then release 6.4.0, don't change with 6.4.1. ? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
as Hamish has noted the choice of the default GUI is decided by whoever does the binary package (?). So my plea was pretty much for William to make wxGUI default in his Mac binary. People who run linux or compile GRASS from source are generally used to customizing so that is not so much an issue. It is really for newcomers who download GRASS binary and start GRASS and then the first thing they have to deal with is to change GUI. The biggest issue that the newcomers had with the TclTk GUI (and that was solved in wxGUI) was - why the map is not displayed when I load it into gis manager? All of this made starting with GRASS on Mac unexpectedly more difficult than on MSWindows. At this point our semester has already started so I will have to deal with it , and if I understand the process correctly, 6.4 can be released with TclTk as default but with MSW and Mac binaries packaged with wxGUI as default. Of course, I would much prefer if the release was with wxGUI as default. I don't have enough expertise on ctypes but we have troubles with it on our enterprise linux when compiling, but that is just a local problem, Helena On Aug 18, 2010, at 2:29 PM, Markus Neteler wrote: On Wed, Aug 18, 2010 at 7:39 PM, Michael Barton michael.bar...@asu.edu wrote: On Aug 17, 2010, at 11:24 PM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org wrote: ... I have to agree with Hamish here. We have delayed for over a year. Getting GRASS to run robustly on Windows is worth it. But I'm not convinced that moving ctypes into 6.4 would be all that easy. Watching the issues for Windows compiling of GRASS 7 is worrisome in this regard. 6.4 works fine as is now. Let's release it and make it a bit better with 6.4.1 Please also post your opinion about (Mac, Linux): - Release 6.4.0 with TclTK default GUI and switch in 6.4.1 to wxGUI as default; - Do first RC7 with wxGUI as default, then release 6.4.0, don't change with 6.4.1. ? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
I'll follow whatever is decided. I probably don't need to set a default GRASS_GUI in the Mac startup (just let init.sh handle the default), except that I do need to make *some* assumption about a setting to work around an application focus issue in OSX Tiger. I'll see if I can figure out a less intrusive test for the GUI setting. On Aug 18, 2010, at 1:58 PM, Helena Mitasova wrote: as Hamish has noted the choice of the default GUI is decided by whoever does the binary package (?). So my plea was pretty much for William to make wxGUI default in his Mac binary. People who run linux or compile GRASS from source are generally used to customizing so that is not so much an issue. It is really for newcomers who download GRASS binary and start GRASS and then the first thing they have to deal with is to change GUI. The biggest issue that the newcomers had with the TclTk GUI (and that was solved in wxGUI) was - why the map is not displayed when I load it into gis manager? All of this made starting with GRASS on Mac unexpectedly more difficult than on MSWindows. At this point our semester has already started so I will have to deal with it , and if I understand the process correctly, 6.4 can be released with TclTk as default but with MSW and Mac binaries packaged with wxGUI as default. Of course, I would much prefer if the release was with wxGUI as default. I don't have enough expertise on ctypes but we have troubles with it on our enterprise linux when compiling, but that is just a local problem, Helena - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
While I echo some of Helena's sentiments, I find that (surprisingly) even some of my students still prefer the TclTk interface of the wxPython one. That aside, it doesn't bother me if TclTk comes as a default on Mac and Linux, as this gives people a very smooth transition into the new GUI. They can easily turn it on as the default when they are ready, but they can start out with what they are more used to with prior versions. For MS Windows there really hasn't been a widely used prior version. So starting out with wxPython will make future updates easier. Beyond this, the Mac version works fine. TclTk nviz is a richer environment than the embedded wxPython one. The wxPython digitizing module works well. AFAICT, the rest works fine too. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Aug 18, 2010, at 11:58 AM, Helena Mitasova wrote: as Hamish has noted the choice of the default GUI is decided by whoever does the binary package (?). So my plea was pretty much for William to make wxGUI default in his Mac binary. People who run linux or compile GRASS from source are generally used to customizing so that is not so much an issue. It is really for newcomers who download GRASS binary and start GRASS and then the first thing they have to deal with is to change GUI. The biggest issue that the newcomers had with the TclTk GUI (and that was solved in wxGUI) was - why the map is not displayed when I load it into gis manager? All of this made starting with GRASS on Mac unexpectedly more difficult than on MSWindows. At this point our semester has already started so I will have to deal with it , and if I understand the process correctly, 6.4 can be released with TclTk as default but with MSW and Mac binaries packaged with wxGUI as default. Of course, I would much prefer if the release was with wxGUI as default. I don't have enough expertise on ctypes but we have troubles with it on our enterprise linux when compiling, but that is just a local problem, Helena On Aug 18, 2010, at 2:29 PM, Markus Neteler wrote: On Wed, Aug 18, 2010 at 7:39 PM, Michael Barton michael.bar...@asu.edu wrote: On Aug 17, 2010, at 11:24 PM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org wrote: ... I have to agree with Hamish here. We have delayed for over a year. Getting GRASS to run robustly on Windows is worth it. But I'm not convinced that moving ctypes into 6.4 would be all that easy. Watching the issues for Windows compiling of GRASS 7 is worrisome in this regard. 6.4 works fine as is now. Let's release it and make it a bit better with 6.4.1 Please also post your opinion about (Mac, Linux): - Release 6.4.0 with TclTK default GUI and switch in 6.4.1 to wxGUI as default; - Do first RC7 with wxGUI as default, then release 6.4.0, don't change with 6.4.1. ? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, On Fri, Aug 13, 2010 at 6:03 PM, Martin Landa landa.mar...@gmail.com wrote: 2010/8/12 Markus Neteler nete...@osgeo.org: So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1, or even make a separate package which works with 6.4.0 (so long as we don't change the API, we would just need to ensure that grass.py contains the correct definition for GIS_H_VERSION so that G_gisinit() works). on the other hand what can cost to add ctypes now. One RC? That's acceptable. I would suggest to add ctypes now, publish RC7 and in one/two weeks final (before FOSS4G 2010). Stable will be released with ctypes and without swig. @developers: please give your opinion on Martin's suggestion. thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/17 Markus Neteler nete...@osgeo.org: On Fri, Aug 13, 2010 at 6:03 PM, Martin Landa landa.mar...@gmail.com wrote: 2010/8/12 Markus Neteler nete...@osgeo.org: So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1, or even make a separate package which works with 6.4.0 (so long as we don't change the API, we would just need to ensure that grass.py contains the correct definition for GIS_H_VERSION so that G_gisinit() works). on the other hand what can cost to add ctypes now. One RC? That's acceptable. I would suggest to add ctypes now, publish RC7 and in one/two weeks final (before FOSS4G 2010). Stable will be released with ctypes and without swig. + consolidate default GUI on all platforms - current situation (TCL/TK on Linux and Mac and wxGUI on Windows) is confusing. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
2010/8/12 Markus Neteler: So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1, this option has my vote. Release now, as-is, and add ctypes for 6.4.1. (ok, I've just gotten off an airplane, gimme 24 hours for final tests on linux and windowsXP now that swig is removed :) did swig/examples/ get moved away before the rm? or even make a separate package which works with 6.4.0 no thanks, too messy. Just release 6.4.1 with it in 3-5 weeks +1 RC. re. default GUI, again my vote is to release now, as-is. aka don't make major code or policy changes in the last moments before release, no matter how attractive it seems short-term. I would note that we are default tcl/tk; only the downstream packagers for WinGrass and Mac have decided to change it to Wx in their packages. (Ok, with the possible exception of j...@osgeo4w downstream is mostly just us anyway, but technically speaking..) actually WinGrass is only default as for the icon it sticks on the desktop. from the menu there is a grass64 -tcltk option and a grass64 -wxpython option. Each will technically reset the default GUI each time you call it. Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with ~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with the wxGUI. Switching the GUI is very easy from the Config menu, and even if it is step 1. it shows the user that other avenues exist if they run into a problem with e.g. the wx digitizer tool. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/12 Markus Neteler nete...@osgeo.org: So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1, or even make a separate package which works with 6.4.0 (so long as we don't change the API, we would just need to ensure that grass.py contains the correct definition for GIS_H_VERSION so that G_gisinit() works). on the other hand what can cost to add ctypes now. One RC? That's acceptable. I would suggest to add ctypes now, publish RC7 and in one/two weeks final (before FOSS4G 2010). Stable will be released with ctypes and without swig. But if we release 6.4.0 with the swig directory in place, we'll still be getting questions about it (that we probably won't be able to answer) in ten years time. Given Glynn's suggestion I redraw my suggestion to add ctypes now. We'll do that for 6.4.1. Can anyone remove swig/ in the 6.4-release branch? I am also on the road these days with sporadic internet access. Then we can release 6.4.0 next week. Done in r43095. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Wed, Aug 11, 2010 at 9:10 PM, Glynn Clements gl...@gclements.plus.com wrote: [... thanks for the long summary which explains it perfectly...] IOW: the swig directory can be removed without affecting any other part of GRASS, including the vdigit/nviz modules. The configure checks relating to SWIG (i.e. --with-python) and the requirement for the swig program relate to the vdigit and (6.4) nviz modules. lib/python/ctypes is only required for the ctypes-based nviz module in 6.4/7.0, or if we want to offer the ctypes-based bindings for use by add-ons. So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1, or even make a separate package which works with 6.4.0 (so long as we don't change the API, we would just need to ensure that grass.py contains the correct definition for GIS_H_VERSION so that G_gisinit() works). But if we release 6.4.0 with the swig directory in place, we'll still be getting questions about it (that we probably won't be able to answer) in ten years time. Given Glynn's suggestion I redraw my suggestion to add ctypes now. We'll do that for 6.4.1. Can anyone remove swig/ in the 6.4-release branch? I am also on the road these days with sporadic internet access. Then we can release 6.4.0 next week. thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Tue, Aug 10, 2010 at 6:31 PM, Glynn Clements gl...@gclements.plus.com wrote: Martin Landa wrote: I'd like to just make one final request to remove the swig directory before release. Otherwise, people will try and use it. Good point. I would vote for it. The wxGUI vdigit and nviz has been disabled, there is nothing which uses swig. Even if they were enabled, vdigit and (the SWIG-based version of) nviz don't use anything from the swig directory. I see that the ctypes backport consists of two commits: http://trac.osgeo.org/grass/changeset/42916 http://trac.osgeo.org/grass/changeset/43015 No patch problems with patch -p4 changeset_r42916.diff Nor compilation issues after: cd lib/python/ctypes/ chmod a+x ctypesgen.py Question: side-effects to be expected? Markus PS: perhaps we should move swig/python/examples elsewhere. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/11 Markus Neteler nete...@osgeo.org: Nor compilation issues after: cd lib/python/ctypes/ chmod a+x ctypesgen.py Question: side-effects to be expected? there is still problem to ctypes on MS Windows [1]. Martin [1] http://trac.osgeo.org/grass/ticket/1125 -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Wed, Aug 11, 2010 at 10:56 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2010/8/11 Markus Neteler nete...@osgeo.org: Nor compilation issues after: cd lib/python/ctypes/ chmod a+x ctypesgen.py Question: side-effects to be expected? there is still problem to ctypes on MS Windows [1]. An option might be to skip ctypes compilation on Windows for now in 6.4.0 (Makefile condition). Markus Martin [1] http://trac.osgeo.org/grass/ticket/1125 -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Glynn wrote: I'd like to just make one final request to remove the swig directory before release. Otherwise, people will try and use it. ( they already are trying) I have no problem with this, but am not really able to test anything well right now as traveling either. If doing it I think we'd need to tag one last RC; perhaps no need to formally announce that beyond the grass-* mailing lists. I don't think to just rename it as the stable release if the tests are all good, as gdal does, but tagging rev+1 after modifying the VERSION file. (hope that makes sense, I mean re-tag, not renaming the tarball file) if removing the full swig/ dir, are there ctype options for perl/java/.net/etc users? if not, were they doomed to fail with swig anyway? MarkusN: PS: perhaps we should move swig/python/examples elsewhere. yes, I thought the same thing. I'd like to see the examples/ all ported to ctypes. (I still need to learn..) cheers, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hamish wrote: if removing the full swig/ dir, are there ctype options for perl/java/.net/etc users? The ctypes wrappers haven't been back-ported to 6.4 yet. However, it should be much easier to add ctypes wrappers to an installed version than to do likewise for SWIG wrappers. if not, were they doomed to fail with swig anyway? Pretty much. Even the relatively few attempts to use the SWIG wrappers were continually running into issues with functions needing or returning internal SWIG objects which we couldn't figure out how to create or use. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: I'd like to just make one final request to remove the swig directory before release. Otherwise, people will try and use it. Good point. I would vote for it. The wxGUI vdigit and nviz has been disabled, there is nothing which uses swig. Even if they were enabled, vdigit and (the SWIG-based version of) nviz don't use anything from the swig directory. I see that the ctypes backport consists of two commits: http://trac.osgeo.org/grass/changeset/42916 http://trac.osgeo.org/grass/changeset/43015 Please bear in mind that removing the SWIG wrappers and adding the ctypes wrappers are entirely orthogonal. As nothing (except for the new nviz module, which isn't in 6.4) depends upon either, removing the swig directory doesn't imply backporting the ctypes wrappers. 1. The swig directory uses SWIG to generate Python binding for the GRASS libraries. Nothing in GRASS uses these; the intent was to allow add-ons to be written in Python. 2. The lib/python/ctypes directory also generates Python bindings for the GRASS libraries. Whereas SWIG-based bindings consist of a binary module plus a Python module, ctypes-based bindings consist only of Python modules which use the ctypes module in the Python standard library (in Python 2.5 and later; ctypes was available as an add-on module for 2.4). Nothing in 6.4 uses this, and the intent is to allow add-ons to be written in Python. 3. The wx GUI's vdigit and nviz modules consist of a mix of C++ and Python, and use SWIG to generate the Python bindings for their C++ component. They do not use the bindings for the GRASS libraries from the swig directory. They do require the swig program to be installed, and GRASS to be configured --with-python. 4. The new nviz module in 6.5 and 7.0 (but not 6.4) no longer has a C++ component. Instead, it's written entirely in Python, using the ctypes-based bindings for the nviz and ogsf libraries. Nothing else in GRASS (and nothing at all in 6.4) uses the ctypes bindings. IOW: the swig directory can be removed without affecting any other part of GRASS, including the vdigit/nviz modules. The configure checks relating to SWIG (i.e. --with-python) and the requirement for the swig program relate to the vdigit and (6.4) nviz modules. lib/python/ctypes is only required for the ctypes-based nviz module in 6.4/7.0, or if we want to offer the ctypes-based bindings for use by add-ons. So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1, or even make a separate package which works with 6.4.0 (so long as we don't change the API, we would just need to ensure that grass.py contains the correct definition for GIS_H_VERSION so that G_gisinit() works). But if we release 6.4.0 with the swig directory in place, we'll still be getting questions about it (that we probably won't be able to answer) in ten years time. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/10 Glynn Clements gl...@gclements.plus.com: I'd like to just make one final request to remove the swig directory before release. Otherwise, people will try and use it. I would vote for it. The wxGUI vdigit and nviz has been disabled, there is nothing which uses swig. We could include ctypes in = 6.4.1 or in 6.5 and reenable wxGUI nviz and rewritten vdigit afterwards. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Mon, Aug 9, 2010 at 4:43 AM, Hamish hamis...@yahoo.com wrote: Markus Metz wrote: It's a bit late, but no blocker bugs are left apart from writing the release announcement. well it's written, as is the blurb. look in grass-web/ announces/ for drafts. please proof read, comment, etc. (see earlier post about that from last weeks, ticket) The current state is here: http://svn.osgeo.org/grass/grass-web/trunk/announces/announce_grass640.html That means it's possible, as long as nobody is slowing it down. two changes I will try to make tonight: backport Paul's g.proj linebreak fix to 6.4 and edit the menu label for v.in.mapgen (it's Matlab compatible ascii, not Matlab format per se). I do not plan on backporting r.in.wms and r.tileset patches as there have been reports of m.proj/cs2cs problems from them. and one last read through of forgotten bug reports.. :) great, we are finally close :) We need to notify the binary packagers unless they don't read here to get binaries out at the same time (ideally we put out the source code ball without announcement, package and publish as much as possible at the same moment). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
A request for quickfix: I'm requesting permission (as we are so close to release) to backport r43023 to 6.4. It fixes r.mask failure to remove MASK if GISDBASE contains spaces in path. [1] As I'm leaving town right now, in case of OK, somebody, please, do backporting. Thanks. Maris. 1. http://trac.osgeo.org/grass/changeset/43023 2010/8/9, Markus Neteler nete...@osgeo.org: On Mon, Aug 9, 2010 at 4:43 AM, Hamish hamis...@yahoo.com wrote: Markus Metz wrote: It's a bit late, but no blocker bugs are left apart from writing the release announcement. well it's written, as is the blurb. look in grass-web/ announces/ for drafts. please proof read, comment, etc. (see earlier post about that from last weeks, ticket) The current state is here: http://svn.osgeo.org/grass/grass-web/trunk/announces/announce_grass640.html That means it's possible, as long as nobody is slowing it down. two changes I will try to make tonight: backport Paul's g.proj linebreak fix to 6.4 and edit the menu label for v.in.mapgen (it's Matlab compatible ascii, not Matlab format per se). I do not plan on backporting r.in.wms and r.tileset patches as there have been reports of m.proj/cs2cs problems from them. and one last read through of forgotten bug reports.. :) great, we are finally close :) We need to notify the binary packagers unless they don't read here to get binaries out at the same time (ideally we put out the source code ball without announcement, package and publish as much as possible at the same moment). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/9 Maris Nartiss maris@gmail.com: A request for quickfix: I'm requesting permission (as we are so close to release) to backport r43023 to 6.4. It fixes r.mask failure to remove MASK if GISDBASE contains spaces in path. [1] As I'm leaving town right now, in case of OK, somebody, please, do backporting. done in r43025. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: two changes I will try to make tonight: backport Paul's g.proj linebreak fix to 6.4 and edit the menu label for v.in.mapgen (it's Matlab compatible ascii, not Matlab format per se). I do not plan on backporting r.in.wms and r.tileset patches as there have been reports of m.proj/cs2cs problems from them. and one last read through of forgotten bug reports.. :) great, we are finally close :) I'd like to just make one final request to remove the swig directory before release. Otherwise, people will try and use it. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: Hi again, Markus Neteler: Hi, proposal for action plan: As before I suggest: - release 6.4.0 now as-is - increment SVN release branch to 6.4.1 - start immediately to backport relevant patches into 6.4.1 - winGRASS binaries will become available through josef - Linux snapshots as well - Get out first 6.4.1RC1 by August - Have final 6.4.1 ready in September for FOSS4G 2010 It's a bit late, but no blocker bugs are left apart from writing the release announcement. That means it's possible, as long as nobody is slowing it down. +1 Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Metz wrote: It's a bit late, but no blocker bugs are left apart from writing the release announcement. well it's written, as is the blurb. look in grass-web/ announces/ for drafts. please proof read, comment, etc. (see earlier post about that from last weeks, ticket) That means it's possible, as long as nobody is slowing it down. two changes I will try to make tonight: backport Paul's g.proj linebreak fix to 6.4 and edit the menu label for v.in.mapgen (it's Matlab compatible ascii, not Matlab format per se). I do not plan on backporting r.in.wms and r.tileset patches as there have been reports of m.proj/cs2cs problems from them. and one last read through of forgotten bug reports.. :) regards, Hamish (traveling with limited internet access) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Paul Kelly wrote: ... still no-go. at the 6.4.0svn msys prompt: GRASS 6.4 g.proj -j +proj=utm +zone=13 +a=6378206.4 +rf=294.9786982 +no_defs +nadgrids=c:/Program Files/GRASS-64-SVN/etc/nad/conus +to_meter=1.0 .. so g.proj is broken .. Oops - well I've just committed a change to 6.5 in r42943 that should only split at a space character if there is a + character following it - hopefully that works? Ah; so pj_get_def() returns a definition using spaces both as an argument separator and within arguments? In which case, we need a more robust alternative to pj_get_def(). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Glynn: Ah; so pj_get_def() returns a definition using spaces both as an argument separator and within arguments? it seems so. with the help of y'alls fixes all should be working in 6.5svn now except for r.in.aster. cs2cs accepts individual argv's, but r.in.aster uses gdalwarp which takes all +proj terms in a single (quoted) argv, and if you use multiple 'single quotes' for each term within the -t_srs outer quote, gdalwarp chokes with a parse error. So I think that's a bug in gdalwarp as it seems impossible to quote +nadgrids there. In which case, we need a more robust alternative to pj_get_def(). only if you can't live with Paul's fix, otherwise I think we're ok. Are the NTv2 grid files likely to ever be installed to a dir with a + in the name? famous last words, but it seems unlikely to me. or at least defer worrying about it until we get an actual bug report. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Fri, 30 Jul 2010, Hamish wrote: Glynn: Ah; so pj_get_def() returns a definition using spaces both as an argument separator and within arguments? In which case, we need a more robust alternative to pj_get_def(). I guess the alternative is to remove the step whereby (in g.proj) the set of PROJ parameters that has been constructed by pj_get_kv() (a GRASS function, despite the pj_ prefix) is passed to pj_get_def() (a PROJ.4 function) for conversion into a string. Instead, part of pj_get_kv() could be separated out into a separate function that GRASS modules could use to get access to the PROJ parameters as an array of separate parameters rather than as a concatentated string. That would be a little bit of work but not too hard to do. only if you can't live with Paul's fix, otherwise I think we're ok. Are the NTv2 grid files likely to ever be installed to a dir with a + in the name? famous last words, but it seems unlikely to me. or at least defer worrying about it until we get an actual bug report. Interesting sidenote here is that it is (AFAIK) an undocumented feature of PROJ.4 that it accepts a full pathname as the value of the +nadgrids parameter. Years ago when we were putting the datum support into GRASS, the recommended method from Frank was just to put an unqualified filename as the value of +nadgrids, and then call the pj_set_finder() function to specify a finder function that PROJ.4 can call back to, to find the directory where the gridfiles are stored. But this approach falls down when exporting a PROJ.4 string for use by another application, as there is no way of telling that application where the gridfiles are stored. So we had to change it to use a fully qualified path to the nadgrids file - which has now thrown up this problem. Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hamish wrote: next problem: r.in.wms calls wms.request which calls r.tileset. r.tileset calls cs2cs*, with +proj4 terms taken from SRS=`g.proj -j`. for spearfish those terms include the conus grid file, which is in $GISBASE/etc/nad/ ... and $GISBASE of course contains a space, and then cs2cs dies a horrible death. so how to quote the right side of the individual +nadgrids= line? and will cs2cs accept that? You need to construct the cs2cs command line the hard way; simply inserting the g.proj -j output won't work. Something like: opts=`g.proj -j | ( opts= while read line ; do opts=$opts '$line' done echo $opts )` BTW: the Python versions of m.proj and r.in.aster will have problems with this, as they use g.proj -jf -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hamish wrote:
next problem: r.in.wms calls wms.request which calls r.tileset.
r.tileset calls cs2cs*, with +proj4 terms taken from SRS=`g.proj -j`.
for spearfish those terms include the conus grid file, which is in
$GISBASE/etc/nad/ ... and $GISBASE of course contains a space, and
then cs2cs dies a horrible death.
so how to quote the right side of the individual +nadgrids= line? and
will cs2cs accept that?
Glynn wrote:
You need to construct the cs2cs command line the hard way; simply
inserting the g.proj -j output won't work.
Something like:
opts=`g.proj -j | (
opts=
while read line ; do
opts=$opts '$line'
done
echo $opts
)`
thanks, applied in 6.5svn in r.in.wms/wms.request and r.tileset.
... still no-go. at the 6.4.0svn msys prompt:
GRASS 6.4 g.proj -j
+proj=utm
+zone=13
+a=6378206.4
+rf=294.9786982
+no_defs
+nadgrids=c:/Program
Files/GRASS-64-SVN/etc/nad/conus
+to_meter=1.0
.. so g.proj is broken ..
g.proj/output.c print_proj4():
for (i = proj4mod; *i; i++) {
/* Don't print the first space */
if (i == proj4mod *i == ' ')
continue;
! -- if (*i == ' ' !(dontprettify))
fputc('\n', stdout);
else
fputc(*i, stdout);
}
fputc('\n', stdout);
BTW: the Python versions of m.proj and r.in.aster will have problems
with this, as they use g.proj -jf
ok
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Thu, 29 Jul 2010, Hamish wrote: ... still no-go. at the 6.4.0svn msys prompt: GRASS 6.4 g.proj -j +proj=utm +zone=13 +a=6378206.4 +rf=294.9786982 +no_defs +nadgrids=c:/Program Files/GRASS-64-SVN/etc/nad/conus +to_meter=1.0 .. so g.proj is broken .. Oops - well I've just committed a change to 6.5 in r42943 that should only split at a space character if there is a + character following it - hopefully that works? Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hamish wrote: Markus Neteler wrote: - r.in.wms should not hold a release. fwiw, r.in.wms and (presumably) i.oif on WinGrass do not work right now because they use helper shell scripts installed to $GISBASE/etc/$module/ and those shell scripts do not currently have associated .bat files to launch them so they aren't executable and so not found in the %PATH%. should be an easy fix to generate those batch files in the two modules' Makefiles, but so far it remains TODO. I'm not sure that they should need .bat files, given that they are only run from within a shell scripts. I thought that MSys could handle this itself. Does it work if the main scripts are changed to run helper scripts via an absolute path? -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: - r.in.wms should not hold a release. Hamish: fwiw, r.in.wms and (presumably) i.oif on WinGrass do not work right now because they use helper shell scripts installed to $GISBASE/etc/$module/ and those shell scripts do not currently have associated .bat files Glynn: I'm not sure that they should need .bat files, given that they are only run from within a shell scripts. I thought that MSys could handle this itself. Does it work if the main scripts are changed to run helper scripts via an absolute path? You are correct, by adding the full path to the helper script it can now find them. fix applied in 6.5svn. i.oif already had that. next problem: r.in.wms calls wms.request which calls r.tileset. r.tileset calls cs2cs*, with +proj4 terms taken from SRS=`g.proj -j`. for spearfish those terms include the conus grid file, which is in $GISBASE/etc/nad/ ... and $GISBASE of course contains a space, and then cs2cs dies a horrible death. so how to quote the right side of the individual +nadgrids= line? and will cs2cs accept that? I expect it may be a bad idea to ask g.proj to output that, but maybe that's not so evil after all. ?? perhaps just do that for MINGW32? I guess that would mean putting ugliness into g.proj's print_proj4(). [*] so m.proj and r.in.gdalwarp probably also has this problem I'm also a bit concerned about what happens when it hits r.tileset's bashisms alittle later in, but we'll jump off that bridge when we get to it. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Tue, Jul 6, 2010 at 10:07 PM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Hamish wrote: [snip] RC bugs according to the trac'er: https://trac.osgeo.org/grass/report/13 The one blocker applies to Windows 7 only. My point was that for Linux and IIUC also MAC 6.4 is stable. GRASS is not part of a Windows7 installation, but available through Linux repositories, e.g. yum install grass should give you 6.4 without enabling particular repositories, GDAL and PROJ4, also QGIS and SAGA are available through standard repositories. Nothing but man power keeps us from making available new wingrass installers on a regular basis. the two (!) remaining blocker bugs are: * https://trac.osgeo.org/grass/ticket/1115 - Mac OSX only? Seems to be a wxpython 2.8.10.1 problem (wasn't there something similar recently in the new i.points?) * https://trac.osgeo.org/grass/ticket/1020 - Windows. AFAIK solved and spammed with another problem. ... I'm still meaning to spend a little time on this: #1051 wxgui: SEARCH_PATH corruption Great! Please do or postpone - we are holding 9000 or so changes after the last stable release. And 6.4.1 will come out way faster. and verify that g.proj's memory bug is /really/ fixed: https://trac.osgeo.org/grass/ticket/1032 A mystery because not reproducible. - was closed. https://trac.osgeo.org/grass/ticket/827 Windows only, out of reach for us, unless we make a plan on how to tell libgdal to ignore any Windows/System32/*.dll - workaround in the ticket https://trac.osgeo.org/grass/ticket/820 Proposed fix for OSGEO4W: add msys bash because from within the OSGEO4W msys (the one you get when starting grass with msys console), there is no /bin/bash - r.in.wms should not hold a release. https://trac.osgeo.org/grass/ticket/555 v.in.gpsbabel on WinGrass + a GPX file as in #555 is a quick test: - closed, too. No blockers left for Linux, it's ready, IMHO. Good. So only two blockers left (see above). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: the two (!) remaining blocker bugs are: * https://trac.osgeo.org/grass/ticket/1115 - Mac OSX only? Seems to be a wxpython 2.8.10.1 problem (wasn't there something similar recently in the new i.points?) Not related to the problem the new i.points had with wxpython 2.8.7, unfortunately, otherwise I could have had an idea. I looked into #1115 but have no idea why it fails, same wx version but different python version, so it's apparently not wx but python. * https://trac.osgeo.org/grass/ticket/1020 - Windows. AFAIK solved and spammed with another problem. Apparently fixed. Is there a new ticket for the problem mentioned in comment::25? Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Jul 26, 2010, at 2:39 PM, Markus Metz wrote: Markus Neteler wrote: the two (!) remaining blocker bugs are: * https://trac.osgeo.org/grass/ticket/1115 - Mac OSX only? Seems to be a wxpython 2.8.10.1 problem (wasn't there something similar recently in the new i.points?) Not related to the problem the new i.points had with wxpython 2.8.7, unfortunately, otherwise I could have had an idea. I looked into #1115 but have no idea why it fails, same wx version but different python version, so it's apparently not wx but python. Cleared up, bad wx build. Sorry for the holdup. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: - r.in.wms should not hold a release. fwiw, r.in.wms and (presumably) i.oif on WinGrass do not work right now because they use helper shell scripts installed to $GISBASE/etc/$module/ and those shell scripts do not currently have associated .bat files to launch them so they aren't executable and so not found in the %PATH%. should be an easy fix to generate those batch files in the two modules' Makefiles, but so far it remains TODO. earlier problems with g.* + r.in.wms seem to be unrelated and fixed now. regards, Hamish ps- everyone please review: https://trac.osgeo.org/grass/browser/grass-web/trunk/announces/abstract_grass640.txt https://trac.osgeo.org/grass/browser/grass-web/trunk/announces/announce_grass640.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
sympathies about requesting yet more server transition work, but fwiw we should really get the rsync mirrors back up and running before announcing a new release. http://grass.ibiblio.org et. al are currently frozen at July 13 when the xblade went off-line. happy to scrape out a little time to help with that as needed, Hamish ps- I notice the weekly translation stats page is broken at the ibiblio mirror ( has been for a while). ? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Sun, Jul 18, 2010 at 11:32 AM, Hamish hamis...@yahoo.com wrote: sympathies about requesting yet more server transition work, but fwiw we should really get the rsync mirrors back up and running before announcing a new release. I am working on all this for many hours :) please stay tuned... http://grass.ibiblio.org et. al are currently frozen at July 13 when the xblade went off-line. of course. Will change asap. happy to scrape out a little time to help with that as needed, Hamish ps- I notice the weekly translation stats page is broken at the ibiblio mirror ( has been for a while). ? will check that once the other mess is done. more soon, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
- start immediately to backport relevant patches into 6.4.1 just a logistics note for all, to help with that please don't start bulk moving random tickets from 6.4.0-6.4.1 in trac until all tickets currently marked for 6.4.1 are dealt with (mostly backports waiting for the branch). otherwise that stuff which should be done asap gets lost in the noise. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Helmut Kudrnovsky wrote: - release 6.4.0 now as-is there is strange behaviour in the map display. auto-rendering is enabled. if you deselect all your raster- or vector-maps in the layer manager for displaying, the last map is though always displayed. if you erase the display and refresh the display, the last map is always displayed although no map is activated. just fixed in all branches Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi again, On Thu, Jul 8, 2010 at 11:09 AM, Markus Neteler nete...@osgeo.org wrote: Hi, proposal for action plan: I am getting a bit tired of the oh let's yet wait another weekend emails... Tonight in Europe could be a nice release preparation evening! We need to complete the release material and write a press release. As before I suggest: - release 6.4.0 now as-is - increment SVN release branch to 6.4.1 - start immediately to backport relevant patches into 6.4.1 - winGRASS binaries will become available through josef - Linux snapshots as well - Get out first 6.4.1RC1 by August - Have final 6.4.1 ready in September for FOSS4G 2010 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus: I am getting a bit tired of the oh let's yet wait another weekend emails... Tonight in Europe could be a nice release preparation evening! updated wingrass binaries which start to use 'make distclean' have only been posted in the last _hour_. (and so r.terraflow fix may be tested) Testing the 6.4 binary will have to wait until tomorrow's job to be included as only just backported. someone posted a failure of v.db.addcol(?) on wingrass in the last days, we should check on that too. We need to complete the release material and write a press release. I will work on the stuff in grass-web/announce/ today. (task #677) any help with updating the twiki side of things would be appreciated. regards, Hamish ps - anyone? #994 v.buffer creating wrong buffer around polygon edges. https://trac.osgeo.org/grass/attachment/ticket/994/buffer_bug.png https://trac.osgeo.org/grass/ticket/994#comment:2 it's fails to join up closed polygons so it does not include the contribution from the buffer around the node where the area is closed (the green x in v.digit). bad results in a core module, seems not too deep to fix.. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Date: Thu, 8 Jul 2010 11:09:47 +0200 From: Markus Neteler nete...@osgeo.org Subject: Re: [GRASS-dev] 6.4.0 blocker bugs To: GRASS developers list grass-dev@lists.osgeo.org Message-ID: aanlktilm1s5_h7yyejffhpyiyigag2vourcadnnsq...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, proposal for action plan: - release 6.4.0 now as-is - increment SVN release branch to 6.4.1 - start immediately to backport relevant patches into 6.4.1 - winGRASS binaries will become available through josef - Linux snapshots as well - Get out first 6.4.1RC1 by August - Have final 6.4.1 ready in September for FOSS4G 2010 Markus Sounds good to me. Michael___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Greetings from remote parts of China. I agree with all about releasing 6.4. As it stands now 6.4 is much more stable and usable than 6.2.3. wxnviz and wxdigit are experimental for this release, so we shouldn't worry about them too much. The TclTk versions of both work well. 1+ for release as quickly as possible. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jul 6, 2010, at 10:34 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Mon, 5 Jul 2010 22:34:23 -0400 From: Helena Mitasova hmit...@unity.ncsu.edu Subject: Re: [GRASS-dev] 6.4.0 blocker bugs To: Glynn Clements gl...@gclements.plus.com Cc: Markus Metz markus.metz.gisw...@googlemail.com, Martin Landa landa.mar...@gmail.com, GRASS developers list grass-dev@lists.osgeo.org Message-ID: bba240b3-11dc-40ab-b670-d58a8063e...@unity.ncsu.edu Content-Type: text/plain; charset=us-ascii On Jul 5, 2010, at 5:11 PM, Glynn Clements wrote: Markus Neteler wrote: time to get out 6.4.0final :-) Please... one huge +1 ... I learned that we should await the ctypes port to get rid of SWIG? SWIG is only used within GRASS for the wxGUI vdigit and nviz modules. It's also used to generate wrappers for programmers who wish to access the libraries directly, but these aren't used by any part of GRASS. I suggest disabling all of this in the final release. The vdigit and nviz modules don't work on Windows, and aren't particularly robust on other platforms (and being loaded in-process means that any problems affect the GUI as a whole, not just the vdigit/nviz modules). Glynn, I assume you are talking about wxnviz here, not the TclTk based nviz which runs on windows just fine? I agree that it is really important to get 6.4 final released, especially given that FOSS4G in Barcelona is coming soon Helena The SWIG wrappers for the libraries are barely usable and are planned to be replaced, so we shouldn't be encouraging their use. IOW: 1. The swig directory should be removed from DIRS in the top-level Makefile, so it isn't built (unless the user builds it manually). 2. Official binaries shouldn't use --with-python; this will prevent the vdigit and nviz modules from being built. 3. Optionally back-port the ctypes wrappers (lib/python/ctypes). Even if this doesn't work (fails to build or generates broken wrappers), it shouldn't break anything which would otherwise work. 4. Optionally back-port the ctypes-based nviz module (wxnviz.py). This has most of the same issues as nviz/vdigit (i.e. the GRASS libraries are being accessed directly from the GUI process, so a segfault or G_fatal_error() will kill the GUI), but not all of them. 4b. Alternatively, back-port the changes but not wxnviz.py itself. The result is equivalent to just building --without-python (i.e. the GUI will try to import the wxnviz module, fail, and warn that it's disabled), except that the user can drop in wxnviz.py from SVN if they want to try it out. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
everyone wrote: time to get out 6.4.0final :-) MN: I learned that we should await the ctypes port to get rid of SWIG? Glynn: SWIG is only used within GRASS for the wxGUI vdigit and nviz modules. It's also used to generate wrappers for programmers who wish to access the libraries directly, but these aren't used by any part of GRASS. I suggest disabling all of this in the final release. The vdigit and nviz modules don't work on Windows, and aren't particularly robust on other platforms (and being loaded in-process means that any problems affect the GUI as a whole, not just the vdigit/nviz modules). The SWIG wrappers for the libraries are barely usable and are planned to be replaced, so we shouldn't be encouraging their use. IOW: 1. The swig directory should be removed from DIRS in the top-level Makefile, so it isn't built (unless the user builds it manually). fyi I've just commented out the SUBDIRS+=python in the grass 6.5 swig/Makefile, assuming ctypes will take its place there. no objection to it happening in the root Makefile. I agree that we shouldn't release 6.4.0 with swig enabled, as it will only encourage folks to invest in a dead-end. 2. Official binaries shouldn't use --with-python; this will prevent the vdigit and nviz modules from being built. 3. Optionally back-port the ctypes wrappers (lib/python/ ctypes). Even if this doesn't work (fails to build or generates broken wrappers), it shouldn't break anything which would otherwise work. 4. Optionally back-port the ctypes-based nviz module (wxnviz.py). This has most of the same issues as nviz/vdigit (i.e. the GRASS libraries are being accessed directly from the GUI process, so a segfault or G_fatal_error() will kill the GUI), but not all of them. 4b. Alternatively, back-port the changes but not wxnviz.py itself. The result is equivalent to just building --without-python (i.e. the GUI will try to import the wxnviz module, fail, and warn that it's disabled), except that the user can drop in wxnviz.py from SVN if they want to try it out. I've no big opinion on if wxVdigit and wxNviz using swig should remain enabled in 6.4.0 for now, or not. Works for me. I suggest to continue to stabilize ctypes in 6.5svn and see where it ends up. If it works cleanly there, backport to the 6.4 branch for 6.4.1. (or if it's a quick job, for 6.4.0, but then as Martin suggests we'd need one last RC. If it means a better end product I don't mind that much) Some folks on the list (eg Kim) report working Python interfaces, I'm not sure if that has anything to with SWIG or just lib/python/ and init.* magic. Anyway, we should announce intentions once we have some so they can adapt as needed. :) Python programming hooks are a big selling point these days (our univ even offers a new course in geospatial programming using python) so it would be a pity to remove that from the 6.4.0 release announcement, but not the end of the world if it will be released mature in 6.4.1. Personally I'd say that the stuff offered by lib/python/ and our solid collection of low-level C modules let us claim support for python programmers with a straight face, even if it isn't every single libgis C lib fn. -- RC bugs according to the trac'er: https://trac.osgeo.org/grass/report/13 of those, weak-blockers IMO are- seems solvable with slight effort AFAICT: #1006 r.terraflow fails to stat() stream file on Windows #994v.buffer creating wrong buffer around polygon edges I'm still meaning to spend a little time on this: #1051 wxgui: SEARCH_PATH corruption and verify that g.proj's memory bug is /really/ fixed: https://trac.osgeo.org/grass/ticket/1032 https://trac.osgeo.org/grass/ticket/827 https://trac.osgeo.org/grass/ticket/820 https://trac.osgeo.org/grass/ticket/555 v.in.gpsbabel on WinGrass + a GPX file as in #555 is a quick test: why does g.proj consistently fail in one particular script with exit code 5, ERROR_ACCESS_DENIED, and yet works fine from the MSys command line and in other scripts? could someone with MS-Windows please (re)test that? -- Helena, fyi the FOSS4G 2010 Live osgeo demo DVD/usb stick will ship with 6.4.0rc6; but MacOSX and MS Windows installers can be updated at the last minute if newer versions become available. The live version ships with the version UbuntuGIS has at build time (which in turn is often derived from what Debian's Testing has). We've got to prep, build, test, and send the master to press a long time before the actual conference. when it's ready, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Helena Mitasova wrote: I learned that we should await the ctypes port to get rid of SWIG? SWIG is only used within GRASS for the wxGUI vdigit and nviz modules. It's also used to generate wrappers for programmers who wish to access the libraries directly, but these aren't used by any part of GRASS. I suggest disabling all of this in the final release. The vdigit and nviz modules don't work on Windows, and aren't particularly robust on other platforms (and being loaded in-process means that any problems affect the GUI as a whole, not just the vdigit/nviz modules). Glynn, I assume you are talking about wxnviz here, not the TclTk based nviz which runs on windows just fine? Correct. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hamish wrote: [snip] RC bugs according to the trac'er: https://trac.osgeo.org/grass/report/13 The one blocker applies to Windows 7 only. My point was that for Linux and IIUC also MAC 6.4 is stable. GRASS is not part of a Windows7 installation, but available through Linux repositories, e.g. yum install grass should give you 6.4 without enabling particular repositories, GDAL and PROJ4, also QGIS and SAGA are available through standard repositories. Nothing but man power keeps us from making available new wingrass installers on a regular basis. of those, weak-blockers IMO are- of those, the only blocker is #1020, and it applies apparently to Windows7 only. I'm still meaning to spend a little time on this: #1051 wxgui: SEARCH_PATH corruption Great! and verify that g.proj's memory bug is /really/ fixed: https://trac.osgeo.org/grass/ticket/1032 A mystery because not reproducible. https://trac.osgeo.org/grass/ticket/827 Windows only, out of reach for us, unless we make a plan on how to tell libgdal to ignore any Windows/System32/*.dll https://trac.osgeo.org/grass/ticket/820 Proposed fix for OSGEO4W: add msys bash because from within the OSGEO4W msys (the one you get when starting grass with msys console), there is no /bin/bash https://trac.osgeo.org/grass/ticket/555 v.in.gpsbabel on WinGrass + a GPX file as in #555 is a quick test: why does g.proj consistently fail in one particular script with exit code 5, ERROR_ACCESS_DENIED, and yet works fine from the MSys command line and in other scripts? could someone with MS-Windows please (re)test that? Done so on XP. when it's ready, No blockers left for Linux, it's ready, IMHO. Umh, we could wait a bit more to discover new blockers caused by e.g. new incompatibilities between wxPython 2.8.11 and 2.8.12 or changes in OSGEO4W... Just nagging, Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: time to get out 6.4.0final :-) Please... Please check the list at https://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typepriority=blockerpriority=criticalmilestone=6.4.0order=id Several of the entries seem to be (almost?) solved but awaiting feedback/closure. Perhaps for the others we have to revisit of critical state is really reflecting the actual state (in a context of a 400 modules GIS). The latest officially stable release of GRASS is GRASS 6.2.3. The reluctance to release 6.4 means that 6.2.3 is still regarded as more stable??? A release candidate is by definition not stable, even if it might be reasonably stable by nature. This is not only about a stable wingrass, this is also about what is available in the standard repositories of major Linux distros. Fedora, which has a reputation of being adventurous, provides 6.3.0. If the aim is to provide an up-to-date GIS package to as many users as possible, a fairly recent GRASS version must be available through standard Linux repositories. Since I am on it, we should provide a Linux x86_64 installer, today the minority of Linux users have a i686 system, I get complains that there is no 64bit Linux binary installer. 64bit Linux has been available for a couple of years, and most systems sold in the past say four years support 64bit (excluding palms and netbooks). IMHO, grass should officially release a new version every 6 months, synchronized to the release schedule of major Linux distros. The more feedback from users, the better. 6.4 should go out now, in the last quarter of 2010(!!!) there should be 6.5, bugs can be fixed in e.g. 6.4.1 and 6.5.1. I am aware that 6.5 aka devbr6 is not supposed to be a stable release, but neither was 6.3. My 2c, coming from a summer school where I had a hard time explaining the grass release schedule to GIS professionals. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/7/5 Markus Metz markus.metz.gisw...@googlemail.com: Markus Neteler wrote: time to get out 6.4.0final :-) Please... one huge +1 ... Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/7/5 Markus Neteler nete...@osgeo.org: one huge +1 ... I learned that we should await the ctypes port to get rid of SWIG? ctypes are still not backported to 6.5. Then we would need another RC for 6.4.0 I would vote for testing ctypes in 6.5 first and then backport it to 6.4.1. Let's go ahead, and release 6.4.0 ASAP. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: time to get out 6.4.0final :-) Please... one huge +1 ... I learned that we should await the ctypes port to get rid of SWIG? SWIG is only used within GRASS for the wxGUI vdigit and nviz modules. It's also used to generate wrappers for programmers who wish to access the libraries directly, but these aren't used by any part of GRASS. I suggest disabling all of this in the final release. The vdigit and nviz modules don't work on Windows, and aren't particularly robust on other platforms (and being loaded in-process means that any problems affect the GUI as a whole, not just the vdigit/nviz modules). The SWIG wrappers for the libraries are barely usable and are planned to be replaced, so we shouldn't be encouraging their use. IOW: 1. The swig directory should be removed from DIRS in the top-level Makefile, so it isn't built (unless the user builds it manually). 2. Official binaries shouldn't use --with-python; this will prevent the vdigit and nviz modules from being built. 3. Optionally back-port the ctypes wrappers (lib/python/ctypes). Even if this doesn't work (fails to build or generates broken wrappers), it shouldn't break anything which would otherwise work. 4. Optionally back-port the ctypes-based nviz module (wxnviz.py). This has most of the same issues as nviz/vdigit (i.e. the GRASS libraries are being accessed directly from the GUI process, so a segfault or G_fatal_error() will kill the GUI), but not all of them. 4b. Alternatively, back-port the changes but not wxnviz.py itself. The result is equivalent to just building --without-python (i.e. the GUI will try to import the wxnviz module, fail, and warn that it's disabled), except that the user can drop in wxnviz.py from SVN if they want to try it out. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Jul 5, 2010, at 5:11 PM, Glynn Clements wrote: Markus Neteler wrote: time to get out 6.4.0final :-) Please... one huge +1 ... I learned that we should await the ctypes port to get rid of SWIG? SWIG is only used within GRASS for the wxGUI vdigit and nviz modules. It's also used to generate wrappers for programmers who wish to access the libraries directly, but these aren't used by any part of GRASS. I suggest disabling all of this in the final release. The vdigit and nviz modules don't work on Windows, and aren't particularly robust on other platforms (and being loaded in-process means that any problems affect the GUI as a whole, not just the vdigit/nviz modules). Glynn, I assume you are talking about wxnviz here, not the TclTk based nviz which runs on windows just fine? I agree that it is really important to get 6.4 final released, especially given that FOSS4G in Barcelona is coming soon Helena The SWIG wrappers for the libraries are barely usable and are planned to be replaced, so we shouldn't be encouraging their use. IOW: 1. The swig directory should be removed from DIRS in the top-level Makefile, so it isn't built (unless the user builds it manually). 2. Official binaries shouldn't use --with-python; this will prevent the vdigit and nviz modules from being built. 3. Optionally back-port the ctypes wrappers (lib/python/ctypes). Even if this doesn't work (fails to build or generates broken wrappers), it shouldn't break anything which would otherwise work. 4. Optionally back-port the ctypes-based nviz module (wxnviz.py). This has most of the same issues as nviz/vdigit (i.e. the GRASS libraries are being accessed directly from the GUI process, so a segfault or G_fatal_error() will kill the GUI), but not all of them. 4b. Alternatively, back-port the changes but not wxnviz.py itself. The result is equivalent to just building --without-python (i.e. the GUI will try to import the wxnviz module, fail, and warn that it's disabled), except that the user can drop in wxnviz.py from SVN if they want to try it out. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, time to get out 6.4.0final :-) Please check the list at https://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typepriority=blockerpriority=criticalmilestone=6.4.0order=id Several of the entries seem to be (almost?) solved but awaiting feedback/closure. Perhaps for the others we have to revisit of critical state is really reflecting the actual state (in a context of a 400 modules GIS). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
W dniu 17.06.2010 21:13, Maciej Sieczka pisze: W dniu 20.05.2010 17:48, Paul Kelly pisze: On Wed, 19 May 2010, Paul Kelly wrote: On Mon, 17 May 2010, Maciej Sieczka wrote: Does this sound acceptable for now - in particular are there any differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth worrying about? I don't know. OK well I will guess that any differences are not relevant for us here, and will see about adding the equivalence of Pulkovo_1942_58 and Pulkovo_1942 to SVN. Actually it is a bit more complicated than this. According to the EPSG database, Pulkovo_1942 is used in the following countries: Armenia; Azerbaijan; Belarus; Estonia; Georgia; Kazakhstan; Kyrgyzstan; Latvia; Lithuania; Moldova; Russian Federation; Tajikistan; Turkmenistan; Ukraine; Uzbekistan. and Pulkovo_1942_58 is used in the following countries: Albania; Bulgaria; Czech Republic; Germany (former DDR); Hungary; Poland; Romania; Slovakia. So it seems to me that we should have two separate datum entries in GRASS, and that it is arguably a bug treating them both as one. I would appreciate some suggestions on what the GRASS abbreviation for Pulkovo 1942 (58) should be; for Pulkovo 1942 it is S-42 - which IMHO is not nice as it has a capital letter in it, but of course we can't change it without breaking existing locations. Another solution is available now. In GDAL stable branch r19810 https://svn.osgeo.org/gdal/branches/1.7/gdal/data/gcs.override.csv, overrides for problematic Polish CRSes [1] were added [2]. After copying it over $GISBASE/etc/ogr_csv/gcs.override.csv, the wxGUI location wizard behaves OK when using Polish EPSG codes [1]. Same as g.proj does, e.g. instead of a warning and a lacking towgs84: Committed as r42664, r42665, r42666 to trunk, develbranch_6 and releasebranch_6_4, respectively. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
W dniu 20.05.2010 17:48, Paul Kelly pisze: On Wed, 19 May 2010, Paul Kelly wrote: On Mon, 17 May 2010, Maciej Sieczka wrote: Does this sound acceptable for now - in particular are there any differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth worrying about? I don't know. OK well I will guess that any differences are not relevant for us here, and will see about adding the equivalence of Pulkovo_1942_58 and Pulkovo_1942 to SVN. Actually it is a bit more complicated than this. According to the EPSG database, Pulkovo_1942 is used in the following countries: Armenia; Azerbaijan; Belarus; Estonia; Georgia; Kazakhstan; Kyrgyzstan; Latvia; Lithuania; Moldova; Russian Federation; Tajikistan; Turkmenistan; Ukraine; Uzbekistan. and Pulkovo_1942_58 is used in the following countries: Albania; Bulgaria; Czech Republic; Germany (former DDR); Hungary; Poland; Romania; Slovakia. So it seems to me that we should have two separate datum entries in GRASS, and that it is arguably a bug treating them both as one. I would appreciate some suggestions on what the GRASS abbreviation for Pulkovo 1942 (58) should be; for Pulkovo 1942 it is S-42 - which IMHO is not nice as it has a capital letter in it, but of course we can't change it without breaking existing locations. Hi, Another solution is available now. In GDAL stable branch r19810 https://svn.osgeo.org/gdal/branches/1.7/gdal/data/gcs.override.csv, overrides for problematic Polish CRSes [1] were added [2]. After copying it over $GISBASE/etc/ogr_csv/gcs.override.csv, the wxGUI location wizard behaves OK when using Polish EPSG codes [1]. Same as g.proj does, e.g. instead of a warning and a lacking towgs84: --- GRASS 6.5.svn (test):~ g.proj -jf epsg=2174 UWAGA:Datum Pulkovo_1942_58 not recognised by GRASS and no parameters found +proj=sterea +lat_0=51.670833 +lon_0=16.67 +k=0.9998 +x_0=3703000 +y_0=5627000 +no_defs +a=6378245 +rf=298.3 +to_meter=1 --- it returns a correct string: --- GRASS 6.5.svn (test):~ g.proj -jf epsg=2174 +proj=sterea +lat_0=51.670833 +lon_0=16.67 +k=0.9998 +x_0=3703000 +y_0=5627000 +no_defs +a=6378245 +rf=298.3 +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +to_meter=1 --- Can I upload the new gcs.override.csv to GRASS SVN? Mind it also overrides the current GRASS ETRS89 definition, as per datum.table: --- # Datum parameters for/from European Terrestrial Reference System ETRS89 etrs89 European_Terrestrial_Reference_System_1989 grs80 dx=0 dy=0 dz=0 --- with: --- # Backported from 1.8dev (see ticket #3579) 4258,ETRS89,6258,European Terrestrial Reference System 1989,6258,9122,7019,8901,1,0,6422,9603,0,0,0 --- thus, e.g. EPSG 2180 would no longer be: -- GRASS 6.5.svn (test):~ g.proj -jf epsg=2180 +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=50 +y_0=-530 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1 --- but: --- GRASS 6.5.svn (test):~ g.proj -jf epsg=2180 +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=50 +y_0=-530 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0,0,0,0,0,0,0 +to_meter=1 --- I guess it doesn't hurt; does it? [1] 3120 2172 2173 2174 2175 3334 3335 3329 3330 3331 3332 3328 4179 [2] http://trac.osgeo.org/gdal/ticket/3579#comment:7 Best, Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Wed, 19 May 2010, Paul Kelly wrote: On Mon, 17 May 2010, Maciej Sieczka wrote: Does this sound acceptable for now - in particular are there any differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth worrying about? I don't know. OK well I will guess that any differences are not relevant for us here, and will see about adding the equivalence of Pulkovo_1942_58 and Pulkovo_1942 to SVN. Actually it is a bit more complicated than this. According to the EPSG database, Pulkovo_1942 is used in the following countries: Armenia; Azerbaijan; Belarus; Estonia; Georgia; Kazakhstan; Kyrgyzstan; Latvia; Lithuania; Moldova; Russian Federation; Tajikistan; Turkmenistan; Ukraine; Uzbekistan. and Pulkovo_1942_58 is used in the following countries: Albania; Bulgaria; Czech Republic; Germany (former DDR); Hungary; Poland; Romania; Slovakia. So it seems to me that we should have two separate datum entries in GRASS, and that it is arguably a bug treating them both as one. I would appreciate some suggestions on what the GRASS abbreviation for Pulkovo 1942 (58) should be; for Pulkovo 1942 it is S-42 - which IMHO is not nice as it has a capital letter in it, but of course we can't change it without breaking existing locations. Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Mon, 17 May 2010, Maciej Sieczka wrote: GRASS already has the correct parameters for Poland. The problem is that it doesn't recognise the datum name Pulkovo_1942_58; it is looking for Pulkovo_1942. I would recommend the patch below for working around this problem. Index: lib/proj/convert.c === --- lib/proj/convert.c (revision 42262) +++ lib/proj/convert.c (working copy) @@ -744,6 +744,8 @@ Militar_Geographische_Institut, Potsdam_Datum_83, Deutsches_Hauptdreiecksnetz, + Pulkovo_1942_58, + Pulkovo_1942, NULL }; Does the trick for location wizard at GRASS startup (e.g. for epsg 2174 a nice selection GUI pops up) and the resulting PROJ_INFO as well as `g.proj -p' output are OK, but `g.proj -p epsg=2174' on the command line still fails to include the towgs84 parameter set at all, so does `g.proj -c epsg=2174'. It does include the datum though (there is a line datum: S-42), which means that the default GRASS parameters for S-42 (over the whole region it is used in) will be used where necessary (e.g. in g.proj -jf epsg=2174). I think this is the best we can hope for for now; in GRASS versions 6.2.1 and earlier g.proj when used on the command-line used to interactively prompt for the user to select a datum transformation if the datum was not fully specified, but this behaviour had to be removed when we were working towards removing all command-line interaction from modules so they could be used in scripts with no side-effects. Since GRASS 6.2.2 if you want g.proj to give you a choice of datum transformation parameters (when one is available), you have to add datumtrans=-1 to the command-line; this is what the location creation GUIs do to determine the available sets of datum transformation parameters. Does this sound acceptable for now - in particular are there any differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth worrying about? I don't know. OK well I will guess that any differences are not relevant for us here, and will see about adding the equivalence of Pulkovo_1942_58 and Pulkovo_1942 to SVN. Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
W dniu 16.05.2010 21:18, Paul Kelly pisze: On Sat, 15 May 2010, Markus Neteler wrote: On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka msiec...@sieczka.org wrote: OK now, so this was actually a revert of a massive update which broke things. Right - personally, I find it to be a major problem that we are out of synch with GDAL now. I agree it's rather unfortunate. But I think we would be getting a lot more complaints and bug reports if we had kept in-sync; the way GDAL now handles datum transformation parameters by forcing a default choice just isn't very desirable for the case of a user setting up a new location. Having a potentially non-optimal choice being automatically made for them could come back to haunt them in the future, perhaps even years into the future. Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches lacks towgs84 definition for Pulkovo 1942(58) datum, which results in locations created from EPSG codes [4] lacking it too. The towgs84 should be as in [5]. @Markus, Paul Do I simply modify gcs.csv alone or should this be a somewhat bigger change? GRASS already has the correct parameters for Poland. The problem is that it doesn't recognise the datum name Pulkovo_1942_58; it is looking for Pulkovo_1942. I would recommend the patch below for working around this problem. Index: lib/proj/convert.c === --- lib/proj/convert.c (revision 42262) +++ lib/proj/convert.c (working copy) @@ -744,6 +744,8 @@ Militar_Geographische_Institut, Potsdam_Datum_83, Deutsches_Hauptdreiecksnetz, + Pulkovo_1942_58, + Pulkovo_1942, NULL }; Does the trick for location wizard at GRASS startup (e.g. for epsg 2174 a nice selection GUI pops up) and the resulting PROJ_INFO as well as `g.proj -p' output are OK, but `g.proj -p epsg=2174' on the command line still fails to include the towgs84 parameter set at all, so does `g.proj -c epsg=2174'. In 7.x I hope to change things around so we can try to work with GDAL's new way of doing things, rather than trying to work around it. Does this sound acceptable for now - in particular are there any differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth worrying about? I don't know. All I know is that Pulkovo 1942 (58) equal 33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 is the official solution for Poland. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi Maciej, Markus, On Sat, 15 May 2010, Markus Neteler wrote: On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka msiec...@sieczka.org wrote: OK now, so this was actually a revert of a massive update which broke things. Right - personally, I find it to be a major problem that we are out of synch with GDAL now. I agree it's rather unfortunate. But I think we would be getting a lot more complaints and bug reports if we had kept in-sync; the way GDAL now handles datum transformation parameters by forcing a default choice just isn't very desirable for the case of a user setting up a new location. Having a potentially non-optimal choice being automatically made for them could come back to haunt them in the future, perhaps even years into the future. Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches lacks towgs84 definition for Pulkovo 1942(58) datum, which results in locations created from EPSG codes [4] lacking it too. The towgs84 should be as in [5]. @Markus, Paul Do I simply modify gcs.csv alone or should this be a somewhat bigger change? GRASS already has the correct parameters for Poland. The problem is that it doesn't recognise the datum name Pulkovo_1942_58; it is looking for Pulkovo_1942. I would recommend the patch below for working around this problem. In 7.x I hope to change things around so we can try to work with GDAL's new way of doing things, rather than trying to work around it. Does this sound acceptable for now - in particular are there any differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth worrying about? Paul Index: lib/proj/convert.c === --- lib/proj/convert.c (revision 42262) +++ lib/proj/convert.c (working copy) @@ -744,6 +744,8 @@ Militar_Geographische_Institut, Potsdam_Datum_83, Deutsches_Hauptdreiecksnetz, +Pulkovo_1942_58, +Pulkovo_1942, NULL }; ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Paul, Thanks for looking into this. I'll get back to you, hopefully this week. Best, Maciek W dniu 16.05.2010 21:18, Paul Kelly pisze: Hi Maciej, Markus, On Sat, 15 May 2010, Markus Neteler wrote: On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka msiec...@sieczka.org wrote: OK now, so this was actually a revert of a massive update which broke things. Right - personally, I find it to be a major problem that we are out of synch with GDAL now. I agree it's rather unfortunate. But I think we would be getting a lot more complaints and bug reports if we had kept in-sync; the way GDAL now handles datum transformation parameters by forcing a default choice just isn't very desirable for the case of a user setting up a new location. Having a potentially non-optimal choice being automatically made for them could come back to haunt them in the future, perhaps even years into the future. Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches lacks towgs84 definition for Pulkovo 1942(58) datum, which results in locations created from EPSG codes [4] lacking it too. The towgs84 should be as in [5]. @Markus, Paul Do I simply modify gcs.csv alone or should this be a somewhat bigger change? GRASS already has the correct parameters for Poland. The problem is that it doesn't recognise the datum name Pulkovo_1942_58; it is looking for Pulkovo_1942. I would recommend the patch below for working around this problem. In 7.x I hope to change things around so we can try to work with GDAL's new way of doing things, rather than trying to work around it. Does this sound acceptable for now - in particular are there any differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth worrying about? Paul Index: lib/proj/convert.c === --- lib/proj/convert.c (revision 42262) +++ lib/proj/convert.c (working copy) @@ -744,6 +744,8 @@ Militar_Geographische_Institut, Potsdam_Datum_83, Deutsches_Hauptdreiecksnetz, + Pulkovo_1942_58, + Pulkovo_1942, NULL }; -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
W dniu 15.05.2010 12:40, Maciej Sieczka pisze: @Markus, Paul: How do you actually do such updates like [3]? [3]http://trac.osgeo.org/grass/changeset?old_path=grass%2Ftrunk%2Flib%2Fprojold=41451new_path=grass%2Ftrunk%2Flib%2Fprojnew=41452 OK now, so this was actually a revert of a massive update which broke things. Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches lacks towgs84 definition for Pulkovo 1942(58) datum, which results in locations created from EPSG codes [4] lacking it too. The towgs84 should be as in [5]. @Markus, Paul Do I simply modify gcs.csv alone or should this be a somewhat bigger change? Maciek [4]3120 2172 2173 2174 2175 3334 3335 3329 3330 3331 3332 3328 4179 [5]33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka msiec...@sieczka.org wrote: W dniu 15.05.2010 12:40, Maciej Sieczka pisze: @Markus, Paul: How do you actually do such updates like [3]? [3]http://trac.osgeo.org/grass/changeset?old_path=grass%2Ftrunk%2Flib%2Fprojold=41451new_path=grass%2Ftrunk%2Flib%2Fprojnew=41452 OK now, so this was actually a revert of a massive update which broke things. Right - personally, I find it to be a major problem that we are out of synch with GDAL now. Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches lacks towgs84 definition for Pulkovo 1942(58) datum, which results in locations created from EPSG codes [4] lacking it too. The towgs84 should be as in [5]. @Markus, Paul Do I simply modify gcs.csv alone or should this be a somewhat bigger change? I have no idea, sorry. If you manage to generate a working patch it will be hopefully possible to include it in GRASS. Markus Maciek [4]3120 2172 2173 2174 2175 3334 3335 3329 3330 3331 3332 3328 4179 [5]33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Sun, Apr 18, 2010 at 10:44 AM, Markus Neteler nete...@osgeo.org wrote: I have tried to generate a new vector map with the new digitizer, but it fails: This is still the case. GRASS 6.4: A Python problem appears when generating a new vector map in the digitizer (Start digitizer, new map, enter name, OK): -- Unable to initialize display driver of vector digitizer. See 'Command output' for details. Details: 'NoneType' object has no attribute 'OpenMap' () -- GRASS 6.5: A different Python problem appears when generating a new vector map in the digitizer (Start digitizer, new map, enter name, OK): -- Unable to initialize display driver of vector digitizer. See 'Command output' for details. Reason: message=_(Unable to initialize display driver of vector Traceback (most recent call last): File /home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/toolbars.py, line 1123, in StartEditing message=_(Unable to initialize display driver of vector DigitError: unprintable DigitError object -- Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/5/14 Markus Neteler nete...@osgeo.org: On Sun, Apr 18, 2010 at 10:44 AM, Markus Neteler nete...@osgeo.org wrote: I have tried to generate a new vector map with the new digitizer, but it fails: This is still the case. GRASS 6.4: A Python problem appears when generating a new vector map in the digitizer (Start digitizer, new map, enter name, OK): -- Unable to initialize display driver of vector digitizer. See 'Command output' for details. Details: 'NoneType' object has no attribute 'OpenMap' () -- GRASS 6.5: A different Python problem appears when generating a new vector map in the digitizer (Start digitizer, new map, enter name, OK): -- Unable to initialize display driver of vector digitizer. See 'Command output' for details. Reason: message=_(Unable to initialize display driver of vector Traceback (most recent call last): File /home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/toolbars.py, line 1123, in StartEditing message=_(Unable to initialize display driver of vector DigitError: unprintable DigitError object both issues are related to the same thing - bloody swig you are using for compiling vdigit extension compared to the swig version used for wxpython packaging. On my system everything works with swig 1.3.36. Not sure when it will be fixed (me - not first item in my TODO list / nobody else probably interested to fix it). Anyway there is chance for 6.4.1. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Fri, May 14, 2010 at 4:12 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2010/5/14 Markus Neteler nete...@osgeo.org: On Sun, Apr 18, 2010 at 10:44 AM, Markus Neteler nete...@osgeo.org wrote: I have tried to generate a new vector map with the new digitizer, but it fails: This is still the case. GRASS 6.4: A Python problem appears when generating a new vector map in the digitizer (Start digitizer, new map, enter name, OK): -- Unable to initialize display driver of vector digitizer. See 'Command output' for details. Details: 'NoneType' object has no attribute 'OpenMap' () -- GRASS 6.5: A different Python problem appears when generating a new vector map in the digitizer (Start digitizer, new map, enter name, OK): -- Unable to initialize display driver of vector digitizer. See 'Command output' for details. Reason: message=_(Unable to initialize display driver of vector Traceback (most recent call last): File /home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/toolbars.py, line 1123, in StartEditing message=_(Unable to initialize display driver of vector DigitError: unprintable DigitError object both issues are related to the same thing - bloody swig you are using for compiling vdigit extension compared to the swig version used for wxpython packaging. On my system everything works with swig 1.3.36. I am not sure about this. It worked till recently without problems and I am not aware of any changes in my swig or wxpython installation. Not sure when it will be fixed (me - not first item in my TODO list / nobody else probably interested to fix it). Anyway there is chance for 6.4.1. Mhh, shipping 6.4 with broken digitizer.. am I the only one having this problem? If yes then who cares :) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi Markus, 2010/5/14 Markus Neteler nete...@osgeo.org: [...] both issues are related to the same thing - bloody swig you are using for compiling vdigit extension compared to the swig version used for wxpython packaging. On my system everything works with swig 1.3.36. I am not sure about this. It worked till recently without problems and I am not aware of any changes in my swig or wxpython installation. when I use swig 1.3.40 -- the same errors, with swig 1.3.36 everything works. Not sure when it will be fixed (me - not first item in my TODO list / nobody else probably interested to fix it). Anyway there is chance for 6.4.1. Mhh, shipping 6.4 with broken digitizer.. am I the only one having this problem? If yes then who cares :) No you are not definitely alone, anyway wxGUI is not default GUI for 6.4.0, moreover there is still v.digit. I would like to have enough time to fix all major issues related to wxGUI digitizer... Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Sat, Apr 10, 2010 at 1:31 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2010/4/10 Glynn Clements gl...@gclements.plus.com: 6.4.0 should be sync'd to 6.5. Maybe 6.5 should be sync'd to 7.0 first, with one exception: the 7.0 version of grass.script.mapcalc() 6.5 sync'ed with 7.0 in r41773, after some testing can be backported to 6.4. I have tried to generate a new vector map with the new digitizer, but it fails: -- Unable to initialize display driver of vector digitizer. See 'Command output' for details. Reason: unprintable DigitError object Traceback (most recent call last): File /home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/toolbars.py, line 1123, in StartEditing message=_(Unable to initialize display driver of vector DigitError: unprintable DigitError object -- wxNVIZ starts correectly in 6.5. === Attached the derived 6.4 backport from r41773 with a full sync of core.py (not sure if that's right). Testing that, also a (different) Python problem when generating a new vector map in the digitizer: -- Unable to initialize display driver of vector digitizer. See 'Command output' for details. Details: 'NoneType' object has no attribute 'OpenMap' () -- Also wxNVIZ does not start here, so the attached backport isn't ok yet. Markus lib_python_g64.diff Description: Binary data ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/4/10 Glynn Clements gl...@gclements.plus.com: 6.4.0 should be sync'd to 6.5. Maybe 6.5 should be sync'd to 7.0 first, with one exception: the 7.0 version of grass.script.mapcalc() 6.5 sync'ed with 7.0 in r41773, after some testing can be backported to 6.4. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: I think that we need to get out 6.4.0final. Can I suggest that lib/python is sync'd to the latest 6.x version. In 6.4.0-RC6, g.parser has been updated to the latest version (with the -s flag), but lib/python/core.py hasn't been updated to use it. It's still using the old (and unreliable) method of re-invoking the script. Is latest version 6.5 or 7? Since it isn't really my area, I am not sure what to sync (have sync'ed the file-internal documentation now). 6.4.0 should be sync'd to 6.5. Maybe 6.5 should be sync'd to 7.0 first, with one exception: the 7.0 version of grass.script.mapcalc() relies upon r.mapcalc using G_parser(), which won't work in 6.x. Although, there isn't any fundamental reason why the 6.x version won't work in 7.0. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Wed, Apr 7, 2010 at 7:58 AM, Glynn Clements gl...@gclements.plus.com wrote: Markus Neteler wrote: I think that we need to get out 6.4.0final. Can I suggest that lib/python is sync'd to the latest 6.x version. In 6.4.0-RC6, g.parser has been updated to the latest version (with the -s flag), but lib/python/core.py hasn't been updated to use it. It's still using the old (and unreliable) method of re-invoking the script. Is latest version 6.5 or 7? Since it isn't really my area, I am not sure what to sync (have sync'ed the file-internal documentation now). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: I think that we need to get out 6.4.0final. please let's fix the r.terraflow stat() bug on WinGrass first, and have another try at the v.buffer skipping start/end nodes of a polygon. https://trac.osgeo.org/grass/ticket/1006 https://trac.osgeo.org/grass/ticket/994 Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus wrote: I think that we need to get out 6.4.0final. Looking at https://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typepriority=blockerpriority=criticalmilestone=6.4.0order=id ... #843 v.digit broken on new WinGrass release - apparently working in 6.5, awaits backport to 6.4 ... the backport state is unclear to me. it *seems* to work ok now, but when you exit you get an error message that it could not build support for vector map (null). So something is still wrong, and without knowing what that is I can not rule out data-loss/corruption therefore release- blocking bug status. Hamish ps- sorry if I'm kept away by other things these days and can't read every email; try to (repeatedly) ping my work email if you need a quickish reply. I'm not ignoring anybody, I just can't keep up with the volume. :) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: I think that we need to get out 6.4.0final. Can I suggest that lib/python is sync'd to the latest 6.x version. In 6.4.0-RC6, g.parser has been updated to the latest version (with the -s flag), but lib/python/core.py hasn't been updated to use it. It's still using the old (and unreliable) method of re-invoking the script. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, I think that we need to get out 6.4.0final. Looking at https://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typepriority=blockerpriority=criticalmilestone=6.4.0order=id #72 PNG driver: boundary rendering is off by one pixel .. critical, no blocker. Unsolvable? #843 v.digit broken on new WinGrass release - apparently working in 6.5, awaits backport to 6.4 ... the backport state is unclear to me. #928: 6.4: wx module GUIs never return TODO: verify 6.4 wingrass with python addon script and the newly backported g.parser -s. #962: wxGUI crash when moving an undocked map display toolbox Unable to reproduce it. - lacking feedback #995: WxGUI startup screen fails if GISDBASE path contains non-latin characters Location Wizard still fails in Windows Vista #1020: Display of vector maps fails ... open issue on Windows7. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Markus Neteler wrote: I think that we need to get out 6.4.0final. Looking at https://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typepriority=blockerpriority=criticalmilestone=6.4.0order=id #72 PNG driver: boundary rendering is off by one pixel .. critical, no blocker. Unsolvable? Not worth the effort. AFAIK, fixing the current issue would require modifying either the polygon-filling code or the horizontal case of the line-drawing code, so that the two match. Even then, there's a limit to what you can do when code typically tries to draw lines exactly along the boundary between pixels and you're using integer coordinates. #995: WxGUI startup screen fails if GISDBASE path contains non-latin characters Location Wizard still fails in Windows Vista There's a limit to what can be achieved on Windows. We should be able to handle characters which are in the current codepage, but supporting filenames which contain characters outside of the current codepage is probably out of the question (we would need to wrap every open(), fopen(), rename(), remove() etc). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Tue, Jan 12, 2010 at 3:55 AM, Hamish hamis...@yahoo.com wrote: ... So AFAIK it is just #843 (v.digit backport) and #860 (wx About) left before we are ready to do RC6. Unfortunately there is a fundamental new bug: #862: winGRASS path detection fails in Japanese locale (¥ instead of \ is used for c:\ etc) I am happy to test whatever solves the problem. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
