Re: [GRASS-dev] Handling of Python scripts on MS Windows
On Wed, Oct 2, 2013 at 12:32 PM, Pietro wrote: > Hi Vaclav, > > On Wed, Oct 2, 2013 at 3:47 PM, Vaclav Petras > wrote: > > I'm always for pure, correct and clean solutions. However, I'm not expert > > neither in MS Windows registry nor in Python virtual environments nor in > > covering .py to .exe and nobody provided other implementation, so I > provided > > mine which is messy but it only reflects mess which I---maybe just > because > > of my lack of knowledge---see on that system. > > Maybe, to resolve this issue, we can integrate in the windows > installer the virtualenv[0] python package, as reported in the link: > "virtualenv is a tool to create isolated Python environments". It > should works with Windows... but I never used on this platform... I'm > using virtualenv on linux, because the default python interpreter on > my distribution is python3.x, and in this way I can easily test GRASS > using different python versions (2.4, 2.6, 2.7). > > I'm ignorant on Windows and maybe virtualenv is useless in this > case... or maybe integrate virtualenv on the windows installer is too > complex, I have no clue! > Hi, the question is: is anyone going to resolve this issue? Currently this is a blocker for many Windows users which we can loose easily if we don't provide solution soon enough. Is this workaround worse than all the others which are already there? Anna > > Pietro > > [0] https://pypi.python.org/pypi/virtualenv > ___ > 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] Handling of Python scripts on MS Windows
Hi Vaclav, On Wed, Oct 2, 2013 at 3:47 PM, Vaclav Petras wrote: > I'm always for pure, correct and clean solutions. However, I'm not expert > neither in MS Windows registry nor in Python virtual environments nor in > covering .py to .exe and nobody provided other implementation, so I provided > mine which is messy but it only reflects mess which I---maybe just because > of my lack of knowledge---see on that system. Maybe, to resolve this issue, we can integrate in the windows installer the virtualenv[0] python package, as reported in the link: "virtualenv is a tool to create isolated Python environments". It should works with Windows... but I never used on this platform... I'm using virtualenv on linux, because the default python interpreter on my distribution is python3.x, and in this way I can easily test GRASS using different python versions (2.4, 2.6, 2.7). I'm ignorant on Windows and maybe virtualenv is useless in this case... or maybe integrate virtualenv on the windows installer is too complex, I have no clue! Pietro [0] https://pypi.python.org/pypi/virtualenv ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Handling of Python scripts on MS Windows
On 02/10/13 16:47, Vaclav Petras wrote: I'm always for pure, correct and clean solutions. However, I'm not expert neither in MS Windows registry nor in Python virtual environments nor in covering .py to .exe and nobody provided other implementation, so I provided mine which is messy but it only reflects mess which I---maybe just because of my lack of knowledge---see on that system. I don't vote for my change to be permanent if we find a different solution. But the fact is that scripts are not working now (for large number of people) and this is the only solution we have. Like with democracy which not perfect but it is the best political system available. I understand the frustration, but I do agree with Glynn that sometimes hack solutions are worse than no solution, as they cover (and make us forget) the underlying problem. And as this is a fundamental issue, I think we just have to be patient until someone finds the best solution. I'm no Python expert at all, and don't have much time currently to look any further into any of this, but have you tried the python launcher as a possible path as outlined in [1] ? Moritz [1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html Vaclav [r57910] https://trac.osgeo.org/grass/changeset/57910 [r57911] https://trac.osgeo.org/grass/changeset/57911 [#2039] http://trac.osgeo.org/grass/ticket/2039 [#2015] http://trac.osgeo.org/grass/ticket/2015 On Wed, Oct 2, 2013 at 7:16 AM, Glynn Clements mailto:gl...@gclements.plus.com>> wrote: Vaclav Petras wrote: > Anna and I have fixed the script handing on MS Windows. Modules which are > Python scripts and/or are from GRASS addons and/or calls other modules > which are Python scripts didn't worked for various reasons. The changeset > r57910 should fix them all (and thus should fix #2039, particularly the > MAXREPEAT error). Note that I've removed the hacks from core.py. So whatever bugs they were trying to work around will have to be fixed where they originate. -- Glynn Clements mailto:gl...@gclements.plus.com>> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Handling of Python scripts on MS Windows
Comparing to unix-like systems, MS Windows works strangely in terms of executing programs (and scripts). Additionally, MS Windows don't have package manager and packagers which would take care of incompatibilities between applications. Moreover, most of the MS Windows applications behaves in the way that they are the best and the only application on the system, so they just associate every possible file with their programs (and interpreters). I'm always for pure, correct and clean solutions. However, I'm not expert neither in MS Windows registry nor in Python virtual environments nor in covering .py to .exe and nobody provided other implementation, so I provided mine which is messy but it only reflects mess which I---maybe just because of my lack of knowledge---see on that system. I don't vote for my change to be permanent if we find a different solution. But the fact is that scripts are not working now (for large number of people) and this is the only solution we have. Like with democracy which not perfect but it is the best political system available. Vaclav [r57910] https://trac.osgeo.org/grass/changeset/57910 [r57911] https://trac.osgeo.org/grass/changeset/57911 [#2039] http://trac.osgeo.org/grass/ticket/2039 [#2015] http://trac.osgeo.org/grass/ticket/2015 On Wed, Oct 2, 2013 at 7:16 AM, Glynn Clements wrote: > > Vaclav Petras wrote: > > > Anna and I have fixed the script handing on MS Windows. Modules which are > > Python scripts and/or are from GRASS addons and/or calls other modules > > which are Python scripts didn't worked for various reasons. The changeset > > r57910 should fix them all (and thus should fix #2039, particularly the > > MAXREPEAT error). > > Note that I've removed the hacks from core.py. So whatever bugs they > were trying to work around will have to be fixed where they originate. > > -- > Glynn Clements > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: [GRASS-user] Grass SQLite driver & math functions
Dear list,
a recent thread on user list was about SQLite and math functions support [1]
The specific problem was well investigated, but the second part of message
(having math support for SQLITE as GRASS default) could be interesting for
future developments. IMHO
2013/9/26 Markus Neteler
> Including SQLite math functions in the standard binary GRASS GIS
> distribuition could be a long term solution? I think this is the
choice
> SpatialLite did since 2.3 version.
You mean
http://www.gaia-gis.it/gaia-sins/spatialite-sql-3.0.0.html#math
hence
http://www.sqlite.org/contrib
--> "extension-functions.c (50.96 KB) contributed by Liam Healy on
2010-02-06 15:45:07
Provide mathematical and string extension functions for SQL queries
using the loadable extensions mechanism. Math: acos, asin, atan, atn2,
atan2, acosh, asinh, atanh, difference, degrees, radians, cos, sin,
tan, cot, cosh, sinh, tanh, coth, exp, log, log10, power, sign, sqrt,
square, ceil, floor, pi. String: replicate, charindex, leftstr,
rightstr, ltrim, rtrim, trim, replace, reverse, proper, padl, padr,
padc, strfilter. Aggregate: stdev, variance, mode, median,
lower_quartile, upper_quartile.
"
If you refer to this file, then it is more related to (your) SQLite
installation rather than GRASS itself since GRASS just calls SQLite.
best,
Markus
as math library is loaded by SQLite
SELECT load_extension('./libsqlitefunctions.so');
but it's not included in SQLite itself (consistently with SQLite
"lightness" strategy),
could be this library managed as an optional library when compiling GRASS
GIS
es: --with-sqlite-math
and then loaded by default (if available) when creating vector support db?
As SQLite is the default db, using this option when compiling GRASS for
binary packages, standard users could have a more powerful "field editor"
using v.db.update.
Please, consider that for many (power)users in Windows using MinGW is
really something arcane...
Do you think this approach might work?
Best regards
Enrico Gallo
[1] http://lists.osgeo.org/pipermail/grass-user/2013-September/068987.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2089: i.landsat.toar doesn't take into account the resolution difference between panchromatic and the other bands.
#2089: i.landsat.toar doesn't take into account the resolution difference
between
panchromatic and the other bands.
+---
Reporter: vesnikos| Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.0.0
Component: Imagery | Version: svn-trunk
Keywords: i.landsat.toar |Platform: All
Cpu: Unspecified |
+---
Changes (by neteler):
* keywords: => i.landsat.toar
Comment:
Did you check with the current version in GRASS 6 (the original author
confirmed the other day to me that it should behave as expected)?
Interestingly, both use the same mechanism to maintain the resolution:
{{{
[neteler@oboe ~]$ grep _get_cellhd grass64/imagery/i.landsat.toar/main.c
if (G_get_cellhd(band_in, mapset, &cellhd) < 0)
if (G_get_cellhd(band_in, mapset, &cellhd) < 0)
[neteler@oboe ~]$ grep _get_cellhd grass70/imagery/i.landsat.toar/main.c
Rast_get_cellhd(band_in, "", &cellhd);
Rast_get_cellhd(band_in, "", &cellhd);
}}}
--
Ticket URL:
GRASS GIS
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.proj: accept imagery groups as input?
Hi, it would be cool if r.proj learned to reproject entire groups (think Landsat8 scene). A challenge might be to maintain the different resolutions. Thoughts? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Handling of Python scripts on MS Windows
Vaclav Petras wrote: > Anna and I have fixed the script handing on MS Windows. Modules which are > Python scripts and/or are from GRASS addons and/or calls other modules > which are Python scripts didn't worked for various reasons. The changeset > r57910 should fix them all (and thus should fix #2039, particularly the > MAXREPEAT error). Note that I've removed the hacks from core.py. So whatever bugs they were trying to work around will have to be fixed where they originate. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.svn on AIX based supercomputers
On Tue, Oct 1, 2013 at 9:20 AM, Markus Metz
wrote:
> Have you included -R,/opt/freeware/lib in LDFLAGS? If not, you
> probably should.
In that case (I added
-Wl,-bsvr4,-R,/opt/freeware/lib
) it happily segfaults:
configure:775: checking for gcc
configure:879: checking whether the C compiler (gcc -maix64 -maix64
-Wl,-bbigtoc -Wl,-bsvr4,-R,/opt/freeware/lib64
-Wl,-bsvr4,-R,/opt/freeware/lib -L/opt/freeware/lib64) works
configure:895: gcc -o conftest -maix64 -maix64 -I/opt/freeware/include
-maix64 -Wl,-bbigtoc -Wl,-bsvr4,-R,/opt/freeware/lib64
-Wl,-bsvr4,-R,/opt/freeware/lib -L/opt/freeware/lib64 conftest.c 1>&5
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
configure: failed program was:
#line 890 "configure"
#include "confdefs.h"
main(){return(0);}
-bash-3.2$
"Guessing" gcc on AIX parameters remains to be tricky.
markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: [Proj] EPSG 8.2 Upgrade
This might be a good moment to re-vamp the legal issue regarding the EPSG license that was raised in Fedora and is blocking the upgrade of libgeotiff: https://bugzilla.redhat.com/show_bug.cgi?id=621416 They didn't respond to my query. Maybe somebody else wants to give it another try. Greetings, Volker Fröhlich Fedora On 10/02/2013 10:12 AM, Markus Neteler wrote: > FYI > > We should review our mechanism of linking to PROJ.4, especially in > terms of the included .csv files. > > Markus > > > -- Forwarded message -- > From: Frank Warmerdam > Date: Tue, 1 Oct 2013 22:46:36 -0700 > Subject: [Proj] EPSG 8.2 Upgrade > To: "PROJ.4 and general Projections Discussions" > , GeoTIFF Mailing List > , gdal dev > > Folks, > > I have upgraded libgeotiff, GDAL and PROJ.4 trunk's with > the EPSG 8.2 database definitions. I have come to the > conclusion that the EPSG Postgresql .sql files are distributed > in WIN1252 encoding, not LATIN1, and so some special > characters - mostly in comments - should be translated better. > > Let me know if you see problems or have questions. > > Best regards, > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: [Proj] EPSG 8.2 Upgrade
FYI We should review our mechanism of linking to PROJ.4, especially in terms of the included .csv files. Markus -- Forwarded message -- From: Frank Warmerdam Date: Tue, 1 Oct 2013 22:46:36 -0700 Subject: [Proj] EPSG 8.2 Upgrade To: "PROJ.4 and general Projections Discussions" , GeoTIFF Mailing List , gdal dev Folks, I have upgraded libgeotiff, GDAL and PROJ.4 trunk's with the EPSG 8.2 database definitions. I have come to the conclusion that the EPSG Postgresql .sql files are distributed in WIN1252 encoding, not LATIN1, and so some special characters - mostly in comments - should be translated better. Let me know if you see problems or have questions. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ Proj mailing list p...@lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
