RE: [GRASS-windows] Re: [GRASS-dev] Updated WinGrass release installer now available
Colin, I just looked at Marco's again and realized that he had nviz working under tcltk, but I think he didn't have the wxpython GUI which has a new nviz system. Right. The last GRASS version I compiled was without wxnviz, because it was still under development at that time... Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RE: [GRASS-windows] Updated WinGrass release installer now available
Dear Colin, congratulations! Good job ...I still didn't try it, but I'm sure that is a good job! ;) Did you use the installer script made by me? Did you encountered any difficulties? Regards, Marco -Original Message- From: grass-windows-boun...@lists.osgeo.org [mailto:grass-windows- boun...@lists.osgeo.org] On Behalf Of Colin Nielsen Sent: Monday, April 06, 2009 11:04 PM To: grass-wind...@lists.osgeo.org; grass-dev Subject: [GRASS-windows] Updated WinGrass release installer now available I have created a new installer for grass-6.4.0RC3, built on windows vista (through the osgeo4w tree). This just-double-click installer creates a stand-alone Grass (no osgeo4w structure). This is still experimental but I think everything works (minus the old tcltk gui). After installation there should be two icons on your desktop. The grass msys one is new (created by me) and allows you to use an msys terminal with grass. Please test and report on both methods and on all windows versions. http://download.osgeo.org/grass/grass64/binary/mswindows/native/WinG RASS-6.4.0RC3-1-Setup.exe I have another installer for develbranch_6 but I'll wait to hear positive feedback on this one before I release it. Once a couple issues with 7.0 get worked out I'll put together that installer too if it is wanted. -Colin ___ grass-windows mailing list grass-wind...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-windows ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Re: wingrass640
Hi Markus, may I suggest to move the build instructions into the Wiki? Currently we have http://grass.osgeo.org/grass63/binary/mswindows/native/#Build GRASS From Source http://trac.osgeo.org/grass/wiki/BuildingOnWindows http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html#GRASS which is rather confusing. A publicly editable document may accelerate the progress to obtain a winGRASS 6.4.0RC2 since more people can add suggestions and update the document to GRASS 6.4.x. OK. I'll consider that. Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: wingrass640
Hi all, is there someone (Marco?) who is going to prepare Windows installer for RC1 with wxGUI support (propably except of vector digitizer and Nviz extension)? I'm just back in office. I'm 455 mails late... but I'll start to work on the new GRASS build right now. The blocking thing is related to the building environment update I planned; in fact, some problems in the GRASS building are generated by some MSYS/MinGW lacks... that's why I decided to replace my current MSYS installation with a fully updated one... and here that's the problem! the MSYS project is poorely documented, and the 1.0.11 version of the istaller, even if available on the repository, is not officially present in the project list... but it seems to be more recent (and bug fixer) than the currently proposed one... even if not fully updated! and the updated are a little be confused (in the way you cannot just unpack the new files because some updates overwrite each other creating messy and buggy installations). I've been reading some articles and mails and I'm figuring how to solve this messy situation... I think I can give you a precise dead-line in about one or two days. I'm sorry, but I also have my regular work here ;) ... I'll do as best as I can. Regards... and happy new year :) - Ing. Marco Pasetti Università degli Studi di Brescia Facoltà di Ingegneria Dipartimento di Ingegneria Meccanica e Industriale Via Branze, 38 - 25123 Brescia - Italy Phone: (+39) 030 371 54 97 Mobile: (+39) 328 56 12 639 Skype: marco.pst - ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Python 3 or Python 2.6?
Dear all, I'm updating the GRASS build environment for MS Windows, and looking for some news in the dependencies I found that Python is currently shipped in two versions: 2.6.1 and 3. What should I install? Thanks, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python 3 or Python 2.6?
Hi Martin, I'm updating the GRASS build environment for MS Windows, and looking for some news in the dependencies I found that Python is currently shipped in two versions: 2.6.1 and 3. What should I install? Thanks, 2.6.x for sure. Python 3 is not supported. Ok. Thanks. Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: GRASS Version for Release
Dear friends, the release candidate becomes pressing now. Or QGIS 1.0 (Windows, MacOSX) will be shipped with 6.3.0 which I would pretty much dislike. Today I started to work on the new MinGW environment for both GRASS and QGIS. From today I'll abandon GRASS 6.3.0 building, moving my attention to 6.4 and 7. I decided to split the GRASS builds into: - Official WinGRASS (itself splitted into: 6.4-RCs, 6.4-dev and 7-dev, both based on trunk) - GRASS for QGIS also because of many other dependencies, such as Tcl/Tk and wxWidgets, that are not needed in the QGIS GRASS Plugin. There are many items in my To-Do list, and the chaotic and confused situation of the current MinGW project could take a lot of time before to fix them all. This said (sorry for the long preamble), I can imagine the following scenario, based on the fact that the QGIS 1.0 call for packaging is set on 12/20: A. ship qgis with grass-6.3.0, planning future package upgrades with the 6.4-RCs B. ship qgis with 6.4-RC1, even if a RC1 branch before 12/20 would not mean that I'll be able to compile a working set (of both QGIS and GRASS 6.4-RC1) in time for the release. Just my 2 cents :) Regards, MP ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [Qgis-developer] Re: GRASS Version for Release
Hi Jürgen, Did you try to build GRASS for OSGEO4W yet? No, not yet. I just started my PhD, so I'm awakening right now from a long break in GIS developing. Some time ago I asked Frank to set up a To-Do list on http://trac.osgeo.org/osgeo4w/wiki/pkg-grass (or just a basic list, to be completed by the team, that is Frank, you and me) This would be very helpful to me to do the job, because I don't have the things clear now on what to do, what is missing, not working... and so on. Because of the curren dead lines (I mean 1.0 call for packaging set on 12/20) I'll focus my GIS-available-time on the standard MinGW build. The OSGEO4W job will follow. Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: grass_icon_package.zip
Hi Luciano, I tried to download Grass Icon Package but the message apears You don't have permission to access /marco.pasetti/ on this server . Can you send this file to my e-mail address? the file is no longer available, and I sincerely don't remember what was its content. What do you need exactly? MP ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch forthcoming
Hi all, I suggest to get out 6.4.0rc1 asap for reality check (especially also for the Windows port). If backporting becomes to heavy, we could even re-do the relbranch in future. Unfortunately I'm very busy now; I'll discuss my thesis on November the 18th, and I'm still working on it. That means that I'm forced to delay the GRASS job after 11/18. I know that this is an annoying problem, but that's all I can do :-( IMHO, I think that we could release the 6.4.0 branch and delay the Windows binaries on late November. Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: mapsets and locations with spaces on wingrass?
Hi all So, in the path to the GRASS database including that is might be ok, but apparently not yet in a location name. Pretty sure that is the point. Having a space both in the mapset and in the location leads to failure for me. GRASS doesn't even open (both console and gui mode) in that case. The main problems rely on spaces in the GRASS path; I still did not detected problems related to spaces in the GIS Data Base path when launching executable modules; I suppose there may be some problems only when launching scripts. Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: mapsets and locations with spaces on wingrass?
Hi Andrea Sorry, I'm not sure I get you. I am sure that there are problems if the location name has spaces or the mapset name has spaces. You agree with that? Absolutely YES! But the GISDBASE path (not the location or mapset, but the leading folder only) allow spaces. Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: WinGRASS localization
Dear Robert, How to run WinGRASS with non-english interface? I tried different methods without success. http://www.nabble.com/-GRASS5--Re%3A--GRASSLIST%3A5600--How-to-start-GRASS-in-another-language--p8590987.html sincerely, -- Robert Szczepanek I'm not sure about it, but I suppose that the locale var settings need GRASS built with NLS support... that is currently unsupported in MS-Windows. NLS support in WinGRASS is already into the to-do list. I Cc'ed the message to the dev-list for a confirmation. Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS commits count on the Ohloh project
Hi Markus, I have looked at it... don't see a way to solve this issue except for registering a second GRASS project. Maybe rename the current registration to GRASS 7 and add a new one as GRASS 6? as you want. Actually it's not so important, I think that we can leave things as they are now. Cheers, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fw: [GRASS-windows] Re: Build GRASS with MySQL support enabled
Hi all, I'm forwarding from GRASS-Windows; I tried to build GRASS with MySQL support enabled, using prebuilt binaries for Windows from official MySQL web site (http://dev.mysql.com/downloads/mysql/5.0.html#win32; without installer zip) configure worked (I only needed to rename libmysql.dll to libmysqlclient.dll and place mysql_config in /usr/local/bin) but make failed; I attacched the error output messages as a txt file; Thanks in advance for your help. Regards, Marco - Original Message - From: Marco Pasetti [EMAIL PROTECTED] To: darren norris [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2008 1:12 PM Subject: Re: [GRASS-windows] Re: Build GRASS with MySQL support enabled Hi Darren, ok, after some tricks and trials, configure worked; now I'm compiling... I hope it will work :) unfortunately it didn't work :( I attacched the error messages as a txt file; I hope that someone else could help us. Regards, Marco ___ grass-windows mailing list [EMAIL PROTECTED] http://lists.osgeo.org/mailman/listinfo/grass-windows [EMAIL PROTECTED] /usr/local/src/grass-6.3.0-test/db/drivers $ export PATH=/usr/local/bin:/usr/local/tcl-tk/bin:/usr/local/sqlite/bin:/usr/local/pgsql/lib:/usr/local/mysql/bin:$PATH [EMAIL PROTECTED] /usr/local/src/grass-6.3.0-test/db/drivers $ make make -C dbf || echo /usr/local/src/grass-6.3.0-test/db/drivers/dbf /usr/local/src/grass-6.3.0-test/error.log make[1]: Entering directory `/usr/local/src/grass-6.3.0-test/db/drivers/dbf' make[1]: Leaving directory `/usr/local/src/grass-6.3.0-test/db/drivers/dbf' make -C postgres || echo /usr/local/src/grass-6.3.0-test/db/drivers/postgres /usr/local/src/grass-6.3.0-test/error.log make[1]: Entering directory `/usr/local/src/grass-6.3.0-test/db/drivers/postgres' make[1]: Leaving directory `/usr/local/src/grass-6.3.0-test/db/drivers/postgres' make -C mysql || echo /usr/local/src/grass-6.3.0-test/db/drivers/mysql /usr/local/src/grass-6.3.0-test/error.log make[1]: Entering directory `/usr/local/src/grass-6.3.0-test/db/drivers/mysql' make OBJ.i686-pc-mingw32 make[2]: Entering directory `/usr/local/src/grass-6.3.0-test/db/drivers/mysql' make[2]: `OBJ.i686-pc-mingw32' is up to date. make[2]: Leaving directory `/usr/local/src/grass-6.3.0-test/db/drivers/mysql' gcc -I/usr/local/src/grass-6.3.0-test/dist.i686-pc-mingw32/include -I/usr/local/include -g -O2 -I/usr/local/include -I/usr/local/mysql/include -I/usr/local/tcl-tk/include -I/usr/local/tcl-tk/include -DPACKAGE=\\ -I../../../lib/db/dbmi_driver -I/usr/local/src/grass-6.3.0-test/dist.i686-pc-mingw32/include -o OBJ.i686-pc-mingw32/create_table.o -c create_table.c In file included from C:/MSYS/local/mysql/include/mysql.h:72, from globals.h:1, from create_table.c:15: C:/MSYS/local/mysql/include/mysql_com.h:183: error: syntax error before SOCKET C:/MSYS/local/mysql/include/mysql_com.h:183: warning: no semicolon at end of struct or union C:/MSYS/local/mysql/include/mysql_com.h:222: error: syntax error before '}' token C:/MSYS/local/mysql/include/mysql_com.h:222: warning: data definition has no type or storage class C:/MSYS/local/mysql/include/mysql_com.h:335: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:336: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:337: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:338: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:339: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:340: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:341: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:342: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:345: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:346: error: syntax error before '*' token C:/MSYS/local/mysql/include/mysql_com.h:358: error: syntax error before s In file included from globals.h:1, from create_table.c:15: C:/MSYS/local/mysql/include/mysql.h:257: error: syntax error before NET C:/MSYS/local/mysql/include/mysql.h:257: warning: no semicolon at end of struct or union C:/MSYS/local/mysql/include/mysql.h:282: error: 'scramble' redeclared as different kind of symbol C:/MSYS/local/mysql/include/mysql_com.h:426: error: previous declaration of 'scramble' was here C:/MSYS/local/mysql/include/mysql.h:282: error: 'scramble' redeclared as different kind of symbol C:/MSYS/local/mysql/include/mysql_com.h:426: error: previous declaration of 'scramble' was here C:/MSYS/local/mysql/include/mysql.h:311: error: syntax error before '}' token C:/MSYS/local/mysql/include/mysql.h:311: warning: data definition has
[GRASS-dev] SVN Commit Help
Hi all, Yesterday I changed the name of the ./Extras folder in svn grass/branches/develbranch_6/mswindows in my local svn working copy ./mswindows I did: svn rename ./Extras ./Installer-Files then: svn commit -m Renamed Extras folder to Installer-Files ./Installer-Files the Installer-Files folder has been created, but it's empty; the Extras folder (along with all its files) is still there; how can I fix it without making mess with too much commits? Thanks, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] SVN Commit Help
Many thanks Glynn,
it worked perfectly :)
Marco
- Original Message -
From: Glynn Clements [EMAIL PROTECTED]
To: Marco Pasetti [EMAIL PROTECTED]
Cc: GRASS Developer Mailing List grass-dev@lists.osgeo.org
Sent: Monday, June 30, 2008 11:21 PM
Subject: Re: [GRASS-dev] SVN Commit Help
Marco Pasetti wrote:
Yesterday I changed the name of the ./Extras folder in
svngrass/branches/develbranch_6/mswindows
in my local svn working copy ./mswindows I did: svn rename
./Extras./Installer-Files
then: svn commit -m Renamed Extras folder to Installer-Files
./Installer-Files
the Installer-Files folder has been created, but it's empty; the
Extras folder (along with all its files) is still there; how can I fix
it without making mess with too much commits?
I think that you have to rename the files individually, i.e.:
for file in Extras/* ; do
svn rename $file Installer-Files/${file##Extras/}
done
--
Glynn Clements [EMAIL PROTECTED]
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS Command Line
Hi Glynn, I don't see a problem with explicitly passing the -text and -tcltk switches whenever you start GRASS. The default will then only matter if the user starts GRASS manually from a console. Also, I'm not sure there's any point to having the batch files. You can just include the -text or -tcltk switch in the shortcut's command. yes, you're right. I'll include the -text/-tcltk into the shortcut's command. Thanks Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS Wiki Hacking
Hi Glynn, I'm stretched in time (electronic systems exam ongoing) , but I try to join the thread a bit; FWIW, I've just built GRASS (SVN head) under MSys/MinGW, and the only libraries which I needed to compile from source were XDR, PROJ, GDAL and Tcl/Tk[1]. For the others, I used either the project's own binaries, or those from GnuWin32. good to know; probably something has changed since I tried the first time to use them. in the past I had problems to build GDAL with external libs and enabling jpeg support in libtiff, using libjpeg from gnuwin32, obviously. [1] I had to commit a fix to NVIZ to get it to compile; the previous change neglected to conditionalise some X11-specific code. it compiles without changes for me [2] I had to copy libfftw3-3.dll to libfftw3.dll. I suppose that we could extend the configure check to try -lfftw3-3. it works as libfftw3-3 for me, but I compiled it by myself; IIRC the gnuwin32 build has been configured differently than mine... but I'm not sure about that [4] Actually, I haven't tried using a pre-compiled Tcl/Tk binary. I'm not sure that we should recommend the ActiveState version due to the licensing terms. since it's very fast to compile, also on MinGW, I would higly prefer to build from source, as I currently do I suppose that wxPython is probably the most important omission. The main issue here is the lack of python-config on Windows. I didn't spent much time on it (I tried only few times to let it work without success, but I really didn't seriously try...), but I guess that the soultion would be here: http://wxconfig.googlepages.com/ In the meantime, can we put the binaries for XDR, PROJ, GDAL and Tcl/Tk on the GRASS site? We really shouldn't be forcing people to compile these themselves before they can even start trying to compile GRASS. Especially XDR, PROJ, and GDAL, which are mandatory dependencies. I'm currently providing a MSYS build environment, with all the libs/bins I build from source for GRASS, but they are all together; I could provide divided binaries for each library, if you prefer. On this w-e I'll send to Markus an updated version of the MSYS build env, with some upgrades and the add of the jpeg lib and support. Along with it I'll upload (to release) a new winGRASS binary release (the fourth for 6.3.0) Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS Wiki Hacking
Hi Paul, When I compiled GDAL I used external libraries as much as possible, to keep the binary size down - but that was the only reason. For compatibility probably better to use the internal ones. agree On the WinGRASS wiki page there is a link to a binary package that I provided containing: xdr-4.0-mingw32 proj-4.6.0 gdal-1.5.0 fftw-2.1.5 tcl-8.5.0 tk-8.5.0 However those versions are 5-6 months old so it would be great to get things up-to-date. the current MSYS environment I provide contains: # Flex (2.5.4a-1) # Bison (2.1) # Zlib (1.2.3) # Libpng (1.2.24) # Libtiff (3.8.2) # Freetype (2.3.5) # FFTW (3.1.2) # PDCurses (3.3) # PROJ.4 (4.6.0) # GEOS (2.2.3) # GSL (1.9) # Expat (2.0.1) # PostgreSQL (8.2.6) # SQLite (3.5.6) # GDAL (1.5.1) * # Tcl/Tk (8.5.1) * with GEOS, Expat, PostgreSQL and SQLite support enabled The one I'm going to upload contains all the previous libs updated to last available source code release (except for flex and bison), plus the libjpeg and libtiff with jpeg support And ultimately I can see us providing simple binary packages on the GRASS site, while people looking for a point click installer could be directed towards OSGeo4W. I think that would keep server disk space requirements in check, among other things. we already have a simple point click installer! Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem with wingrass
Ciao Simone, it's really strange! do you use a download manager? if yes, disable it and download it again. Grab the self installer from here: http://grass.osgeo.org/grass63/binary/mswindows/native/WinGRASS-6.3.0-3-Setup.exe I just downloaded and tested it, and it works fine. Marco - Original Message - From: Simone Bonzano To: grass-dev@lists.osgeo.org Sent: Tuesday, June 24, 2008 2:19 PM Subject: [GRASS-dev] Problem with wingrass I´ve tried many times and from different mirrors to install Wingrass native on my computer (I have a Windows XP system) but the integrity check failed, there is the possibility to have a copy of Wingrass to install it? thank you simone -- ___ 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
[GRASS-dev] WinGRASS Wiki Hacking
Hi all, I'm working on the WinGRASS Wiki page; I basically merged my personal GRASS To-Do list with it; please, take a quick look to check if I worked fine, thanks. Then, I think that section 2 (Installing binary snapshots) should be removed: I'm actually not providing binary snapshots in my WinGRASS job, and I think that no on eis doing the job. I planned to build weekly binary snapshots of both 6.4 and 7 development source code (and the installer script is already prepared for that), but at the moment I do'nt have enough spare time; This said, I propose to remove this section. What do you think about? Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS Wiki Hacking
Hi Paul, I don't think it should be labour intensive - it should be able to be scripted and run automatically. That said, I haven't got round to doing it either. But deleting all mention of it will discourage other people from helping with it. Yes, it's not actually a labour intensive task. I just need to do it and upload the binaries to Markus (and write down few lines in the WinGRASS readme). I'm doing my last university exams now, so sometimes simple things seem to me as time expensive, when actually they aren't (ah... student anxiety!!) I think there are a few reasons for keeping it. People might want to try old versions to see what is improved, or they might not have the bandwidth to download the monolithic installer, or they just might not like monolithic installers and prefer to run GRASS as a trial where it does not affect anything else on their system. actually the current WinGRASS installer just adds some entries to the registry and links to the Desktop and The StartMenu folder. while, about the bandwith, yes, I could prepare a simple tar.gz with only the grass binaries, to use along the already distributed GRASS MSYS environment tar.gz ...we could do as follows: prepare a complete SVN development installer, with all included (GRASS + dependencies), and then a simple SVN weekly snaposhot GRASS installer that contains only the GRASS binaryes and automatically installs those binaries in the right place reading the needed paths into the registry. monolithic installer and zipped binaries that can be run directly and don't require installation yes we could, but I don't know id we have so much space to use on the osgeo server (Markus?). This said, the installer creates 3 specific files during the installation (grass.bat, grass and .grassrc6), to fits the specif user configuration (basically the install dir path); simple binaries will not work alone... (even if they just need few line hacking in those files...) Also at some stage I think we need to update the Compiling by yourself section to reflect that lots of the libraries are available from Gnuwin32 at http://gnuwin32.sourceforge.net/. I'm afraid to come again on this topic, but I definetely checked that many binaries from the GNUWin32 project don't work as expected when building GRASS or other libraries. I can give you many examples: zlib, libpng, libtiff, libjpeg and others... I don't know why, but when I tried to build both GDAL and GRASS with them, they failed... while if I use my builds (from source) they compile! I'm not stubborn, nor I want to reinvent the wheel each time, but I tried... and sometimes they don't work! That's my work procedure: try prebuilt libs first! if they don't work as expected, try build them from source and if I say in my guide to build from source instead of use prebuilt binaries, there's actually a reason... And definitely mention that Tcl/Tk can be compiled from source and Activestate Tcl isn't a strict requirement. yes, I think that we should deeply modify this section. First of all I should move my building guide into /mswindows/native/ and then refer to that. Nothing known for XP/2000 issues sounds a little optimistic! yes, it's a lot optimistic! But I guess that the person who wrote that lines, intended that there are no specific issues with XP... while there are many with Windows in general... Re the FFmpeg linking problem I think Glynn said on the list that he had fixed it in SVN. I suppose that Glynn fixed the libavutil check in the configure, and not the gcc issue in the makefile. But I just suppose... I had never heard of OSGeo4W (not sure if I like the name) - looks like it could be intersting. I'm actually working with it; but there are still many opened issues about it (the main is that they use VS to build binaries) P.S. Marco I'm not suggesting you fix all these things or that we need an answer to them! Just that they might be useful for us to consider. Don't worry, I need this kind of mails :-) Thanks for all; now I must come back to my books :-( Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: [GRASS-dev] WinGRASS Plans
Hi Moritz, Just saw this: http://wxconfig.googlepages.com/ Maybe it can help you. Fantastic! It looks very promising! I'll try it. Many thanks Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: R: R: [GRASS-dev] GRASS FFMPEG support
Hi Glynn, No, I mean the gcc ... -shared command which actually links the library. That's what is generating the errors. well... sure, sorry :) I attached it because it's very long, and I think it would make the e-mail text too dirty if inserted inline. The problem is that lib/OGSF/Makefile doesn't actually specify that -lavutil is required when building the OGSF DLL. [...] ok. gotcha. Windows doesn't have a separate search path for DLLs, it just looks in $PATH. For Cygwin/MinGW, the lib directories are only used for import libraries; DLLs go in the bin directory as that will already be in $PATH. [...] thanks. meanwhile I better googled for it, and I found as follows: from: http://www.mingw.org/MinGWiki/index.php/sample%20DLL The import library created by the --out-implib linker option is required iff (==if and only if) the DLL shall be interfaced from some C/C++ compiler other than the MinGW toolchain. The MinGW toolchain is perfectly happy to directly link against the created DLL. *.pc are pkg-config files. On Linux, the official way to determine the CFLAGS/LDFLAGS required to use a particular package is e.g.: [...] thanks again. You're my personal Wikipedia on software engineering... but a lot better than Wikipedia :) Regards, Marco ogsf_error Description: Binary data ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: [GRASS-dev] WinGRASS Plans
Re: R: [GRASS-dev] WinGRASS PlansHi Michael, Check carefully throughout your entire implementation of wxPython. For the Mac version, wx-config exists in the binaries, but in a place very different from it Linux location. I checked carefully. No wx-config file! Remember that Mac is Unix-like, so it's normal that you have it, even if in another location than on linux; while Windows it's definetly another *place to live* :-) We'll solve it in another way, soon or later... Regards, Marco___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: [GRASS-dev] WinGRASS Plans
Hy Glynn, did you ever estimated the speed of the Python GUI Vs a generic compiled GUI? On my old Notebook (AMD Athlon64 3000+, 1.25 GB RAM DDR, integrated NVIDIA GPU with shared 64 MB VRAM) I noticed that, very often, just opening a module GUI or a dialoge window caused the system to freeze for a while (XP Pro SP2, 32bit, very well maintained). This said, all the other GUI parts, such as the GIS Layer Manager and the Map Display, always worked very well, and never (maybe rarely) freezed. Is that because the GUI is interpreted or is it only a Windows problem? actually, many Windows native application GUIs frequently freeze, even if they are compiled and not interpreted GUIs... Thanks for your precious explanations, as always.. :-) Marco - Original Message - From: Glynn Clements [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Michael Barton [EMAIL PROTECTED]; grass-dev@lists.osgeo.org Sent: Friday, June 06, 2008 6:37 PM Subject: Re: R: [GRASS-dev] WinGRASS Plans [EMAIL PROTECTED] wrote: Since we are talking about, why an interpretated language for the GUI It makes it easier for the user to customise the code, and to apply updates. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS Plans
Hi Michael, You can get wxPython as an installable binary for Windows from the wxPython site. No need to compile Python from source. yes, I know that (http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html#wxPython), but I cannot enable the wxWidgets support (--with-wxwidgets=path/wx-config), because the wx-config file is available only if I built wxPython from source. This said, I'm finishing the Vista build, but I need help for testings. Do you have some students *available* to make cross testings on both XP and Vista? I could test the build on Vista by myself, while on XP it's more difficult for me (I still have the old XP notebook, but I don't work at home, and I cannot keep 2 notebooks travelling..) Thanks, Marco - Original Message - From: Michael Barton [EMAIL PROTECTED] To: grass-dev@lists.osgeo.org Sent: Thursday, June 05, 2008 9:40 PM Subject: Re: [GRASS-dev] WinGRASS Plans On 6/5/08 9:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: In the WinGRASS Current Status Wiki (ToDo - Dependencies) I read: compile with wx for wx gui v.digit replacement IIRC, to enable wxWidgets in the MSYS build we need a compiled (not prebuilt) version of Python, but, at the moment, it's not possible to compile Python under MSYS/MinGW. Is it (or will it be) strictly necessary to build the new v.digit module? You can get wxPython as an installable binary for Windows from the wxPython site. No need to compile Python from source. Mihcael __ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@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] WinGRASS Plans
Markus, That's not needed. You can compile with: cd grass-addons/raster/r.sun_horizon/ make MODULE_TOPDIR=$HOME/grass64/ This will compile it into the main GRASS code tree. very good! Thanks the last thing I have to check (when I'll finish to build all) is where the binaries will be created. I'll see when I'll try to build one. Then I'll need to create a script to automatically build all the addons in the repository. I will work on it. Thanks, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS Plans
Michael, Maybe this is what you have in mind, but I think that the wx-config is only needed for compiling vdigit, not for using it. Good! sorry, confused: I always thought that Python was an interpreted language. I don't know anything about the new vdigit: does it have some C or C++ code parts to be compiled in Python? Also, I'm pretty sure that if you install the Windows dev package, it has wx-config. Windows dev package? I always used the *normal* installers; do you mean from here http://www.python.org/dev/daily-msi/? BTW, I'm sure that the *normal* installer doesn't include the wx-config. Just trying to save you some work. Thank you very much. I really appreciate that ;-) I don't have anyone in my lab currently using Vista for testing. There will be some students once we all come back for classes in mid-August. OK. I'll try to do that with my XP notebook. Thanks, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Locking is not supported on Windows
Hi Glynn, IIRC, if you just set GIS_LOCK (to anything) in init.bat, g.mapset will work. On Windows, the etc/lock program always succeeds (after printing a warning), so it's up to you to ensure that you don't run multiple GRASS sessions concurrently in the same mapset. at the moment I don't have GRASS installed on this machine, so I cannot check it, but IIRC the .gislock file was not created, even if I added GIS_LOCK=0 in the init.bat; that missing causes a problem when trying to close a mapset. Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Locking is not supported on Windows
Re: [GRASS-dev] Locking is not supported on WindowsHi all, I'm afraid that I didn't have enough spare time to correctly follow this discussion, that actually I started. On the last days I have been *GRASS Off* since I bought a new machine and I needed to migrate (from XP to Vista... please, don't say nothing! I'm really upset!). Now I'm quite operative, but I think that, about this discussion, I actually missed the point :-( Is there something that I can do? creating a .gislock file in the current opened location could be a solution? what should I write in the .gislock file? *when* should I create it? from init.bat/.sh or from another shell file? Thanks, Marco___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] R: [GRASS-PSC] SVN Write Access Request
Hi Hamish, 2) branches/develbranch_6/win32 the folder where i put all the scripts and files needed to prepare the release installer (as an exe file). why refer to 32bit in the dirname? Good question; actually I named it as I'm used in my windows projects, because I build on a 32 system; BTW, I don't know if MSYS/MinGW + NSIS are available even for Win64... For me it's the same... We can call it just Windows Just few questions: all the files (dos batch scripts, the NSIS script, icons and documents) are made by me, with the exception of: 2.1) the bmp files (4) for the installer GUI, taken from the standard library of NSIS (that is OS, obviously) it may be open source, but that means 1001 different things, many of which we can not touch. what is the license exactly? are those 4 files distributed under terms compatible with the GPL? If not GPL is it one of the OSI usual-suspects approved set? From the NSIS official web site: Applicable licenses -- * All NSIS source code, plug-ins, documentation, examples, header files and graphics, with the exception of the compression modules and where otherwise noted, are licensed under the zlib/libpng license. * The zlib compression module for NSIS is licensed under the zlib/libpng license. * The bzip2 compression module for NSIS is licensed under the bzip2 license. * The lzma compression module for NSIS is licensed under the Common Public License version 1.0. zlib/libpng license -- This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. About the above mentioned terms: 1. done: http://grass.osgeo.org/grass63/binary/mswindows/native/#Install%20GRASS 2. I didn't altered the source, I'm using only the binaries 3. We are not distributing the source code 2.2) a small part of the installer, a function to let replace parts of strings; I just copied and pasted it, maintaining the header, where is clear the line ;Written by [author] what license terms did the author provide it with? you can not just cut and paste things from the internet or cook books, even with attribution. is it a simple one-liner that is hard to write any other way, or is it an original work? without a clear license you can not distribute the code. I found it on the wiki/examples section of NSIS site http://nsis.sourceforge.net/StrRep Since it's an example it lays in the zlib/libpng license mentioned above. In particular, as I didn't modified the code, it respects all the terms in it. if in doubt try and contact the author of that code, they may give you full permission to use, modify, and redistribute it. The contact page of the author [http://nsis.sourceforge.net/User:Dandaman32] is no more available. good reading: http://www.softwarefreedom.org/resources/2008/foss-primer.html Thanks ;-) Marco -Messaggio originale- Da: Hamish [mailto:[EMAIL PROTECTED] Inviato: giovedì 15 maggio 2008 12.54 A: [EMAIL PROTECTED]; [EMAIL PROTECTED] Oggetto: Re: [GRASS-PSC] SVN Write Access Request Marco: I read and accepted the terms of the RFC 2 document published here: http://download.osgeo.org/grass/grass6_progman/rfc/rfc2_psc.html ok, then +1 from me. simple curiosity: where do you expect your initial WinGRASS commits to be? In a dir in the source code like macosx/ and debian/, or in the grass-web grass63/binary/mswin/ area, or ..? 1) grass-web/trunk/grass63/binary/mswindows/native to maintain the published release documentation 2) branches/develbranch_6/win32 the folder where i put all the scripts and files needed to prepare the release installer (as an exe file). why refer to 32bit in the dirname? Just few questions: all the files (dos batch scripts, the NSIS script, icons and documents) are made by me, with the exception of: 2.1) the bmp files (4) for the installer GUI, taken from the standard library of NSIS (that is OS, obviously) it may be open source, but that means 1001 different things, many of which we can not touch. what is the license exactly? are those 4 files distributed under terms compatible with the GPL? If not GPL is it one of the OSI usual-suspects approved set? 2.2) a small part of the installer, a
R: [GRASS-dev] Re: [GRASS GIS] #160: WinGRASS: v.reportincompatability issue
Michael, Yes. The new installer is already in my GRASS folder. Just tell me if upload it or not (and with what name, 6.3.0-1?) Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Michael Barton Inviato: martedì 13 maggio 2008 18.40 A: grass-dev@lists.osgeo.org Oggetto: [GRASS-dev] Re: [GRASS GIS] #160: WinGRASS: v.reportincompatability issue Thanks very much Marco. Also, I don't think there is any reason that binaries (and especially needed dependencies like coreutils) cannot be updated between GRASS version releases. Michael On 5/13/08 9:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Message: 1 Date: Mon, 12 May 2008 16:00:16 - From: GRASS GIS [EMAIL PROTECTED] Subject: [GRASS-dev] Re: [GRASS GIS] #160: WinGRASS: v.report incompatability issue To: undisclosed-recipients:; Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=utf-8 #160: WinGRASS: v.report incompatability issue -+ -+-- Reporter: isaacullah | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: major | Milestone: 6.4.0 Component: default | Version: 6.3.0 Resolution: fixed |Keywords: v.report paste WinGRASS -+ -+-- Changes (by 4everskiff): * status: new = closed * resolution: = fixed Comment: I already did the job on my local machine. All the MSYS coreutils will be added to the next WinGRASS release. This done, I checked the v.report module using the North-Carolina sample database: it worked fine for me. Until the next release will be published, do as follows: Download the coreutils package from here: http://downloads.sourceforge.net/mingw/coreutils-5.97-MSYS-1.0.11- snapshot.tar.bz2 Unpack it to a temporary folder, then copy all the content of the coreutils-5.97 folder to %your GRASS installation path%\msys Marco __ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ___ 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
[GRASS-dev] v.in.e00 AVCE00
Hi all, I was importing DCW (http://www.maproom.psu.edu/dcw/dcw_about.shtml) data with v.in.e00 (WinGRASS), but it reported the following error: 'avcimport' program not found, install it first; http://avce00.maptools.org this requirement is not present in the GRASS requirements list, why? BTW, I visited the suggested web page and downloaded the source code; I will compile it on next hour. If it will work fine, should we update the WinGRASS binary release now (that is when I compiled and tested it) or can we wait for the next GRASS release? Update means: update the binaries (installer), the files WinGRASS_Sources.zip, GRASS_MSYS_Environment.zip and the BuilFromSource guide. Comments? Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] v.in.e00 AVCE00
Hi Markus, No reason, someone forgot to add it. I have done so now. Perfect Since it was a technology preview, I suggest to wait. Good. Let's do it for 6.3.1 or 6.4.0. I'm going to open a ticket with 6.4.0 as milestone BTW: Maybe you better use VMAP0 instead of the older DCW (1992)... http://en.wikipedia.org/wiki/DCW http://en.wikipedia.org/wiki/Vector_Map Thanks, as usual ;-) Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Markus Neteler Inviato: mercoledì 7 maggio 2008 21.09 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: [GRASS-dev] v.in.e00 AVCE00 Hi Marco, On Wed, May 7, 2008 at 8:45 PM, Marco Pasetti [EMAIL PROTECTED] wrote: Hi all, I was importing DCW (http://www.maproom.psu.edu/dcw/dcw_about.shtml) data with v.in.e00 (WinGRASS), but it reported the following error: 'avcimport' program not found, install it first; http://avce00.maptools.org this requirement is not present in the GRASS requirements list, why? No reason, someone forgot to add it. I have done so now. BTW, I visited the suggested web page and downloaded the source code; I will compile it on next hour. If it will work fine, should we update the WinGRASS binary release now (that is when I compiled and tested it) or can we wait for the next GRASS release? Since it was a technology preview, I suggest to wait. Update means: update the binaries (installer), the files WinGRASS_Sources.zip, GRASS_MSYS_Environment.zip and the BuilFromSource guide. Comments? Let's do it for 6.3.1 or 6.4.0. BTW: Maybe you better use VMAP0 instead of the older DCW (1992)... http://en.wikipedia.org/wiki/DCW http://en.wikipedia.org/wiki/Vector_Map Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] Reproject, change resolution and patch: doubts....
Hi Helena, Thanks for your reply. just a few notes. If you set the resolution to 20m, GRASS will resample your 90m SRTM to 20m using nearest neighbor, creating a DEM with steps - something line this (a) is automatic nn resampling, b) is reinterpolation by rst) http://www.grassbook.org/gallery/chapters/s050303f010_resamp.jpg Yes, yesterday I tried the described procedure and I noticed the same result NVIZing the reprojected dem. BTW I don't need to produce 3D maps, but I need to introduce the less data distorsion as possible. The NN method should do the job for me. I'm not sure that an interpolation would be a good solution, but I talk with a strict mathematic/electronic approach, that's my professional training; probably, talking about topography, interpolations rarely produce remarkable errors. This said, I prefer the 20m data, against the SRTM ones, because I analyzed a very well known (small) area with NVIZ, using both SRTM and 20m data, and I noticed relevant errors with SRTM data (I cannot pretend much from it, it's a SAR shuttle mission... it's actually a miracle that we have it, that it works pretty fine and that is free). Summarizing: 1) r.proj method=nearest 2) r.resamp.rst Right? Thanks, Marco -Messaggio originale- Da: Helena Mitasova [mailto:[EMAIL PROTECTED] Inviato: mercoledì 7 maggio 2008 18.25 A: [EMAIL PROTECTED] Oggetto: Re: [GRASS-dev] Reproject, change resolution and patch: doubts Marko, just a few notes. If you set the resolution to 20m, GRASS will resample your 90m SRTM to 20m using nearest neighbor, creating a DEM with steps - something line this (a) is automatic nn resampling, b) is reinterpolation by rst) http://www.grassbook.org/gallery/chapters/s050303f010_resamp.jpg Dylan has a nice comparison of effects of different resampling and reinterpolation methods on his web site, if you want to learn more. If you have a GRASS book and the nc_spm data set - it has both SRTM data and lidar based 10m and 1m resolution DEMs so you can see how SRTM works, there are several examples in the book - e.g. SRTM is consistently higher and I did viewshed from 30m SRTM and lidar-based 30m DEM - same resolution but the results were quite different. You need to keep in mind that SRTM maps the surface with vegetation on it while your 20m DEM is probably bare earth surface. Also look at the metadata for both to compare their vertical accuracy, some smoothing of SRTM may actually be justified (unless you want the vegetation and have some means to add it to your 20m DEM). When you decide to reinterpolate you can compare your re-interpolated DEM with the original data (e.g. the 90m grid centers) and make sure that any smoothing does not exceed the accuracy of your original data. Just for illustration: here is a stream network derived from 10m resolution IFSARE patched with 90m SRTM where IFSARE data were missing, all reinterpolated to 30m resolution to get the river flow seamlessly back-and-forth along the patch line. http://skagit.meas.ncsu.edu/~helena/measwork/panama/pacora30maccum.jpg some SRTM data can be pretty noisy: http://skagit.meas.ncsu.edu/~helena/measwork/nrc/mumbai_srtm.png Helena Do you agree? Thanks for all, Marco ___ 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
R: [GRASS-dev] v.in.e00 AVCE00
Hi all,
I compiled the source code and installed avcimport.exe and e00conv.exe (289
KB total).
Then I ran the v.in.e00 module and I got the following error messages:
v.in.e00 {file=C:/Documents and Settings/Marco/Documenti/GIS Data
Repository/DCW/rdline.e00} type=line
basename: too many arguments
Try `basename --help' for more information.
An error may appear next which will be ignored...
E00 ASCII found and converted to Arc Coverage in current directory
Importing lines...
Unable to open data source .E00
An error occurred while running v.in.ogr
Marco
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] v.in.e00 AVCE00
Hi Bob,
v.in.e00 might have a problem with spaces in file names?
Yes, I suppose too.
I need some time to check it out ...tomorrow, now it's too late :-)
Marco
-Messaggio originale-
Da: Moskovitz, Bob [mailto:[EMAIL PROTECTED]
Inviato: mercoledì 7 maggio 2008 22.32
A: Marco Pasetti; Markus Neteler
Cc: GRASS Developer Mailing List
Oggetto: RE: [GRASS-dev] v.in.e00 AVCE00
v.in.e00 might have a problem with spaces in file names?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Marco Pasetti
Sent: Wednesday, May 07, 2008 1:17 PM
To: 'Marco Pasetti'; 'Markus Neteler'
Cc: 'GRASS Developer Mailing List'
Subject: R: [GRASS-dev] v.in.e00 AVCE00
Hi all,
I compiled the source code and installed avcimport.exe and e00conv.exe
(289 KB total).
Then I ran the v.in.e00 module and I got the following error messages:
v.in.e00 {file=C:/Documents and Settings/Marco/Documenti/GIS Data
Repository/DCW/rdline.e00} type=line
basename: too many arguments
Try `basename --help' for more information.
An error may appear next which will be ignored...
E00 ASCII found and converted to Arc Coverage in current directory
Importing lines...
Unable to open data source .E00
An error occurred while running v.in.ogr
Marco
___
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
R: R: [GRASS-dev] Re: WinGRASS-6.3.0 Release Package
Markus,
oops, restored.
Good ;)
BTW: I have made Wiki url fixes in
http://grass.osgeo.org/grass63/binary/mswindows/native/README.html
Thanks. Updated changes with my local version
before expanding, it needs a cleanup: the demolocation is replicated which
we should avoid
Could you work around that?
OK. But it need changes also into the installer scripts.
I'll send you the new SVN_Win32.zip (since it's small I'll send you as file
attachment by mail)
Marco
-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Per conto di Markus Neteler
Inviato: venerdì 25 aprile 2008 10.55
A: GRASS developers list
Oggetto: Re: R: [GRASS-dev] Re: WinGRASS-6.3.0 Release Package
On Fri, Apr 25, 2008 at 10:35 AM, Marco Pasetti [EMAIL PROTECTED]
wrote:
Hi Markus,
I was writing to you :-)
Only two things:
1. The GRASS_MSYS_Environment.zip disappeared from the WinGRASS Web
Page
oops, restored.
BTW: I have made Wiki url fixes in
http://grass.osgeo.org/grass63/binary/mswindows/native/README.html
2. The SVN_Win32.zip should be extracted to the SVN root. It could be
stay also in the WinGRASS Web Page, but I didn't provide a README
file for it,
I have moved it out there.
and I would not, since it contains only developers information on how
to prepare a WinGRASS release intaller (and a complete related
README.html file is already contained in the zipped Win32 folder)
before expanding, it needs a cleanup: the demolocation is replicated which
we should avoid:
unzip -l SVN_Win32.zip
Archive: SVN_Win32.zip
Length Date TimeName
0 04-24-08 22:04 Win32/Extras/
0 04-24-08 22:04 Win32/Extras/demolocation/
0 04-24-08 22:04 Win32/Extras/demolocation/PERMANENT/
270 03-09-07 10:55 Win32/Extras/demolocation/PERMANENT/DEFAULT_WIND
155 11-24-04 22:18
Win32/Extras/demolocation/PERMANENT/DEFAULT_WIND3
0 04-24-08 22:04 Win32/Extras/demolocation/PERMANENT/dig/
283 12-17-04 18:13 Win32/Extras/demolocation/PERMANENT/dig/point
0 04-24-08 22:04 Win32/Extras/demolocation/PERMANENT/dig_att/
50 12-17-04 18:13
Win32/Extras/demolocation/PERMANENT/dig_att/point
0 04-24-08 22:04 Win32/Extras/demolocation/PERMANENT/dig_plus/
374 12-17-04 18:14
Win32/Extras/demolocation/PERMANENT/dig_plus/point
20 11-24-04 22:18 Win32/Extras/demolocation/PERMANENT/MYNAME
76 03-09-07 10:55 Win32/Extras/demolocation/PERMANENT/PROJ_INFO
40 11-24-04 22:18 Win32/Extras/demolocation/PERMANENT/PROJ_UNITS
0 04-24-08 22:04 Win32/Extras/demolocation/PERMANENT/site_lists/
8 12-17-04 18:14
Win32/Extras/demolocation/PERMANENT/site_lists/mysites
66 03-09-07 10:55 Win32/Extras/demolocation/PERMANENT/VAR
270 03-09-07 10:55 Win32/Extras/demolocation/PERMANENT/WIND
155 11-24-04 22:18 Win32/Extras/demolocation/PERMANENT/WIND3
17987 03-26-08 18:17 Win32/Extras/GPL.TXT
112 04-21-08 11:40 Win32/Extras/GRASS-WebSite.url
17542 02-29-08 23:51 Win32/Extras/grass.ico
17542 04-21-08 11:51 Win32/Extras/grass_web.ico
13052 03-08-08 19:49 Win32/Extras/InstallHeaderImage.bmp
17542 03-08-08 19:39 Win32/Extras/install_grass.ico
15822 04-24-08 22:00 Win32/Extras/README.html
13052 03-08-08 20:18 Win32/Extras/UnInstallHeaderImage.bmp
17542 03-08-08 20:14 Win32/Extras/uninstall_grass.ico
52576 02-29-04 17:44 Win32/Extras/UnWelcomeFinishPage.bmp
52576 02-29-04 17:44 Win32/Extras/WelcomeFinishPage.bmp
20377 04-24-08 21:36 Win32/GRASS-Installer.nsi
5315 04-24-08 20:21 Win32/GRASS-Packager.bat
10807 04-24-08 22:12 Win32/README.html
0 04-24-08 22:04 Win32/
---
273611 34 files
Could you work around that?
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
R: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
Hi all, When do you think that 6.3.0 will be released? Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: R: [GRASS-dev] GRASS 6.3.0 to be released
Hi Michael, If its easier to just do a single package, then I think that is what you should do. That is what most Windows (and Mac) users expect anyway. ...and that's very good to hear for me ;-) Marco _ Da: Michael Barton [mailto:[EMAIL PROTECTED] Inviato: mercoledì 16 aprile 2008 19.16 A: [EMAIL PROTECTED]; grass-dev@lists.osgeo.org Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released You have described it well. If its easier to just do a single package, then I think that is what you should do. That is what most Windows (and Mac) users expect anyway. Michael On 4/16/08 9:40 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Michael, I see what you mean on Windows. Actually, in this case, there are no dependencies like you find on Unix systems thx. it's difficult to be a Windows user here. GRASS people is used to work on too much advanced systems than I'm used to ;-) (even if I'm a linux user too) A separate install for Msys/TclTk/Python might be useful. MSYS: --- I think we could provide MSYS as install option or don't provide it at all... if people want MSYS they can download and install using the official MSYS installer (the GRASS installer could just check if MSYS is installed and create the grass63 file into /usr msys folder, according to selected GRASS install path, as it already does) TclTk --- This is needed, since GRASS is built with it and some binaries require tcl/tk DLLs. I think we must provide it along binaries Python --- I think that's the only indipendent package installer we could provide. Then that part could be installed only as needed and GRASS could be updated more often. I think that's not a *frequency* problem, but just a *weight* problem of the installers provided. If I had built a new version of GRASS to release, it's not absolutely a problem for me to package all the other files along with it (I mean the new GRASS build) as I as did with the WinGRASS-6.3.0RC5 and RC6 releases. I need to just run an automated batch file I wrote for the job, and then compile the NSIS script to create the related installer. The whole packaging job takes approx 5 minutes! I hope to have well described the *situation* Best regards, Marco _ Da: [EMAIL PROTECTED] per conto di Michael Barton Inviato: mer 16/04/2008 18.15 A: grass-dev@lists.osgeo.org Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released Marco, I see what you mean on Windows. Actually, in this case, there are no dependencies like you find on Unix systems. A separate install for Msys/TclTk/Python might be useful. Then that part could be installed only as needed and GRASS could be updated more often. Michael On 4/16/08 9:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Date: Wed, 16 Apr 2008 17:18:30 +0200 From: [EMAIL PROTECTED] Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released To: Moritz Lennert [EMAIL PROTECTED] Cc: Martin Landa [EMAIL PROTECTED], Glynn Clements [EMAIL PROTECTED], GRASS developers list grass-dev@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi Moritz, This actually sounds much more sophisticated than what Glynn proposed. yes, it is... but we could make a walkaround... I'll explain how later... Could you not simply propose one installer with only the latest (complete) GRASS binaries. This installer could check for any existing installation of GRASS and propose to erase that before installing the new version, or install the new version next to the old. very good ;-) we are at the same *point* here. I already thought it some weeks ago, before ro release RC6... and that's why I already added in RC6 installer some registry key values that would let me the job (that is: let future installers recognise if GRASS is already istalled on the system, what version and where). I already talked with Markus about this option in future WinGRASS installers. The question then is: do we need a complete installer with everything in it (as you suggest), or can we impose the burden of two installers on people, i.e. as Glynn suggests: one GRASS installer + one Dependencies installer. I think this would be the best solution for us, but it would mean that at least for the first installation, users will have to install two packages. If the GRASS installer could test for the installation of the other package and propose to download it and lauch its installation autmagically, then this might be the best solution. what do you mean about *dependencies*? the only dependencies that are indipendent to GRASS binaries is Python! all the other DLLs are necessary to start GRASS. What would happen if we release GRASS with an additional support (jpeg, for example) not previously supported? we must provide the libjpeg with the installer, or update the *dependencies installer*? IMHO, this is a sctrictly UNIX way to think... windows is
R: [GRASS-dev] GRASS 6.3.0 to be released
Hi all, It would be good also for me, even if it would better if we release it on next week tough (I'm very busy now). BTW, there are few thing to do for me, just some improvements for windows installer... Martin, do you think that we could add the needed python files into the 6.3.0 windows package, in order to let users start the pyGUI without the need to install python stuffs by themselves? Regards Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Martin Landa Inviato: martedì 15 aprile 2008 19.04 A: Markus Neteler Cc: GRASS developers list Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released 2008/4/15, Markus Neteler [EMAIL PROTECTED]: After 6 release candidates, even tested on MS-Windows, I don't see any real blockers any more. I suggest to get out 6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn. We can have 6.3.1 if needed. Sounds ok? +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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] Re: [GRASS-user] trouble with v.rast.stats underWINGRASS
Hi Moritz, Moritz, does it probably has been fixed in RC6? Niels, could you download and install WinGRASS-6.3.0RC6 (before uninstall RC5 using Add/Remove programs utility) and check if v.rast.stats works in it? Thanks Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Moritz Lennert Inviato: martedì 8 aprile 2008 23.03 A: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; GRASS devel; Hamish Oggetto: [GRASS-dev] Re: [GRASS-user] trouble with v.rast.stats underWINGRASS On 08/04/08 18:04, Niels Thevs wrote: Dear GRASS users, I am using WINGRASS 6.3 (RC5) and tried the command v.rast.stats. But I encountered the error messages below, though the vector and raster are in the same mapset. [EMAIL PROTECTED] is not in the current mapset (PERMANENT) An error occurred while converting vector to raster G__open(r): mapset (PERMANENT) doesn't match xmapset (PERMANENT_3280.0) G__open(r): mapset (PERMANENT) doesn't match xmapset (PERMANENT_3280.0) [EMAIL PROTECTED] is not in the current mapset (PERMANENT) Does anybody know, how to overcome this problem ? This was fixed by Hamish here http://trac.osgeo.org/grass/changeset/30136 but apparently it did not get backported. A quick fix for you is to click on the command in the Output window, so that you can edit it at the bottom and change the [EMAIL PROTECTED] into vector=split1 and then push 'Run'. A more permanent fix is to download the current version of the script from here: http://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast. stats and replace you $GISBASE/scripts/v.rast.stats with the downloaded file. Moritz ___ 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
R: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer
Hi Moritz, ODBC and maybe MySQL might be good things to add They are actually in my wish list, along with jpeg support, FFMPEG, xerces and some other things. I just need a day of 48 hours ;-) ... But I think that waiting for some months more until I'll take my degree will be enough! Marco -Messaggio originale- Da: Moritz Lennert [mailto:[EMAIL PROTECTED] Inviato: giovedì 27 marzo 2008 18.22 A: [EMAIL PROTECTED] Cc: grass-dev@lists.osgeo.org; Glynn Clements Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer On 27/03/08 17:46, [EMAIL PROTECTED] wrote: http://www.webalice.it/marco.pasetti/temp/README.html Notes and suggestions about modifications, addings and removals in it will be highly appreciated. - How to submit bugs ? preferably here: http://trac.osgeo.org/grass/ but possibly on wingrass list http://lists.osgeo.org/mailman/listinfo/grass-windows - Maybe add the information about how to contact you (possibly via one of the mailing lists) ? - Not about the document, but about the package: 1) ODBC and maybe MySQL might be good things to add. Especially the first, as this would potentially give access to Win-specific databases. 2) More a question to Glynn: I see r.terraflow is still missing. I guess this hasn't been backported to 6.3releasebranch ? Once again: great job and many thanks ! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer
Hi Moritz, Just one last remark: IIRC, for PostgreSQL you only provide the libpg.dll, not the entire postgresql installation. This should be mentioned. And what about sqlite ? Did you include the sqlite.exe ? For PostgreSQL I provide only libpq.dll, while for SQLite I provide *all the build*, that is also sqlite.exe. On the same way, should I notice also further info for Tcl/Tk (as for SQLite, I provide *all the build* of it)? But this would open a *pandora's box*, because on this way I should specify also what files I exactly provide from other stuffs (such as tiff, gdal, proj) Opened to all suggestions ;-) Marco -Messaggio originale- Da: Moritz Lennert [mailto:[EMAIL PROTECTED] Inviato: giovedì 27 marzo 2008 22.59 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer On Thu, March 27, 2008 22:46, Marco Pasetti wrote: Hi all, Thanks for all the suggestions: I modified the document, and finally it sounds good for me: http://www.webalice.it/marco.pasetti/temp/README.html So, let's start the poll! ;-) Just one last remark: IIRC, for PostgreSQL you only provide the libpg.dll, not the entire postgresql installation. This should be mentioned. And what about sqlite ? Did you include the sqlite.exe ? Moritz Marco ___ 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
R: [GRASS-dev] WinGRASS-6.3.0RC6 Python GUI
Hi Glynn, How could that be if all works well with tcl/tk GUI? I tried, and g.region works perfectly if I open GRASS with tcl/tk GUI. Marco -Messaggio originale- Da: Glynn Clements [mailto:[EMAIL PROTECTED] Inviato: giovedì 27 marzo 2008 22.24 A: [EMAIL PROTECTED] Cc: grass-dev@lists.osgeo.org Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC6 Python GUI [EMAIL PROTECTED] wrote: I reinstalled Python (2.5.2) + Python Extensions for Windows (Build 210 - py2.5) + WxPython (2.8.7.1 - unicode - py25) but I still have the same errror (follows): http://www.webalice.it/marco.pasetti/temp/grass_bugs/bug002.png My first guess is that it's related to GDAL, i.e. it can't find either the GDAL DLL or one of the (many) DLLs which GDAL requires. The Python error is a consequence of g.region failing. Essentially, if g.region doesn't work, the GUI isn't going to work. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer
I could solve as adding the following note after *with GEOS, Expat, PostgreSQL and SQLite support enabled: The current WinGRASS package contains a complete build of all the items listed above, except for PostgreSQL, for which it contains only the libpq.dll dynamic library. What do you think about? -Messaggio originale- Da: Moritz Lennert [mailto:[EMAIL PROTECTED] Inviato: giovedì 27 marzo 2008 22.59 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer On Thu, March 27, 2008 22:46, Marco Pasetti wrote: Hi all, Thanks for all the suggestions: I modified the document, and finally it sounds good for me: http://www.webalice.it/marco.pasetti/temp/README.html So, let's start the poll! ;-) Just one last remark: IIRC, for PostgreSQL you only provide the libpg.dll, not the entire postgresql installation. This should be mentioned. And what about sqlite ? Did you include the sqlite.exe ? Moritz Marco ___ 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
R: R: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer
If using --with-tiff and --without-jpeg works, either your TIFF library doesn't have JPEG support, or it can find the JPEG library without any assistance. Either way, adding --with-jpeg won't make any difference. Yes, currently TIFF library doesn't have JPEG support (as this libjpeg is not present in my MSYS environment); I succesfully built libjpeg, but during tests it reported errors, so I decided to remove it and then build TIFF without it; In wish list I meant to add jpeg and its support in tiff. Marco -Messaggio originale- Da: Glynn Clements [mailto:[EMAIL PROTECTED] Inviato: venerdì 28 marzo 2008 1.03 A: Marco Pasetti Cc: 'Moritz Lennert'; grass-dev@lists.osgeo.org Oggetto: Re: R: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer Marco Pasetti wrote: ODBC and maybe MySQL might be good things to add They are actually in my wish list, along with jpeg support, FFMPEG, xerces and some other things. JPEG support doesn't actually mean anything. None of the Makefiles use the JPEG variables (JPEGLIB, JPEGLIBPATH and JPEGINCPATH). The configure script uses the variables when testing for the TIFF library, but that only matters if the TIFF library was built with JPEG support but it requires specific switches to locate the JPEG library (e.g. if the TIFF library is a static library). If using --with-tiff and --without-jpeg works, either your TIFF library doesn't have JPEG support, or it can find the JPEG library without any assistance. Either way, adding --with-jpeg won't make any difference. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] WinGRASS-6.3.0RC6 Python GUI
I'm afraid folks.. I'm a gigantic idiot!!! I supposed to work with the *package version* that has all the dlls in an unique folder, while I was launching grass from the *original* msys environment, where pgsql.dll is placed in the specific pgsql/lib folder!!! (Glynn, as usual you were right!!!) Sorry! Now the new python interface works, and it automatically starts even if I don't specify -wxpython after grass63 command in shell. I didn't have time to perform many tests, but opening existing locations it seems to work; only two things: 1) when I exit it reports the following message in msys shell: $ grass63 Cleaning up temporary files. Starting GRASS ... WARNING: Attention! WARNING: Locking is not supported on Windows! GRASS GUI should be wxpython __ ___ _____ / / __ \/ | / ___/ ___/ / / _/ ___/ / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ / /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / \/_/ |_/_/ |_/// \/___/// Welcome to GRASS 6.3.0RC6 (2008) GRASS homepage: http://grass.osgeo.org/ This version running thru: Bourne Shell (/bin/sh) Help is available with the command: g.manual -i See the licence terms with: g.version -c If required, restart the GUI with: g.gui wxpython When ready to quit enter:exit GRASS 6.3.0RC6 (SIT-Lombardia):C:/MSYS/local/bin Traceback (most recent call last): File C:\MSYS\local\grass-6.3.0RC6\etc\wxpython\gui_modules\mapdisp.py, line 2412, in OnFocus self.layerbook.SetSelection(pgnum) File C:\DevTools\Python\Lib\site-packages\wx-2.8-msw-unicode\wx\lib\flatnotebook .py, line 3275, in SetSelection if not self._pages.GetEnabled(page) and len(self._windows) 1 and not self._bForceSelection: File C:\DevTools\Python\Lib\site-packages\wx-2.8-msw-unicode\wx\_core.py, line 14318, in __getattr__ raise PyDeadObjectError(self.attrStr % self._name) wx._core.PyDeadObjectError: The C++ part of the PageContainer object has been deleted, attribute access no longer allowed. Traceback (most recent call last): File C:\MSYS\local\grass-6.3.0RC6\etc\wxpython\gui_modules\mapdisp.py, line 2412, in OnFocus self.layerbook.SetSelection(pgnum) File C:\DevTools\Python\Lib\site-packages\wx-2.8-msw-unicode\wx\lib\flatnotebook .py, line 3275, in SetSelection if not self._pages.GetEnabled(page) and len(self._windows) 1 and not self._bForceSelection: File C:\DevTools\Python\Lib\site-packages\wx-2.8-msw-unicode\wx\_core.py, line 14318, in __getattr__ raise PyDeadObjectError(self.attrStr % self._name) wx._core.PyDeadObjectError: The C++ part of the PageContainer object has been deleted, attribute access no longer allowed. 2) When I create a new location using epsg codes, next button is not enabled since I don't press Browse codes, even if I already typed the desired code. Then, I remember that when I created locations with epsg=3003, GRASS asked me to select an option for towgs84 parameters; now GRASS asks me only for Datum Transformation without showing descriptions for the options (and narrows button don't work too, I need to enter the option manually) Thanks and goodnight Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: R: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer
Hi Moritz, personally, I think the information about the GDAL, proj, etc are minor compared to the info about postgresql. Maybe you could just add a ** with a note packages containing libraries and binaries, all others only contain library files, or something similar. Please, check if it works for you now. It's late here, and my brain continues to fail connections (brain ping errors!), so you'll probably need to fix my english errors ;-) Goodnight Marco -Messaggio originale- Da: Moritz Lennert [mailto:[EMAIL PROTECTED] Inviato: giovedì 27 marzo 2008 23.23 A: Marco Pasetti Cc: 'GRASS Developer Mailing List' Oggetto: Re: R: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer On Thu, March 27, 2008 23:06, Marco Pasetti wrote: Hi Moritz, Just one last remark: IIRC, for PostgreSQL you only provide the libpg.dll, not the entire postgresql installation. This should be mentioned. And what about sqlite ? Did you include the sqlite.exe ? For PostgreSQL I provide only libpq.dll, while for SQLite I provide *all the build*, that is also sqlite.exe. On the same way, should I notice also further info for Tcl/Tk (as for SQLite, I provide *all the build* of it)? But this would open a *pandora's box*, because on this way I should specify also what files I exactly provide from other stuffs (such as tiff, gdal, proj) Opened to all suggestions ;-) personally, I think the information about the GDAL, proj, etc are minor compared to the info about postgresql. Maybe you could just add a ** with a note packages containing libraries and binaries, all others only contain library files, or something similar. Moritz Marco -Messaggio originale- Da: Moritz Lennert [mailto:[EMAIL PROTECTED] Inviato: giovedì 27 marzo 2008 22.59 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer On Thu, March 27, 2008 22:46, Marco Pasetti wrote: Hi all, Thanks for all the suggestions: I modified the document, and finally it sounds good for me: http://www.webalice.it/marco.pasetti/temp/README.html So, let's start the poll! ;-) Just one last remark: IIRC, for PostgreSQL you only provide the libpg.dll, not the entire postgresql installation. This should be mentioned. And what about sqlite ? Did you include the sqlite.exe ? Moritz Marco ___ 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
[GRASS-dev] WinGRASS-6.3.0RC6: First Impressions
Hi, I just built RC6; first impressions: 1) make procedure fails creating symbolic links d.paint.labels, r.cats and p.out.vrml; as temporary solution I fixed the problem manually creating symbolic links after make procedure; it seems that MinGW needs the full path for both target and link name... 2) About GRASS (from Help menu) works now 3) I opened some exixsting projects, applied some commands and used NVIZ; all seems to works fine; good job folks! ;-) More testing is needed, but at the moment I don't have enough time :-( I'm planning self installer release for tomorrow (with new zipped MSYS environment, readme files and guide updates) 4) I started the new python GUI: the first screen is OK (very beautiful... but the fonts seem to be a little bit too small for me... probably I need new glasses :-D), but loading a mapset it returns an error and exits; the first time it reported and error with a *classic* windows message box, then, when I restarted it, it displayed the following *only MSYS* message: [EMAIL PROTECTED] /usr/local/bin $ grass63 -wxpython Cleaning up temporary files. Starting GRASS ... Traceback (most recent call last): File C:/MSYS/local/grass-6.3.0RC6/etc/wxpython/gis_set.py, line 31, in module from gui_modules import globalvar File C:\MSYS\local\grass-6.3.0RC6\etc\wxpython\gui_modules\globalvar.py, line 27, in module import wx File C:\DevTools\Python\Lib\site-packages\wx-2.8-msw-unicode\wx\__init__.py, line 45, in module from wx._core import * File C:\DevTools\Python\Lib\site-packages\wx-2.8-msw-unicode\wx\_core.py, line 14526, in module from _windows import * ValueError: bad marshal data Error in GUI startup. If necessary, please report this error to the GRASS developers. Switching to text mode now. Hit RETURN to continue... That's all at the moment. Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] R: [gdal-dev] GDAL/OGR 1.5.1 Released
Very good news! Markus et al., I think that I'll add it to the upcoming winGRASS-6.3.0RC6 release... Right? Regards, Marco Pasetti -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Frank Warmerdam Inviato: giovedì 20 marzo 2008 23.00 A: [EMAIL PROTECTED]; gdal-dev Oggetto: [gdal-dev] GDAL/OGR 1.5.1 Released Folks, The GDAL/OGR project is pleased to announce the release of GDAL/OGR 1.5.1. This is a bug fix release improving on the December 2007 1.5.0 release. There are no substantial new features. NEWS: http://trac.osgeo.org/gdal/wiki/Release/1.5.1-News Source: http://download.osgeo.org/gdal/gdal-1.5.1.tar.gz http://download.osgeo.org/gdal/gdal151.zip Best regards, -- ---+ ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ gdal-dev mailing list [EMAIL PROTECTED] http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] WinGRASS-6.3.0RC5 Self Installer
Hi,
I forgot to reply to *this* in the previous mail:
Just looking at your building guide [2], I see that you do not do a 'make
install' but copy the files directly from the dist.* dir to $GISBASE.
Actually the 'make install' step is necessary as this corrects a series of
path issues in the files for windows. This might be the cause of your
problems with spaces (although I'm only guessing - I'll try to install my
package in a directory with spaces to test). Any specific reason why you did
not want to go through the make install step ?
Sorry, but it don't definetely depends on it. *make install* windows path
corrections are only for the selected installation, so, if you want to
install on another machine, you must repeat all those *corrections* starting
from build files folder; and its exactly what I did with my install script;
but it remains the fact that, if you select a installation dir with spaces,
it creates errors such as:
- No help pages from main help menu (no message displayed)
- No NVIZ (child process exited abnormally)
Marco
-Messaggio originale-
Da: Moritz Lennert [mailto:[EMAIL PROTECTED]
Inviato: giovedì 13 marzo 2008 11.51
A: Marco Pasetti
Cc: 'Glynn Clements'; 'Michael Barton'; grass-dev@lists.osgeo.org
Oggetto: Re: R: R: R: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer
On 12/03/08 21:32, Marco Pasetti wrote:
Hi Glynn,
Please note that, if you provide binaries which are covered by the
GPL, you
must provide the corresponding source code for download *from the same
place*. It isn't sufficient to point to the source on a different site.
[...]
I think that this is a problem I should don't care, actually. I asked
the list if there were problems about that and I had the green
light... If you don't agree, I think you should discuss the matter
with other persons, I don't have the knowledge to neither reply nor
discuss it.
I don't think this is an appropriate answer. Glynn did not necessarily mean
that you are the one that has to host these files. In fact they should be on
the osgeo GRASS site next to the installer, but to just shrug it off this
way is not the way to go. Making sources available is a fundamental element
of free software.
Also, just to correct things a bit, this was discussed before, offlist:
On 29/02/08 18:02, Moritz Lennert wrote:
On 29/02/08 11:04, [EMAIL PROTECTED] wrote:
This said, if we start to officially distribute binary packages with
thelibraries included, we also have to make the source code of all
theselibraries (and obvioiusly of GRASS) available...
sorry, that's my fault... ;-) I meant only to prepare a self installer
of GRASS Well, de facto we are already officially distributing
packages, but they have been declared experimental, so maybe we can
argue this as an excuse. I always meant to do the work you just did and
recompile everything and then keep the source code. I think that if you
could provide the binary package plus a directory which contains all the
source tarballs you used and your compilation information, this would be
perfect. If you rather have me host these files, I can do so as well.
So, to shorten a long discussion, I just used this simple command line to
download all the source packages mentioned in your guide:
for i in `grep source code BuildFromSource.html | awk -F'=' '{print $3}' |
awk -F'' '{print $2}' | sort`; do wget $i; done
And I downloaded the msys, flex and bison sources manually.
Everything is available at
http://geog-pc40.ulb.ac.be/grass/wingrass/wingrass_sources/ including the
version of the GRASS sources you used (don't think this is necessary, but
just to be complete). All packages are available individually, and there
also is a wingrass_sources.tar which contains them all.
Maybe Markus can just get the tar and put it on the download site next to
the installer ?
I hope you understand that this is an attempt to make your work even more
perfect than it already is :-)
What's the problem with spaces? If any part of GRASS can't handle
spaces in
filenames, that's a bug which should be fixed.
I think that forcing users to install GRASS in a space free dir is,
at the moment, the only solution to let us distribute winGRASS with a
simple one-touch installation procedure.
Again, I agree with Glynn: if there is a problem let's try to fix it and not
circumvent it. Your great installer will help a lot in getting people to
install and test GRASS on windows, but if we already force such solutions
on them, they will not be able to correctly detect the problem. Is there a
way of just making the installer print a warning, instead of breaking off
the installation procedure.
Just looking at your building guide [2], I see that you do not do a 'make
install' but copy the files directly from the dist.* dir to $GISBASE.
Actually the 'make install' step is necessary as this corrects a series of
path issues in the files for windows. This might be the cause of your
[GRASS-dev] WinGRASS-6.3.0RC5 Self Installer
Glynn, In fact, I'm quite worried that the main consequence of an easy-to-use installer could be a large number of useless bug reports which don't provide any useful information and just end up distracting (and possibly de-motivating) the developers who are working on the Windows version. Anyone who wants a robust version of GRASS for Windows should be using the Cygwin version. Thanks a lot for de-motivating ME on working this way! Actually, I really could have spent all those hours and energies to do something else, ...my thesis, for example. If you think that my work is not only useless for WinGRASS, but even counterproductive for it, I can stop it right now. It really would be a great saving of wasted time! Marco -Messaggio originale- Da: Glynn Clements [mailto:[EMAIL PROTECTED] Inviato: venerdì 14 marzo 2008 20.34 A: [EMAIL PROTECTED] Cc: Moritz Lennert; Michael Barton; grass-dev@lists.osgeo.org Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer [EMAIL PROTECTED] wrote: Again, I agree with Glynn: if there is a problem let's try to fix it and not circumvent it. Your great installer will help a lot in getting people to install and test GRASS on windows, but if we already force such solutions on them, they will not be able to correctly detect the problem. Is there a way of just making the installer print a warning, instead of breaking off the installation procedure. I decided to force a working installation for the following reason: the aim of all this work is, obviously, to spread GRASS as most as possible, because there are a lot of Windows users out there... so, to convince them to use GRASS, we need to be sure that it will definetely work on their machines, because Windows users are not used to *test* software and report bugs... they just use it, and when it doesn't work (for many reasons, also because they didn't followed installation warnings, and they're used to) they just say: I told you! opensource softwares are good only for listen music or let kids chat with friends! if you need it for your job, you must buy a commercial fully working release! You seem to be overlooking one major point: WinGRASS is currently at an *alpha* stage. Anyone who isn't willing to tolerate some bugs and rough edges is going to be unhappy with it. Right now, we need more testers for Windows. We don't need more users. In fact, I'm quite worried that the main consequence of an easy-to-use installer could be a large number of useless bug reports which don't provide any useful information and just end up distracting (and possibly de-motivating) the developers who are working on the Windows version. Anyone who wants a robust version of GRASS for Windows should be using the Cygwin version. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] WinGRASS-6.3.0RC5 Self Installer
Sorry, confused: what? This WARNING: you are about to install GRASS into a directory that has spaces in either its name or the path of directories leading up to it. Some functionalities of GRASS might be hampered by this. We would highly appreciate if you tried and reported any problems, so that we can fix them. However, if you want to avoid any such issues, we recommended that you choose a simple installation path without spaces such as: C:\GRASS. Or this? WARNING: you are about to install GRASS into a directory that has spaces in either its name or the path of directories leading up to it. You may go ahead, but without customization of some GRASS modules, you may encounter unexpected behaviour or failure of some functions. It is highly recommended to choose a simple installation path without spaces such as: C:\GRASS. Marco -Messaggio originale- Da: Michael Barton [mailto:[EMAIL PROTECTED] Per conto di Michael Barton Inviato: venerdì 14 marzo 2008 16.24 A: Moritz Lennert Cc: [EMAIL PROTECTED]; Glynn Clements; grass-dev@lists.osgeo.org Oggetto: Re: R: WinGRASS-6.3.0RC5 Self Installer I like this. Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton On Mar 14, 2008, at 5:24 AM, Moritz Lennert wrote: On 14/03/08 12:08, [EMAIL PROTECTED] wrote: Hi, Please, suggest me also the message to display. Benjamin suggested as follows: WARNING: you are about to install GRASS into a directory that has spaces in either its name or the path of directories leading up to it. You may go ahead, but expect trouble and weird behaviour from GRASS modules. It is highly recommended to choose a simple installation path without spaces such as: C:\GRASS. I find this a bit too strong. How about WARNING: you are about to install GRASS into a directory that has spaces in either its name or the path of directories leading up to it. Some functionalities of GRASS might be hampered by this. We would highly appreciate if you tried and reported any problems, so that we can fix them. However, if you want to avoid any such issues, we recommended that you choose a simple installation path without spaces such as: C:\GRASS. Moritz Marco - --- *Da:* Moritz Lennert [mailto:[EMAIL PROTECTED] *Inviato:* ven 14/03/2008 10.38 *A:* [EMAIL PROTECTED] *Cc:* Glynn Clements; Michael Barton; grass-dev@lists.osgeo.org *Oggetto:* Re: WinGRASS-6.3.0RC5 Self Installer On 14/03/08 10:25, [EMAIL PROTECTED] wrote: Hi all, sorry for the late, I'm really drowning in workflows... I don't think this is an appropriate answer. I'm really afraid, I didn't want to give a bad answer! I apologise if I did something wrong! No problem. This said, if you prefer to not have a *forced* installation, I'll prepare a *only warnings* one; just tell me what I have to do... +1 for the only warnings version. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer
Paul, As I said in previous e-mails, in next weeks I'll have enough time to compile and test grass_trunk, even if recent comments let me reflect on how useful is all this work... Marco -Messaggio originale- Da: Paul Kelly [mailto:[EMAIL PROTECTED] Inviato: sabato 15 marzo 2008 12.30 A: Marco Pasetti Cc: 'Moritz Lennert'; 'Glynn Clements'; 'Michael Barton'; grass-dev@lists.osgeo.org Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer On Sat, 15 Mar 2008, Marco Pasetti wrote: [...] - No help pages from main help menu (no message displayed) As I think I mentioned in an earlier e-mail, I suspect this is due to the problem with the Windows _spawn* functions and arguments with spaces in them. I managed to find the earlier patch to g.parser I proposed, but which I am still not very sure about: http://lists.osgeo.org/pipermail/grass-dev/2007-June/031931.html Maybe we could test if this removes the problem? Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer
Hi Michael, Markus has uploaded all my recent jobs (excluding the building guide) at http://grass.osgeo.org/grass63/binary/mswindows/ Goodnight, Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Michael Barton Inviato: mercoledì 12 marzo 2008 0.43 A: grass-dev@lists.osgeo.org Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer On Mar 11, 2008, at 11:52 AM, [EMAIL PROTECTED] wrote: Date: Tue, 11 Mar 2008 13:20:59 +0100 From: [EMAIL PROTECTED] Subject: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer To: grass-dev@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 WinGRASS Self Installer has been temporarily deleted from www.laser4000.it/temp/ I'm fixing some minor bugs; it will be available again whithin few hours at another internet location please be patient ;-) I'm working for you Marco -- next part -- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/ 20080311/9512ee49/attachment-0001.html -- Marco, I just want to say thank you again on behalf of all the windows users among my students. As soon as the download location gets worked out, I'll make a general announcement to the class. They'll be thrilled. Michael ___ 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
R: R: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer
Hi Michael, Hehehe... I would reply just try ;-) ... but it's not politically correct ;-) In the pure MS style, installer includes all: tcl/tk, sqlite, postgresql (the last only dll) built from source, and prebuilt msys from sourceforge project. Moreover, the installer procedure forces the user to install GRASS in a path without spaces, to let it wotk properly, and then dynamically creates: - grass63.bat, to correctly configure GRASS, basing on user selected install path - grass63, to let user launch GRASS from shell (configuring GISBASE and PATH variables accordingly to selected install path) - .grassrc6, to avoid the common first GRASS launch error - desktop shortcut to grass63.bat (to directly launch GRASS 6.3.0RC5) - StartMenu shortcuts to grass63.bat (to directly launch GRASS 6.3.0RC5) and msys.bat (to open an MSYS console) As an option, users can also download and install Spearfish GRASS sample DataBase during installation. Am I cool or not?? ;-DDD (I'm joking) Sorry, but now I need to go to bed. I must wake up until less than 6 hours; when it's late I have difficulties to write in italian... just imagine if I must write in english!! Goodnight Marco -Messaggio originale- Da: Michael Barton [mailto:[EMAIL PROTECTED] Per conto di Michael Barton Inviato: mercoledì 12 marzo 2008 1.06 A: Marco Pasetti Cc: grass-dev@lists.osgeo.org Oggetto: Re: R: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer Marco, Thanks very much. Does the wingrass...setup.exe file include tcltk and msys? Or do these need to be installed separately? Also, if msys is already installed, does it need to be installed again from your version? Thanks Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton On Mar 11, 2008, at 8:03 PM, Marco Pasetti wrote: Hi Michael, Markus has uploaded all my recent jobs (excluding the building guide) at http://grass.osgeo.org/grass63/binary/mswindows/ Goodnight, Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Michael Barton Inviato: mercoledì 12 marzo 2008 0.43 A: grass-dev@lists.osgeo.org Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer On Mar 11, 2008, at 11:52 AM, [EMAIL PROTECTED] wrote: Date: Tue, 11 Mar 2008 13:20:59 +0100 From: [EMAIL PROTECTED] Subject: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer To: grass-dev@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 WinGRASS Self Installer has been temporarily deleted from www.laser4000.it/temp/ I'm fixing some minor bugs; it will be available again whithin few hours at another internet location please be patient ;-) I'm working for you Marco -- next part -- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/ 20080311/9512ee49/attachment-0001.html -- Marco, I just want to say thank you again on behalf of all the windows users among my students. As soon as the download location gets worked out, I'll make a general announcement to the class. They'll be thrilled. Michael ___ 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
[GRASS-dev] winGRASS Self Installer Package
Hi, I'm preparing a winGRASS self installer package, but I'm not sure about what files include in the package from PostgreSQL and SQLite install; Since now I included only libpq.dll (for PostgreSQL) and libsqlite3-0.dll (for SQLite); unfortunately I'm not able to use database instructions in GRASS, so I cannot know if some files are required or not! While SQLite is a very light utility (for all files), PostgreSQL requires lot of space (quite 30 MB!!!) for a complete inclusion in a GRASS self contained package. Can someone help me, please? Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support
Hi Markus, I already checked it out... but it seems that there's still not a grass-plugin for latest gdal release (1.5.0); the last I found is for gdal 1.4.3 Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Markus Neteler Inviato: martedì 4 marzo 2008 22.41 A: Marco Pasetti Cc: grass-dev@lists.osgeo.org Oggetto: Re: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support Hi Marco, please don't build GDAL with direct GRASS support but use the plugin instead (way easier...). See http://grass.gdf-hannover.de/wiki/Compile_and_install_GRASS_and_QGIS_with_GD AL/OGR_Plugin cheers Markus On Tue, Mar 4, 2008 at 9:24 PM, Marco Pasetti [EMAIL PROTECTED] wrote: Problem fixed needed only to add --with-local=/usr/local in configure Marco Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di [EMAIL PROTECTED] Inviato: martedì 4 marzo 2008 18.03 A: grass-dev@lists.osgeo.org Oggetto: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support Hi, I'm building GDAL 1.5.0 with GRASS support; it gives the following error: In file included from grass57dataset.cpp:45: C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:23:22: proj_api.h: No such file or directory In file included from grass57dataset.cpp:45: C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: ISO C++ forbids declaration of `projPJ' with no type C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: expected `;' before '*' token make[2]: *** [../o/grass57dataset.o] Error 1 make[2]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts/grass' make[1]: *** [grass-install-obj] Error 2 make[1]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts' make: *** [frmts-target] Error 2 proj_api.h is present in /usr/local/include, while /usr/local/grass-6.3.0RC5/include/grass has gproj_api.h should I force GRASS code to include gproj_api.h instead of proj_api.h or walk around the problem adding /usr/local/include to PATH before launch make command? Thanks Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] New Binary Package Project for winGRASS
Hi, I decided to change the subject of the mail to a better one, and then to send the mail to the list, as I should have done before (sorry for the mistake). Let we start from this: I think that if you could provide the binary package plus a directory which contains all the source tarballs you used and your compilation information, this would be perfect. If you rather have me host these files, I can do so as well. If you can, then that's perfect and I officially pass on the responsibility for maintaining the windows binary packages (cc to Markus for info). I will obviously continue to help you and try to debug whenever possible. I have started to add some ToDo's on the Wingrass Status wiki page. This is probably the best place to keep track of what still needs to be done. So, as soon as your package of libraries (and header files) is ready, could you let me know where I can get it, so that I can adapt my build system to that ? I'm very excited about that, that is officially contribute to a such important family ;-) ...but it's the first time for me (I mean about software releasing and all things related), so I guess that I need to learn some things before... That's my questions: For an user-oriented self installer: 1. because I added some extra-supports in GRASS (such as PostgreSQL, SQLite and ActiveTcl), I could use Dependency Walker to securely check what files are needed and then add them in ../bin dir, in order to prepare a self contained package/installer, whitout the need of asking the user to install other pieces of software; but, can I do that (I mean about licenses, permissions, and so on...)? About PostgreSQL and SQLite I rebuilt packages from source, while about ActiveTcl I used prebuit windows installer. 2. since the new wxPython GUI still doesn't work on windows (for RC05, I'll check on trunk in the next days), I think that we can avoid to include it in the RC05 package as requirement; why tell the user to install Python and wxPython if the new GUI doesn't work? 3. do we really need MSYS? Quantum GIS self installer still have MSYS inside (only few files), whithout the need of installing it separately. Can we do do the same? For development-oriented package: I thought about the following options: 1. pack all the MSYS local folder, excluding sources; all the applications and libraries included has been built by source with MSYS/MinGW, excluding Flex and Bison, for which I used prebuilt binaries packages from sourceforge GNUWin32 Project; 2. pack all the MSYS local folder, including sources for all the libraries/applications built; 3. pack all the MSYS environment, including MinGW installation, local folder and sources; actually, I think that both MSYS and MinGW don't need to be installed from related installers, you can just copy all the MSYS folder to your local hard drive. While for the compilation information i could: 1. add a pdf print of the html guide 2. add a simple text (txt) copy of the html guide Sounds perfect. You can put the link here: http://grass.gdf-hannover.de/wiki/Compile_and_Install#MS-Windows.2Fnative and we could erase this part http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status#Compiling_by_your self and just link to the previous wiki page. So I'll need to subscribe, log-in, delete previous entries and the simply add a ... see here for instructions link? Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] New Binary Package Project for winGRASS
Hi Martin, Be careful with the guide, it's still a WIP: refresh it regularly, updates are on the road... (even if I think that GRASS section is almost complete) Related to this (the guide): what do you think about keeping GRASS + Quantum GIS building guide together? Actually some things (like expat, geos and gsl) are not needed by GRASS, but they are for QGIS. Should I prepare two different documents, one for GRASS only and one for both GRASS and QGIS (since I actually don't see great utility of using QGIS without GRASS plugin, which is instead a great feature of QGIS, specially for not advanced users)? PS: thanks for the great ;-) -Messaggio originale- Da: Martin Landa [mailto:[EMAIL PROTECTED] Inviato: sabato 1 marzo 2008 14.00 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS Ciao Marco, 2008/3/1, Marco Pasetti [EMAIL PROTECTED]: [snip] 2. since the new wxPython GUI still doesn't work on windows (for RC05, I'll check on trunk in the next days), I think that we can avoid to include it in the RC05 package as requirement; why tell the user to install Python and wxPython if the new GUI doesn't work? right now I am following your great installation guide, then I will try to make wxGUI working on Windows too (basic features for now). Without functional wxGUI doesn't make sense to require at least wxPython, Python maybe because of SWIG interface. [snip] 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
R: R: [GRASS-dev] New Binary Package Project for winGRASS
Hi, maybe it would be better, or at least to make note like this package is required for GRASS compilation, etc. Ok. I'll do that later, before to release the final version. What about GEOS, GSL and Expat? Actually, GRASS uses none of them, but GDAL uses GEOS, I'm not sure if it uses GSL (even if I think not) and it would use Expat ...if I could be able to enable that support in GDAL :-) So, summarizing, for the GRASS guide only, should I remove GSL, Expat and GEOS or leave only GEOS? Marco -Messaggio originale- Da: Martin Landa [mailto:[EMAIL PROTECTED] Inviato: sabato 1 marzo 2008 14.44 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: R: [GRASS-dev] New Binary Package Project for winGRASS Hi, 2008/3/1, Marco Pasetti [EMAIL PROTECTED]: Related to this (the guide): what do you think about keeping GRASS + Quantum GIS building guide together? Actually some things (like expat, geos and gsl) are not needed by GRASS, but they are for QGIS. Should I prepare two different documents, one for GRASS only and one for both GRASS and QGIS maybe it would be better, or at least to make note like this package is required for GRASS compilation, etc. 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
[GRASS-dev] R: winGRASS-6.3.0RC5
Hi, 3) Help (button) in module GUI fails; I try to translate Firefox message from italian: Firefox can't open this address because the (c) protocol is not associated with any application Funny, I don't have this problem, even without GRASS_SH being set... Are you sure that the html man pages have been created correctly ? Check $GISBASE/docs/html. Yes, html man pages are all correctly created! But Firefox still reports the same message! Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] winGRASS RC5 Fails on Creating a New Projection
Hi, From startpanel, define new location with epsg codes Used 4326 for WGS84 Returned the following message: g.proj returned the following informational message: child killed: SIGABRT Why? Thanks Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] New Binary Package Project for winGRASS
Hi Benjamin, Why use ActiveTcl? The regular, GPL'd Tcl compiles without any problems and can be distributed freely. Good question! When I planned the work I dind't considered this option, because on the wiki it was (it is) suggested to use ActiveTcl; Probably I should reconsider to build Tcl/Tk from source using MinGW, and then rebuild GRASS... Moritz, what do you think about? Would also be interesting to know how 8.5 is working on Win. AFAIK there are some problems for GRASS with 8.5, I read it in the list in the last weeks. Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Benjamin Ducke Inviato: sabato 1 marzo 2008 21.45 Cc: GRASS Developer Mailing List Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS Marco Pasetti wrote: 1. because I added some extra-supports in GRASS (such as PostgreSQL, SQLite and ActiveTcl), I could use Dependency Walker to securely check what files are needed and then add them in ../bin dir, in order to prepare a self contained package/installer, whitout the need of asking the user to install other pieces of software; but, can I do that (I mean about licenses, permissions, and so on...)? About PostgreSQL and SQLite I rebuilt packages from source, while about ActiveTcl I used prebuit windows installer. Why use ActiveTcl? The regular, GPL'd Tcl compiles without any problems and can be distributed freely. Would also be interesting to know how 8.5 is working on Win. 3. do we really need MSYS? Quantum GIS self installer still have MSYS inside (only few files), whithout the need of installing it separately. Can we do do the same? Yes, please. The sh interpreter is vastly superior to cmd.exe. -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg ___ 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
R: [GRASS-dev] winGRASS 6.3.0RC5 errors
OK, I intalled Python Extensions (pywin32-210.win32-py2.5.exe) for Windows from http://downloads.sourceforge.net/pywin32/pywin32-210.win32-py2.5.exe http://downloads.sourceforge.net/pywin32/ Relaunched grass63 -wxpython Now the new error is: Starting GRASS ... Traceback (most recent call last): File C:/MSYS/local/grass-6.3.0RC5/etc/wxpython/gis_set.py, line 690, in module GRASSStartUp = StartUp(0) File C:\DevTools\Python\Lib\site-packages\wx-2.8-msw-unicode\wx\_core.py, line 7836, in __init__ self._BootstrapApp() File C:\DevTools\Python\Lib\site-packages\wx-2.8-msw-unicode\wx\_core.py, line 7433, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File C:/MSYS/local/grass-6.3.0RC5/etc/wxpython/gis_set.py, line 674, in OnInit StartUp = GRASSStartup() File C:/MSYS/local/grass-6.3.0RC5/etc/wxpython/gis_set.py, line 45, in __init__ self.grassrc = self._read_grassrc() File C:/MSYS/local/grass-6.3.0RC5/etc/wxpython/gis_set.py, line 356, in _read_grassrc key, val = line.split(:) ValueError: too many values to unpack Error in GUI startup. If necessary, please report this error to the GRASS developers. Switching to text mode now. Hit RETURN to continue... Ideas? Suggestions? Thanks Marco _ Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di [EMAIL PROTECTED] Inviato: giovedì 28 febbraio 2008 18.43 A: grass-dev@lists.osgeo.org Oggetto: [GRASS-dev] winGRASS 6.3.0RC5 errors Hi all, I just compiled GRASS 6.3.0RC5 on Windows using MinGW; I report the following errors: 1) grass63.bat doesn't work! it says: ERROR: LOCATION_NAME not set where should I set it? my grass63.bat is configured as follows: @echo off rem # rem # rem # GRASS Initialization rem # rem # rem ***Environment variables*** rem Uncomment and set the following values if they differ from the indicated default rem Directory where your .grassrc6 file will be stored set HOME=%USERPROFILE% rem Name of the wish (Tk) executable set GRASS_WISH=wish.exe rem Path to the shell command rem (adjust to where you installed msys or another shell) set GRASS_SH=c:\msys\bin\sh.exe rem Path to utilities used by some scripts, such as awk, sed, etc rem (adjust to where you installed msys, gnuwin32, or other similar utilises) set PATH=%PATH%;c:\msys\bin;c:\msys\lib;c:\devtools\python rem Path to your web browser set GRASS_HTML_BROWSER=%PROGRAMFILES%\Mozilla Firefox\firefox.exe rem Path to the proj files (notably the epsg projection list) set GRASS_PROJSHARE=c:\msys\local\share\proj set WINGISBASE=c:\msys\local\grass-6.3.0RC5 %WINGISBASE%\etc\init.bat %* 2) If I start grass63 from MSYS it's ok, while if I start with -wxpython it says $ grass63 -wxpython WELCOME TO GRASS Version 6.3.0RC5 2008 1) Have at your side all available GRASS tutorials 2) When working on your location, the following materials are extremely useful: - A topo map of your area - Current catalog of available computer maps 3) Check the GRASS webpages for feedback mailinglists and more: http://www.grass-gis.org http://www.grass-gis.org http://grass.osgeo.org http://grass.osgeo.org Hit RETURN to continue Starting GRASS ... Traceback (most recent call last): File C:/MSYS/local/grass-6.3.0RC5/etc/wxpython/gis_set.py, line 688, in module import gui_modules.gcmd as gcmd File C:\MSYS\local\grass-6.3.0RC5\etc\wxpython\gui_modules\gcmd.py, line 38, in module from win32file import ReadFile, WriteFile ImportError: No module named win32file Error in GUI startup. If necessary, please report this error to the GRASS developers. Switching to text mode now. Hit RETURN to continue... Redirection is not supported. mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] /usr/local/bin Thanks for your help Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Python Tcl/Tk
Hi all, I just installed Python 2.51 for Windows, and I noticed that it contains Tcl/Tk... Is it all we need for GRASS or do I need to install also Activestate Tcl? Thanks Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] PROJ.4 dll usage
Hi all, I just built a win32 PROJ.4 dll (v.4.6.0) It seems to work, but I don't know how to use it in order to test it Could someone give me an example (a line command usage... I don't know if is it possible) with the guessed results? Thanks Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] PostgreSQL and SQLite
Ciao, To enable support of PostgreSQL and SQLite in GRASS Win Native (and then in QGIS) should I install them using windows installer, or do I need only library and headers, or, for PostgreSQL, unpack in /usr/local the zip of the PostgreSQL installation directory (postgresql-binaries-no-installer.zip)? Thanks for help Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] Can I trust libtool?
Good news Thanks ;-) MP -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Ivan Shmakov Inviato: lunedì 11 febbraio 2008 19.14 A: grass-dev@lists.osgeo.org Cc: Ivan Shmakov Oggetto: Re: [GRASS-dev] Can I trust libtool? [EMAIL PROTECTED] writes: Hi, I started to build on Windows (MSYS/MinGW) latest releases of GRASS required libraries (zlib, libpng, and so on...) and I thought everything was going well... but (occasionally) browsing /usr/lib dir I found NO dlls of what I built, only .a and .la libraries, while I found dlls in /usr/bin... [...] I'm not familiar with W32, but IIRC, the dynamic libraries are searched in PATH on W32. Since /usr/bin is much more likely to be in PATH than /usr/lib, I deem this behaviour as correct. There're bugs in any software, and libtool is hardly an exception, but after using it for quite some time, I'd say that it's reliable enough. ___ 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
