Re: [GRASS-dev] [GRASS GIS] #2096: Missing libintl-8.dll from all Windows binaries

[GRASS GIS]

#2096: Missing libintl-8.dll from all Windows binaries
+---
 Reporter:  dkavanagh   |   
Owner:  martinl
 Type:  defect  |  
Status:  assigned   
 Priority:  normal  |   
Milestone:  6.4.3  
Component:  Packaging   | 
Version:  unspecified
 Keywords:  wingrass, windows, binaries, ms-windows, libintl-8.dll  |
Platform:  MSWindows 7
  Cpu:  x86-64  |  
+---

Comment(by martinl):

 I can confirm the issue with standalone installer.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Problem installing r.modis on trunk

[Martin Landa]

Hi,

2013/10/8 Pierre Roudier :
> I'm having a wee problem trying to compile r.modis on the trunk
> version of GRASS. It does not seem to compile the pymodis library if
> I'm getting that right:

[...]

> Is that a bug?

seems like that. Please report it. Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2096: Missing libintl-8.dll from all Windows binaries

[GRASS GIS]

#2096: Missing libintl-8.dll from all Windows binaries
+---
 Reporter:  dkavanagh   |   
Owner:  martinl
 Type:  defect  |  
Status:  assigned   
 Priority:  normal  |   
Milestone:  6.4.3  
Component:  Packaging   | 
Version:  unspecified
 Keywords:  wingrass, windows, binaries, ms-windows, libintl-8.dll  |
Platform:  MSWindows 7
  Cpu:  x86-64  |  
+---
Changes (by martinl):

 * cc: grass-dev@… (added)
  * keywords:  windows, binaries, ms-windows, libintl-8.dll => wingrass,
   windows, binaries, ms-windows, libintl-8.dll
  * status:  new => assigned
  * component:  Default => Packaging
  * owner:  grass-dev@… => martinl


Comment:

 This library has been recently moved to the separated package in OSGeo4W.
 You are referring to the standalone or OSGeo4W installer. Please try the
 most recent version first.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Problem installing r.modis on trunk

[Pierre Roudier]

Hi,

I'm having a wee problem trying to compile r.modis on the trunk
version of GRASS. It does not seem to compile the pymodis library if
I'm getting that right:

GRASS 7.0.svn (eda-rsr):~ > g.extension ext=r.modis
Fetching  from GRASS-Addons SVN (be patient)...
WARNING: gnome-keyring:: couldn't connect to:
/tmp/keyring-CTEtVP/pkcs11: No such file or directory
Compiling...
/bin/sh: 1: cannot create
/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c:
Directory nonexistent
sed: couldn't flush stdout: Broken pipe
make[1]: 
[/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c]
Error 2 (ignored)
/bin/sh: 1: cannot create
/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.import_to_translate.c:
Directory nonexistent
sed: couldn't flush stdout: Broken pipe
make[1]: 
[/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.import_to_translate.c]
Error 2 (ignored)
Installing...
Updating metadata file...
Installation of  successfully finished
GRASS 7.0.svn (eda-rsr):~ > r.modis.import
ERROR: modis library not found

Is that a bug?

Cheers,

Pierre

-- 
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2096: Missing libintl-8.dll from all Windows binaries

[GRASS GIS]

#2096: Missing libintl-8.dll from all Windows binaries
--+-
 Reporter:  dkavanagh |   Owner:  
grass-dev@…  
 Type:  defect|  Status:  new   
   
 Priority:  normal|   Milestone:  6.4.3 
   
Component:  Default   | Version:  
unspecified  
 Keywords:  windows, binaries, ms-windows, libintl-8.dll  |Platform:  
MSWindows 7  
  Cpu:  x86-64|  
--+-
 libintl-8.dll is missing from all current Windows binaries (6.4, 6.5, 7).
 Following error is reported:

 "The program can't start because libintl-8.dll is missing from your
 computer. Try reinstalling the program to fix this problem."

 (I am on Windows 8.)

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.lidar tuning

[Markus Neteler]

On Mon, Oct 7, 2013 at 8:28 AM, Markus Metz
 wrote:
> Markus Neteler wrote:
>
>> PS: if the LAS file is not accessible, r.in.lidar happily segfaults.
>> My attempts to fix that were yet unsuccessful.
>
>
> Fixed in r57951,2 for [r|v].in.lidar

Thanks!

One more wish comes to mind (indeed, I started cross-porting but :-)

v.in.lidar comes with a filter (which should perhaps be generalized to
the nth return; or, the last *is* the nth return but then "mid" could
be more than one in this case?):

filter   Only import points of selected return type
  If not specified, all points are imported
 options: first,last,mid

which would be great for r.in.lidar as well to avoid that I need to
split the file with las2las beforehand.

markusN
___
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

[Helmut Kudrnovsky]

>To start with, it needs to be established that Python is actually
>installed correctly. To this end, I need to see the output from the
>shell commands:
>
>assoc .py
>ftype python.file
>echo %PATHEXT% 

tested with a _not pristine_ win7 + python-installation, so more
eventualities should be reported! 

python is installed by ArcGIS on this testing box here.

ArcGIS 10.0 installed C:\Python26\ArcGIS10.0

after upgrade

ArcGIS 10.1 installed C:\Python27\ArcGIS10.1

AFAIR most of the winGRASS-users have ArcGIS 10.x installed

now above tests in a windows command line (started by windows start ->
command line - cmd.exe in a console window):

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\tmp\testpython>assoc .py
.py=Python.File

C:\tmp\testpython>ftype python.file
python.file="C:\Python27\ArcGIS10.1\python.exe" "%1" %*

C:\tmp\testpython>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

>Then, I would need to see the result of running a python script from
>the shell (that's cmd.exe in a console window, not bash, or anything
>running in MSys' rxvt, or the GUI's "command line"). 

test.py:

print "Hello, Python!";

C:\tmp\testpython\test.py

a error box pops up that test.py can't by executed because of no associated
program can be found (see echo %PATHEXT%)

please others report with other win7/8-python-confgurations



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5082254.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] G7: parameter standardization: n/count, min/minimum etc

[Markus Neteler]

Hi,

we have the confusing situation of naming the same statistic in different ways:

r.series | r.statistics2 | t.rast.aggregate.* | t.vect.what.strds
...
method   Aggregate operation
 options: average,count,median,mode,minimum,min_raster,maximum,
  max_raster,stddev,range,sum,variance,diversity,slope,
  offset,detcoeff,tvalue,quart1,quart3,perc90,quantile,
  skewness,kurtosis

r.in.lidar | r.in.xyz | r3.in.xyz | r.statistics
 method   Statistic to use for raster values
   options: n,min,max,range,sum,mean,stddev,variance,coeff_var,
median,percentile,skewness,trimmean
   default: mean

I would suggest to streamline this (and personally opt for the
r.series way of naming the methods; e.g., the "n" is easily
overlooked, the "count" less so).
Also the order might be revisited and standardized...?

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

[Glynn Clements]

Martin Landa wrote:

> @Glynn: please revert your revert or find a time to implement better solution.

First, someone would need to explain the problem. "Doesn't work" isn't
sufficient. Nor is "I have a problem and this makes it work for me".

To start with, it needs to be established that Python is actually
installed correctly. To this end, I need to see the output from the
shell commands:

assoc .py
ftype python.file
echo %PATHEXT%

Then, I would need to see the result of running a python script from
the shell (that's cmd.exe in a console window, not bash, or anything
running in MSys' rxvt, or the GUI's "command line").

If that works, but running the script from the GUI doesn't, then the
problem is in the GUI and any fix belongs in the GUI (and not e.g. 
lib/python).

-- 
Glynn Clements 
___
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

[Helmut Kudrnovsky]

Markus Neteler wrote
> On Mon, Oct 7, 2013 at 9:57 AM, Moritz Lennert
> <

> mlennert@.worldonline

> > wrote:
>> A solution might be to try to focus resources in the form of a specific
>> Windows code sprint, ideally with some Windows power hackers who could
>> help
>> us.
>>
>> BTW, it seems that the same is needed to solve the encoding issues on
>> Windows.
> 
> 
> Do we have capable programmers around? Perhaps we can co-finanze some
> effort since it is unrealistic to obtain it on a voluntary base.
> 
> Markus
> ___

see also here

http://lists.osgeo.org/pipermail/grass-psc/2013-February/001054.html



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5082169.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
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

[Markus Neteler]

On Mon, Oct 7, 2013 at 9:57 AM, Moritz Lennert
 wrote:
> A solution might be to try to focus resources in the form of a specific
> Windows code sprint, ideally with some Windows power hackers who could help
> us.
>
> BTW, it seems that the same is needed to solve the encoding issues on
> Windows.


Do we have capable programmers around? Perhaps we can co-finanze some
effort since it is unrealistic to obtain it on a voluntary base.

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

[Moritz Lennert]

On 06/10/13 17:05, Martin Landa wrote:

Hi all,

2013/10/3 Moritz Lennert:

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.


that's the point. This issue is open for many months(!). The answer
for your question is quite predictable. The problem is that we don't
have a full-time Windows developer. Personally I was forced (by the
students or my collegues) to try to fix some of Windows bugs in the
past. If you are forced, usually you invest only a limited time to
solve the issue. Result is sometimes something like workarounds.
Better than nothing I would say!


Users come and users go. I don't think that we have to create unsatisfactory


Huh, I hope you are kidding otherwise I do not understand. Yes, they
come and go, but we should try to convince them to use our software
and not to dissuade them from using it.  Please tell me what I can tell
the students who are attending my classes (they use Windows mostly) or
to my collegue (hydrologist) who would like to use GRASS in
comparision to ArcGIS in his research grant. Yes, he is also a Windows
user. I cannot find a reasonable explanation of this situation what I
can tell them.


I agree with the frustration, I live it myself, but I don't think that 
we should make people believe that we have solutions when we don't. I 
would love to be able to tell my students to go ahead, use GRASS, it 
"just works" (tm), but there are limitations, and we do not seem to have 
the manpower currently to remove those rapidly. And even if this is 
frustrating, I prefer to say that, and hope that they'll find their way 
back to GRASS once we've had the opportunity to fix the issue.


And it's not as if GRASS is completely unusable on Windows...



First of all, thanks Vaclav that he found time to take a look at this
issue.


+1


His time is limited (as for all of us), the solution is not
perfect, but it's anyway step towards.


Well, that is the question. According to some, it is a step that takes 
us further away from a real solution. And some quick fixes actually will 
cost us more developer time in the long run.


This does not mean I don't support Vaclav in trying, on the contrary, 
but trying also implies the possibility of error.



After r57911 we are in the same
situation. Python scripts called from Python code do not work again!
It's very serious issue, yes, it's a blocker.


I agree. That's why we haven't been able to release a tech preview, yet. 
But let's take the time it needs to resolve the issue once and for all.




@Glynn: please revert your revert or find a time to implement better solution.


Has anyone actually tried the python launcher as I suggested ? If yes, 
what are your experiences ?




@Moritz: you were discussing tech-previews for many times. Are you
able to imagine releasing tech-previews with this serious bug. Not me.


I agree.


hacks just to get some users now, with the risk of losing them (and others)
later when it becomes apparent that the hack doesn't solve everything...


What means "solve everything",


s/doesn't solve everything/only provides a superficial solution which 
contains the risk that it will hit us in the face later, when we've 
already built other parts of the software on top of that solution, only 
making it harder to then roll everything back/



could you elaborate a little bit? So
it's better to have broken functionality on Windows for many months?
It will probably not change within next weeks/months. Good to know,
it's a nice policy ;-)


As bad as it might sound, but yes, I prefer to have openly broken 
functionality (listing it in known bugs) for the time it takes to find a 
real solution, than to try to put band-aids over it and then move on, 
hoping that the band-aid will stick.





I think we just have to accept that MS Windows work power is _very_ limited
amongst us and that solutions for Windows will take time to be put in place.


Right, that's what I am speaking about.


A solution might be to try to focus resources in the form of a specific 
Windows code sprint, ideally with some Windows power hackers who could 
help us.


BTW, it seems that the same is needed to solve the encoding issues on 
Windows.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #957: v.voronoi has extra lines in output

[GRASS GIS]

#957: v.voronoi has extra lines in output
---+
 Reporter:  helena |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.4
Component:  Vector | Version:  svn-releasebranch64  
 Keywords:  v.voronoi  |Platform:  All  
  Cpu:  All|  
---+

Comment(by mmetz):

 Replying to [comment:37 mlennert]:
 [removing unused functions:]
 >
 > I'll attach a diff with all the changes erasing these functions entails.
 Everything seems to work here, but before submitting this, I would like
 someone else to have a look and test.

 I have completely removed all unused functions in r57953 (they were used
 in the original non-GRASS version producing text output).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev