Re: [GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver

2013-05-28 Thread GRASS GIS
#943: wxpython gui hangs after switching to cairo display driver
--+-
 Reporter:  epatton   |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  critical  |   Milestone:  6.4.3 
   
Component:  wxGUI | Version:  svn-develbranch6  
   
 Keywords:  cairo, driver, gui, wxpython  |Platform:  Linux 
   
  Cpu:  All   |  
--+-

Comment(by hamish):

 Hi,

 a few cleanups and fixes applied to devbr6 in r56443. The main problem
 there was GRASS_RENDER_IMMEDIATE always being set to TRUE, which in GRASS
 6 always triggers the PNG driver instead.

 Now the error message is by d.rast (e.g.) and has to do with the monitor
 not accepting connections. Interestingly enough, if I have the x0 XMONITOR
 started and selected (on linux) and the cairo driver selected as the wxGUI
 rendering mode, it renders to the Xmon much like the old tcl/tk GUIs
 would.

 But as for the Cairo driver, trying to start it still locks up the wxGUI,
 as per the original bug report, so is currently commented out.
 {{{
RunCommand('d.mon', start = 'cairo')
 }}}

 I had an hourglass mouse cursor on the Map Display window, and could not
 change tabs or do anything with the Layer Manager window, although if I
 dragged it around and moved other windows over the top of it it still
 looked ok after dragging them off. But I had to use `xkill` to get rid of
 it, as neither the Map Display or the Layer manager's "X" window
 decoration worked.


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #560: WinGRASS not deleting temp ppm files from map display

2013-05-28 Thread GRASS GIS
#560: WinGRASS not deleting temp ppm files from map display
+---
 Reporter:  isaacullah  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  6.4.3   
 
Component:  Display | Version:  6.4.0 RCs   
 
 Keywords:  v.digit ppm temp, wingrass  |Platform:  MSWindows XP
 
  Cpu:  x86-32  |  
+---

Comment(by hamish):

 some slight improvement in devbr6 with r56444, but still more to do.

 is there a reason for the temp .ppm files not to live in
 /tmp/grass6-$USER-$PID/ with gisrc for easier cleanup if something crashes
 or MS Windows happens? If the files are left open maybe it means that the
 gisrc temp dirs don't get deleted on MS Windows then..?


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver

2013-05-28 Thread GRASS GIS
#943: wxpython gui hangs after switching to cairo display driver
--+-
 Reporter:  epatton   |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  critical  |   Milestone:  6.4.3 
   
Component:  wxGUI | Version:  svn-develbranch6  
   
 Keywords:  cairo, driver, gui, wxpython  |Platform:  Linux 
   
  Cpu:  All   |  
--+-

Comment(by hamish):

 oh, and GRASS_RENDER_IMMEDIATE is now ''not'' set at the time that d.mon
 is called to start the cairo driver, but the GUI still locks up anyway.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1434: g.extension: option to specify proxy server

2013-05-28 Thread GRASS GIS
#1434: g.extension: option to specify proxy server
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…
  
 Type:  enhancement  |  Status:  new
  
 Priority:  major|   Milestone:  7.0.0  
  
Component:  Installation | Version:  svn-trunk  
  
 Keywords:  g.extension, urllib, wget, r.in.wms  |Platform:  All
  
  Cpu:  All  |  
-+--
Changes (by neteler):

  * priority:  normal => major


Comment:

 Increasing importance, enhancement asked in Italian GRASS GIS mailing
 list.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1434: g.extension: option to specify proxy server

2013-05-28 Thread GRASS GIS
#1434: g.extension: option to specify proxy server
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…
  
 Type:  enhancement  |  Status:  new
  
 Priority:  major|   Milestone:  7.0.0  
  
Component:  Installation | Version:  svn-trunk  
  
 Keywords:  g.extension, urllib, wget, r.in.wms  |Platform:  All
  
  Cpu:  All  |  
-+--

Comment(by zarch):

 Replying to [comment:2 neteler]:
 > Increasing importance, enhancement asked in Italian GRASS GIS mailing
 list.


 Ok, I've changed the code, now the proxy should be supported...
 see attachement: g.extension.diff

 (Un)fortunately I'm not behind a proxy, therefore I cannot test...

 If someone can test the changes, then I can commit...



 Note: I changed the global variables from lower to capitals (PEP8).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1961: wxNVIZ: error if no raster map selected

2013-05-28 Thread GRASS GIS
#1961: wxNVIZ: error if no raster map selected
+---
 Reporter:  hamish  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  6.4.3
Component:  wxGUI   | Version:  svn-develbranch6 
 Keywords:  wxnviz  |Platform:  All  
  Cpu:  x86-64  |  
+---

Comment(by hamish):

 Hi,

 it's better for points now, thanks, but still some small tweaks needed
 elsewhere. comments as I go:


 tested Spearfish's bugsites map in devbr6, looked ok. when tested in the
 old 6.4.3svn version only a thin line rendered until I moved the
 z-exaggeration slider off 0.0 to 1.0. (which seems like a nice default)


 fwiw there doesn't seem to be a need to abbreviate exaggeration to exag.
 since there is lots of space to the right of it for the text.


 restarting the GUI in devbr6 and adding Spearfish's roads did not go well,
 nothing rendered, lots of this repeating in the terminal:
  (.:25449): Gtk-CRITICAL **: gtk_range_set_range: assertion `min < max'
 failed

 and endless repeating tracebacks:
 {{{
 Traceback (most recent call last):
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/mapwindow.py", line
 366, in OnPaint

 self.DoPaint()
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/mapwindow.py", line
 385, in DoPaint

 self.lmgr.nviz.UpdatePage('cplane')
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/tools.py", line 4315,
 in UpdatePage

 self.FindWindowById(self.win['cplane']['position']['z']['sli
 der']).SetRange(zRange[0], zRange[1])
   File "/usr/lib64/python2.6/dist-
 packages/wx-2.8-gtk2-unicode/wx/_controls.py", line 2692, in
 SetRange

 return _controls_.Slider_SetRange(*args, **kwargs)
 OverflowError
 :
 in method 'Slider_SetRange', expected argument 2 of type
 'int'
 }}}

 on going back to 2D mode:
 {{{
 self.DoPaint()
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/mapwindow.py", line
 385, in DoPaint

 self.lmgr.nviz.UpdatePage('cplane')
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/tools.py", line 4315,
 in UpdatePage

 self.FindWindowById(self.win['cplane']['position']['z']['sli
 der']).SetRange(zRange[0], zRange[1])
   File "/usr/lib64/python2.6/dist-
 packages/wx-2.8-gtk2-unicode/wx/_controls.py", line 2692, in
 SetRange

 return _controls_.Slider_SetRange(*args, **kwargs)
 OverflowError
 :
 long int too large to convert to int
 Switching back to 2D view mode...
 Vector map  (lines) unloaded successfully
 Traceback (most recent call last):
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/mapwindow.py", line
 366, in OnPaint

 self.DoPaint()
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/mapwindow.py", line
 385, in DoPaint

 self.lmgr.nviz.UpdatePage('cplane')
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/tools.py", line 4315,
 in UpdatePage

 self.FindWindowById(self.win['cplane']['position']['z']['sli
 der']).SetRange(zRange[0], zRange[1])
   File "/usr/lib64/python2.6/dist-
 packages/wx-2.8-gtk2-unicode/wx/_controls.py", line 2692, in
 SetRange

 return _controls_.Slider_SetRange(*args, **kwargs)
 OverflowError
 :
 long int too large to convert to int
 Traceback (most recent call last):
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/mapwindow.py", line
 366, in OnPaint

 self.DoPaint()
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/mapwindow.py", line
 376, in DoPaint

 self.LoadDataLayers()
   File "/home/hamish/src/grass/svn/grass65/dist.x86_64
 -unknown-linux-gnu/etc/wxpython/nviz/mapwindow.py", line
 1311, in LoadDataLayers

 npoints, nlines, nfeatures, mapIs3D =
 self.lmgr.nviz.VectorInfo(layer)
   File "/usr/lib64/python2.6/dist-
 packages/wx-2.8-gtk2-unicode/wx/_core.py", line 14564, in
 __getattr__

 raise PyDeadObjectError(self.attrStr % self._name)
 wx._core
 .
 PyDeadObjectError
 :
 The C++ part of the NvizToolWindow object has been deleted,
 attribute access no longer allowed.
 }}}


 Spearfish geology (area) did not render at all. Perhaps it could check
 'v.info -t' via vector.vector_info_topo() and if a vector map containing
 area features is loaded pop up a warning and offer to render the
 boundaries-as-lines instead?


 Going to the wxNVIZ Data tab at that point and trying to add a raster
 didn't work, the drop down showed the current mapset and PERMANENT, but no
 maps within them and no '>' triangle or so to click to expand them. I
 supposed that's what 

Re: [GRASS-dev] [GRASS GIS] #1434: g.extension: option to specify proxy server

2013-05-28 Thread GRASS GIS
#1434: g.extension: option to specify proxy server
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…
  
 Type:  enhancement  |  Status:  new
  
 Priority:  major|   Milestone:  7.0.0  
  
Component:  Installation | Version:  svn-trunk  
  
 Keywords:  g.extension, urllib, wget, r.in.wms  |Platform:  All
  
  Cpu:  All  |  
-+--

Comment(by hamish):

 Hi,

 please also check if the http_proxy, ftp_proxy, etc. environment variables
 exist, that's quite widely supported convention and quite handy for those
 that need it set for everything.

 I'm not sure which should have precedence if it is set multiple ways, I
 guess the command line option before the envrio. variable.


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1434: g.extension: option to specify proxy server

2013-05-28 Thread GRASS GIS
#1434: g.extension: option to specify proxy server
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…
  
 Type:  enhancement  |  Status:  new
  
 Priority:  major|   Milestone:  7.0.0  
  
Component:  Installation | Version:  svn-trunk  
  
 Keywords:  g.extension, urllib, wget, r.in.wms  |Platform:  All
  
  Cpu:  All  |  
-+--

Comment(by zarch):

 Replying to [comment:4 hamish]:
 > Hi,
 >
 > please also check if the http_proxy, ftp_proxy, etc. environment
 variables exist, that's quite widely supported convention and quite handy
 for those that need it set for everything.


 If the environment variables exist and user does not specify new one with:
 http_proxy, ftp_proxy, etc. the environment variables are used. Looking at
 the python docs:

 {{{
 # Use proxies from environment - both versions are equivalent
 filehandle = urllib.urlopen(some_url, proxies=None)
 }}}


 > I'm not sure which should have precedence if it is set multiple ways, I
 guess the command line option before the envrio. variable.


 IMHO, if the user specify the http_proxy parameter on the module this
 should have the precedence.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Rast_open_new_null()

2013-05-28 Thread Newcomb, Doug
Yann,
You could just use r.reclass  on an existing layer and set everything to
NULL,
http://grass.osgeo.org/grass64/manuals/r.reclass.html

Doug



On Mon, May 27, 2013 at 11:38 PM, Yann Chemin  wrote:

> Hi,
>
> is there a small way to open a new file and set all values to NULL?
> The function would be something like Rast_open_new_null(),
>
> Yann
>
> --
> 
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r56452 - grass/trunk/scripts/g.extension

2013-05-28 Thread Martin Landa
Hi,

2013/5/28  :
> Author: zarch
> Date: 2013-05-28 05:07:34 -0700 (Tue, 28 May 2013)
> New Revision: 56452
>
> Modified:
>grass/trunk/scripts/g.extension/g.extension.py
> Log:
> Add proxy support.
> @@ -55,6 +55,27 @@
>  #% answer: $GRASS_ADDON_BASE
>  #% required: no
>  #%end
> +#%option
> +#% key: http_proxy
> +#% type: string
> +#% key_desc: http proxy
> +#% description: Set the http proxy
> +#% required: no
> +#%end
> +#%option
> +#% key: https_proxy
> +#% type: string
> +#% key_desc: https proxy
> +#% description: Set the https proxy
> +#% required: no
> +#%end
> +#%option
> +#% key: ftp_proxy
> +#% type: string
> +#% key_desc: ftp proxy
> +#% description: Set the ftp proxy
> +#% required: no
> +#%end

any idea how to minimize number of newly added parameters?

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


Re: [GRASS-dev] [GRASS-SVN] r56452 - grass/trunk/scripts/g.extension

2013-05-28 Thread Blumentrath, Stefan
What about using two option:

proxy_url

proxy_type (ftp/http/https)

this would be one option less...

Cheers
Stefan


-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Martin Landa
Sent: 28. mai 2013 14:29
To: Pietro Zambelli
Cc: GRASS developers list
Subject: Re: [GRASS-dev] [GRASS-SVN] r56452 - grass/trunk/scripts/g.extension

Hi,

2013/5/28  :
> Author: zarch
> Date: 2013-05-28 05:07:34 -0700 (Tue, 28 May 2013) New Revision: 56452
>
> Modified:
>grass/trunk/scripts/g.extension/g.extension.py
> Log:
> Add proxy support.
> @@ -55,6 +55,27 @@
>  #% answer: $GRASS_ADDON_BASE
>  #% required: no
>  #%end
> +#%option
> +#% key: http_proxy
> +#% type: string
> +#% key_desc: http proxy
> +#% description: Set the http proxy
> +#% required: no
> +#%end
> +#%option
> +#% key: https_proxy
> +#% type: string
> +#% key_desc: https proxy
> +#% description: Set the https proxy
> +#% required: no
> +#%end
> +#%option
> +#% key: ftp_proxy
> +#% type: string
> +#% key_desc: ftp proxy
> +#% description: Set the ftp proxy
> +#% required: no
> +#%end

any idea how to minimize number of newly added parameters?

Thanks, Martin
___
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] [GRASS-SVN] r56452 - grass/trunk/scripts/g.extension

2013-05-28 Thread Martin Landa
2013/5/28 Blumentrath, Stefan :
> What about using two option:
>
> proxy_url
>
> proxy_type (ftp/http/https)

or one paramater

proxy="http:"

proxy="http:,ftp:"

...

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


[GRASS-dev] [GRASS GIS] #1982: v.rast.stats: running generates "Unable to fetch interface description for command" error

2013-05-28 Thread GRASS GIS
#1982: v.rast.stats: running generates "Unable to fetch interface description 
for
command" error
--+-
 Reporter:  neteler   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  v.rast.stats  |Platform:  MSWindows 7  
  Cpu:  Unspecified   |  
--+-
 Recent winGRASS 7 standalone installer - running v.rast.stats
 generates this error:

 {{{
 Traceback (most recent call last):
   File "C:\Program Files\GRASS GIS
 7.0.svn\etc\gui\wxpython\lmgr\frame.py", line 737, in
 OnMenuCmd

 cmd = self.GetMenuCmd(event)
   File "C:\Program Files\GRASS GIS
 7.0.svn\etc\gui\wxpython\lmgr\frame.py", line 722, in
 GetMenuCmd

 input = GUI().GetCommandInputMapParamKey(cmdlist[0])
   File "C:\Program Files\GRASS GIS
 7.0.svn\etc\gui\wxpython\gui_core\forms.py", line 2296, in
 GetCommandInputMapParamKey

 tree =
 etree.fromstring(gtask.get_interface_description(cmd))
   File "C:\Program Files\GRASS GIS
 7.0.svn\etc\python\grass\script\task.py", line 464, in
 get_interface_description

 "\n\nDetails: %(det)s") % { 'cmd' : cmd, 'det' :
 decode(cmderr) }
 grass.script.core
 .
 ScriptError
 :
 Unable to fetch interface description for command
 'v.rast.stats'.
 Details: C:\Program Files\GRASS GIS
 7.0.svn\extrabin\python.exe: can't open file 'v.rast.stats':
 [Errno 2] No such file or directory
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] ERROR: no null file for

2013-05-28 Thread Markus Metz
On Tue, May 28, 2013 at 6:50 AM, Yann Chemin  wrote:
> Hi,
>
> I am opening a new raster file of nrows >100 and ncols > 100
> writing a single row with values then closing the file.

I think you can not close the file before you have written all rows.

Markus M

>
> It gives me this error.
>
> "ERROR: no null file for "
>
> Any possible way to get through it,
> close the file properly and not getting this error?
>
> I have been trying to create a raster first, filling it with 0.0 and then
> closing it. But this does not influence Rast_open_new() since it is not
> connecting to the same name raster file existing on disk as long as it does
> not actually write the new raster to disk. The failsafe "ERROR: no null file
> for " maybe called too early as it does not check for
> pre-existing file on disk with same name...
>
> any help please?
> Yann
>
>
> --
> 
>
> ___
> 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] Rast_open_new_null()

2013-05-28 Thread Markus Metz
On Tue, May 28, 2013 at 5:38 AM, Yann Chemin  wrote:
> Hi,
>
> is there a small way to open a new file and set all values to NULL?
> The function would be something like Rast_open_new_null(),

Using a module:
r.mapcalc "newmap = null()"

Using C code:

int row, nrows;
int data_type;
void *buf;

data_type = 

/* open raster map ... */

buf = Rast_allocate_buf(data_type);

Rast_set_null_value(buf, Rast_window_cols(), data_type);

nrows = Rast_window_rows();

for (row = 0; row < nrows; row++) {
Rast_put_row(buf, data_type);
}

/* close raster map ... */

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


Re: [GRASS-dev] [GRASS GIS] #1981: export error in osgeo4w/grass.tmpl

2013-05-28 Thread GRASS GIS
#1981: export error in osgeo4w/grass.tmpl
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.3
Component:  Packaging| Version:  svn-trunk
 Keywords:  scripting|Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [ticket:1981 hamish]:

 > ok to change?

 Yes. A "$" in an "export" command is almost always wrong.

 There '''might''' be a situation where "`export $LD_LIBRARY_PATH_VAR`" is
 required, but I think that LD_LIBRARY_PATH_VAR is normally substituted
 rather than ending up in the final script.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] rast_open_new() saturates after opening 127 temporary files

2013-05-28 Thread Glynn Clements

Yann Chemin wrote:

> Opening 127 temporary raster files is the limit of GRASS,
> 
> How can I get above that limit?

You need to provide more information: version, OS, any error or debug
messages generated.

I don't have this problem with 7.0 on Linux.

But first, check that it isn't an OS issue. "ulimit -n" reports the
maximum number of open files (in 7.0, you need two per map). Also,
each completed raster needs a subdirectory within the cell_misc
directory, and some filesystems impose a limit on the number of
subdirectories (often much lower than the limit on the number of
files).

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


Re: [GRASS-dev] [GRASS GIS] #560: WinGRASS not deleting temp ppm files from map display

2013-05-28 Thread GRASS GIS
#560: WinGRASS not deleting temp ppm files from map display
+---
 Reporter:  isaacullah  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  6.4.3   
 
Component:  Display | Version:  6.4.0 RCs   
 
 Keywords:  v.digit ppm temp, wingrass  |Platform:  MSWindows XP
 
  Cpu:  x86-32  |  
+---

Comment(by glynn):

 Replying to [comment:20 hamish]:

 > some slight improvement in devbr6 with r56444, but still more to do.
 >
 > is there a reason for the temp .ppm files not to live in
 /tmp/grass6-$USER-$PID/ with gisrc for easier cleanup if something crashes
 or MS Windows happens?

 The location of the temporary directory is chosen by the init script,
 which doesn't "publish" the location directly. If GRASS was started using
 the init script, the directory can be inferred from $GISRC, but there's no
 reliable way to know whether GRASS was actually started using the init
 script.

 Most uses of G_tempfile() are wrong (including its use by g.tempfile), but
 there isn't an official API for obtaining a normal temporary directory.
 AFAICT, the only code which should actually be using G_tempfile() is
 lib/raster/open.c and lib/raster3d/open.c.

 In light of that, G_tempfile() should probably be changed to use a similar
 mechanism to the init script (possibly by having the script set
 GRASS_TMPDIR), and a new function created for the code which requires the
 existing behaviour (i.e. requires that the temporary file is within the
 mapset directory so that rename() and link() work).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #560: WinGRASS not deleting temp ppm files from map display

2013-05-28 Thread GRASS GIS
#560: WinGRASS not deleting temp ppm files from map display
+---
 Reporter:  isaacullah  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  6.4.3   
 
Component:  Display | Version:  6.4.0 RCs   
 
 Keywords:  v.digit ppm temp, wingrass  |Platform:  MSWindows XP
 
  Cpu:  x86-32  |  
+---

Comment(by hamish):

 Ok, if $GISRC is custom you'd get tmp files in weird places. (render.py
 could test if the getenv string started with "/tmp/grassX-" before using
 that, otherwise use $TMPDIR?)

 Right or wrong, many modules leave left-over files in $MAPSET/.tmp/,
 either due to design or a crash, and wherever they are it's rather nice
 that they get cleaned up automatically by the clean_temp program (if users
 wish to bypass normal startup and not run clean_temp, then it's their
 responsibility to look after that manually). What I am looking for with
 the `dirname $GISRC` idea is some way to replicate that auto-cleanup for
 GUI .ppm files that are forgotten, undeletable-at-runtime on Windows, and
 the residual results of the GUI crashing before cleaning itself up.

 it's probably mainly of concern for large raster maps, where it's not a
 concern at all since in $MAPSET/.tmp/, but fwiw it's good to consider that
 /tmp/ is often on a much smaller filesystem than $GISDBASE. For example,
 v.in.ascii might make a multi GB tempfile during its scanning step.

 > Most uses of G_tempfile() are wrong

 what's the potential downside of that? why "wrong" instead of "different"?
 i.e. is it theoretically wrong or practically wrong?


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepts 22 students for Google Summer of Code 2013

2013-05-28 Thread Hamish
Martin wrote:
> @wiki: backup mentors are missing: this information is not
> currently available in mellange.
...
> [1] http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Accepted_Ideas

Done. While on the topics of wikis, I'd mention it is a goal this
year to have the students' blogs regularly appear on the
planet.osgeo.org aggregator site.


Anna, Pietro: if you like, you might wish to sign yourselves up
as extra backup mentors for the interactive scatter plot project,
since Michael is already backup mentor for all projects and I
wouldn't like to stretch anyone too thin. :)


congrats to all, we were spoilt for choice this year, all
student submissions were good and worth considering.


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


Re: [GRASS-dev] [GRASS GIS] #1981: export error in osgeo4w/grass.tmpl

2013-05-28 Thread GRASS GIS
#1981: export error in osgeo4w/grass.tmpl
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.3
Component:  Packaging| Version:  svn-trunk
 Keywords:  scripting|Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by hamish):

 done in trunk and devbr6 with r56458,9.

 another one to consider changing, in env.bat:

 -set GRASS_PYTHON=python
 +set GRASS_PYTHON=%GISBASE%\extrabin\python.exe


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-SVN] r56452 - grass/trunk/scripts/g.extension

2013-05-28 Thread Pietro
Hi Martin,

Sorry I didn't thought that an higher number of parameter were a problem.

On Tue, May 28, 2013 at 1:57 PM, Martin Landa  wrote:
> proxy="http:,ftp:"

Personally I like your solution...
Therefore if there are not objections I could implement it tomorrow.

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


Re: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepts 22 students for Google Summer of Code 2013

2013-05-28 Thread Anna Petrášová
On Tue, May 28, 2013 at 11:14 PM, Hamish  wrote:

> Martin wrote:
> > @wiki: backup mentors are missing: this information is not
> > currently available in mellange.
> ...
> > [1] http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Accepted_Ideas
>
> Done. While on the topics of wikis, I'd mention it is a goal this
> year to have the students' blogs regularly appear on the
> planet.osgeo.org aggregator site.
>
>
> Anna, Pietro: if you like, you might wish to sign yourselves up
> as extra backup mentors for the interactive scatter plot project,
> since Michael is already backup mentor for all projects and I
> wouldn't like to stretch anyone too thin. :)
>

OK, done. But I think Stepan won't need much help :)

Anna


>
> congrats to all, we were spoilt for choice this year, all
> student submissions were good and worth considering.
>
>
> best,
> Hamish
> ___
> 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] [GRASS GIS] #1982: v.rast.stats: running generates "Unable to fetch interface description for command" error

2013-05-28 Thread GRASS GIS
#1982: v.rast.stats: running generates "Unable to fetch interface description 
for
command" error
--+-
 Reporter:  neteler   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  v.rast.stats  |Platform:  MSWindows 7  
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 You run it from menu? (It is always better to include the information
 where you run the command from.) Is the version recent enough? Are there
 any other python scripts not running?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1982: v.rast.stats: running generates "Unable to fetch interface description for command" error

2013-05-28 Thread GRASS GIS
#1982: v.rast.stats: running generates "Unable to fetch interface description 
for
command" error
--+-
 Reporter:  neteler   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  v.rast.stats  |Platform:  MSWindows 7  
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Replying to [comment:1 annakrat]:
 > You run it from menu?

 Yes (it was not my own machine but from a course participant)

 > Is the version recent enough?

 Two days old.

 > Are there any other python scripts not running?

 Other look fine. It is the v.rast.stats script which gave problems on
 various
 machines. From the error I don't know what to look for or check on the
 user's
 machine.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepts 22 students for Google Summer of Code 2013

2013-05-28 Thread Hamish
Anna wrote:
> OK, done. But I think Stepan won't need much help :)  

thanks, I don't think Martin will either, but the more the
merrier. :)

sometimes it seems that gsoc projects (in general, not specifically
grass's ones) happen mainly student <-> mentor, so I try to
encourage to flatten it out for more community engaement. that
doesn't really apply to Stepan, more to help welcome in/integrate
those new to the project.


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

Re: [GRASS-dev] [GRASS GIS] #1982: v.rast.stats: running generates "Unable to fetch interface description for command" error

2013-05-28 Thread GRASS GIS
#1982: v.rast.stats: running generates "Unable to fetch interface description 
for
command" error
--+-
 Reporter:  neteler   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  v.rast.stats  |Platform:  MSWindows 7  
  Cpu:  Unspecified   |  
--+-

Comment(by hamish):

 perhaps g.parser is looking for "v.rast.stats" but only "v.rast.stats.py"
 exists in the %PATH%, and it is missing the ".py" extension association?
 (that only works in the DOSbox window, not the MSys one AFAIK, and GRASS7
 doesn't have the .bat file wrappers in bin/)

 what does "set" say at the GRASS cmd.exe prompt? is ";.PY" known?

 do other python scripts like r3.in.xyz work there?


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] rast_open_new() saturates after opening 127 temporary files

2013-05-28 Thread Yann Chemin
Hi,

Linux: Ubuntu 13.04
ulimit: open files  (-n) 1024


from : http://www.itworld.com/operating-systems/317369/setting-limits-ulimit

-n The maximum number of open file descriptors (most systems
   do not allow this value to be set)

indeed:
ulimit -n unlimited
bash: ulimit: open files: cannot modify limit: Operation not permitted

Yann

On 29 May 2013 01:34, Glynn Clements  wrote:
>
> Yann Chemin wrote:
>
>> Opening 127 temporary raster files is the limit of GRASS,
>>
>> How can I get above that limit?
>
> You need to provide more information: version, OS, any error or debug
> messages generated.
>
> I don't have this problem with 7.0 on Linux.
>
> But first, check that it isn't an OS issue. "ulimit -n" reports the
> maximum number of open files (in 7.0, you need two per map). Also,
> each completed raster needs a subdirectory within the cell_misc
> directory, and some filesystems impose a limit on the number of
> subdirectories (often much lower than the limit on the number of
> files).
>
> --
> Glynn Clements 



-- 

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


Re: [GRASS-dev] rast_open_new() saturates after opening 127 temporary files

2013-05-28 Thread Yann Chemin
ah yes i am using G7 trunk

On 29 May 2013 08:04, Yann Chemin  wrote:
> Hi,
>
> Linux: Ubuntu 13.04
> ulimit: open files  (-n) 1024
>
>
> from : http://www.itworld.com/operating-systems/317369/setting-limits-ulimit
>
> -n The maximum number of open file descriptors (most systems
>do not allow this value to be set)
>
> indeed:
> ulimit -n unlimited
> bash: ulimit: open files: cannot modify limit: Operation not permitted
>
> Yann
>
> On 29 May 2013 01:34, Glynn Clements  wrote:
>>
>> Yann Chemin wrote:
>>
>>> Opening 127 temporary raster files is the limit of GRASS,
>>>
>>> How can I get above that limit?
>>
>> You need to provide more information: version, OS, any error or debug
>> messages generated.
>>
>> I don't have this problem with 7.0 on Linux.
>>
>> But first, check that it isn't an OS issue. "ulimit -n" reports the
>> maximum number of open files (in 7.0, you need two per map). Also,
>> each completed raster needs a subdirectory within the cell_misc
>> directory, and some filesystems impose a limit on the number of
>> subdirectories (often much lower than the limit on the number of
>> files).
>>
>> --
>> Glynn Clements 
>
>
>
> --
> 



-- 

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


Re: [GRASS-dev] [GRASS GIS] #560: WinGRASS not deleting temp ppm files from map display

2013-05-28 Thread GRASS GIS
#560: WinGRASS not deleting temp ppm files from map display
+---
 Reporter:  isaacullah  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  6.4.3   
 
Component:  Display | Version:  6.4.0 RCs   
 
 Keywords:  v.digit ppm temp, wingrass  |Platform:  MSWindows XP
 
  Cpu:  x86-32  |  
+---

Comment(by glynn):

 Replying to [comment:22 hamish]:

 > Ok, if $GISRC is custom you'd get tmp files in weird places. (render.py
 could test if the getenv string started with "/tmp/grassX-" before using
 that, otherwise use $TMPDIR?)

 The init script uses TMPDIR or TEMP or tempfile.gettempdir(), and only
 falls back to /tmp as the last resort.

 > > Most uses of G_tempfile() are wrong
 >
 > what's the potential downside of that? why "wrong" instead of
 "different"?
 > i.e. is it theoretically wrong or practically wrong?

 If /tmp (or $TMPDIR) is on a different filesystem to the mapset, it's
 likely to be faster, e.g. /tmp is likely to be on a local disc even if the
 mapset is on an NFS or CIFS share.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] rast_open_new() saturates after opening 127 temporary files

2013-05-28 Thread Glynn Clements

Yann Chemin wrote:

> Linux: Ubuntu 13.04
> ulimit: open files  (-n) 1024

In which case, that isn't the problem.

What type of filesystem are you using? ext2 has a limit of 32768
subdirectories, increased to 64000 in ext4. I know that btrfs has a
rather low limit on the number of hard links (which normally
determines the maximum number of subdirectories, as each
subdirectory's ".." entry is a hard link to its parent).

> indeed:
> ulimit -n unlimited
> bash: ulimit: open files: cannot modify limit: Operation not permitted

You can't increase a soft limit above the corresponding hard limit,
and you can't increase a hard limit unless you're root (and sudo won't
work because the limits are per-process, so ulimit has to be a shell
built-in). On a system which uses PAM, the limits are normally set on
login based upon the contents of /etc/security/limits.conf.

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