[GRASS-dev] Re: [GRASS GIS] #995: WxGUI startup screen fails if GISDBASE path contains non-latin characters
#995: WxGUI startup screen fails if GISDBASE path contains non-latin characters
--+-
Reporter: marisn | Owner: martinl
Type: defect | Status: assigned
Priority: blocker | Milestone: 6.4.0
Component: wxGUI| Version: svn-releasebranch64
Resolution: |Keywords: wingrass, i18n
Platform: MSWindows Vista | Cpu: Unspecified
--+-
Comment (by marisn):
Location Wizard still fails on Vista WinGRASS-6.4.SVN-r41749-1
{{{
Traceback (most recent call last):
File C:/Program Files/GRASS-64-SVN/etc/wxpython/gis_set.py, line 418,
in OnW
izard
grassdatabase = self.tgisdbase.GetValue())
File c:\osgeo4w\usr\src\grass64_release\dist.i686-pc-
mingw32\etc\wxpython\gui
_modules\location_wizard.py, line 1853, in __init__
File c:\osgeo4w\usr\src\grass64_release\dist.i686-pc-
mingw32\etc\wxpython\gui
_modules\location_wizard.py, line 2011, in OnWizFinished
File C:\Program Files\GRASS-64-SVN\etc\wxpython\gui_modules\gcmd.py,
line 60
9, in RunCommand
ps = grass.start_command(prog, flags, overwrite, quiet, verbose,
**kwargs)
File c:/osgeo4w/usr/src/grass64_release/dist.i686-pc-
mingw32\etc\python\grass
\script\core.py, line 145, in start_command
File c:/osgeo4w/usr/src/grass64_release/dist.i686-pc-
mingw32\etc\python\grass
\script\core.py, line 52, in __init__
File C:\Program Files\GRASS-64-SVN\Python25\lib\subprocess.py, line
594, in
__init__
errread, errwrite)
File C:\Program Files\GRASS-64-SVN\Python25\lib\subprocess.py, line
816, in
_execute_child
startupinfo)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0161' in
position 7
9: ordinal not in range(128)
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/995#comment:8
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1020: Display of vector maps fails
#1020: Display of vector maps fails --+- Reporter: MilenaN | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: blocker | Milestone: 6.4.0 Component: wxGUI| Version: 6.4.0 RCs Resolution: |Keywords: wingrass Platform: MSWindows 7 | Cpu: x86-64 --+- Comment (by marisn): Works fine on Vista WinGRASS-6.4.SVN-r41749-1. Could be something like Vista UAC related issues? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1020#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #928: 6.4: wx module GUIs never return
#928: 6.4: wx module GUIs never return ---+ Reporter: hamish| Owner: martinl Type: defect| Status: assigned Priority: critical | Milestone: 6.4.0 Component: default | Version: svn-releasebranch64 Resolution:|Keywords: addons Platform: Linux | Cpu: x86-64 ---+ Comment (by marisn): g.gui in WinGRASS-6.4.SVN-r41749-1 is also a blocker. Running g.gui gui=wxpython locks CMD till exit from GUI. Same with gui=tcltk. Still it's possible to launch old tcltk GUI with gis.m without blocking CMD. 1:0 in favor of gis.m. Also g.gui -u wxpython has no effect on modules launched from CMD - I still get tcltk GUI afterwards. g.gisenv displays GRASS_GUI=wxpython -- Ticket URL: http://trac.osgeo.org/grass/ticket/928#comment:16 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #928: 6.4: wx module GUIs never return
#928: 6.4: wx module GUIs never return ---+ Reporter: hamish| Owner: martinl Type: defect| Status: assigned Priority: critical | Milestone: 6.4.0 Component: default | Version: svn-releasebranch64 Resolution:|Keywords: addons Platform: Linux | Cpu: x86-64 ---+ Comment (by hamish): Replying to [comment:16 marisn]: Also g.gui -u wxpython has no effect on modules launched from CMD - I still get tcltk GUI afterwards. g.gisenv displays GRASS_GUI=wxpython that is due to the way that the icons/menu items are set up on WinGrass. If you look at the Properties they actually call `grass64 -tcltk` and `grass64 -wxpython`. Which has the effect of making the selection permanent. Solution: if you want the tcltk gui click on the tcltk menu item, if you want the wx gui click on the wx gui menu item. copy either one to your desktop as desired. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/928#comment:17 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to stat() stream file on Windows
#1006: r.terraflow fails to stat() stream file on Windows
--+-
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Raster | Version: svn-releasebranch64
Resolution: |Keywords: wxgui, wingrass, terraflow
Platform: MSWindows Vista | Cpu: x86-32
--+-
Comment (by marisn):
WinGRASS-6.4.SVN-r41749-1 running Vista with DEBUG=3:
{{{
GRASS 6.4.0svn (spearfish60) r.terraflow --verbose
elevation=elevation@perm
ANENT filled=elevflood direction=elevdir swatershed=elevsinkwater
accumulation=e
levflowacc tci=elevtci memory=900
D2/3: G__read_Cell_head
D2/3: G__read_Cell_head_array
D3/3: region item: proj: 1
D3/3: region item: zone: 13
D3/3: region item: north: 4928010
D3/3: region item: south: 4913700
D3/3: region item: east: 609000
D3/3: region item: west: 589980
D3/3: region item: cols: 634
D3/3: region item: rows: 477
D3/3: region item: e-w resol: 30
D3/3: region item: n-s resol: 30
D3/3: region item: top:1
D3/3: region item: bottom: 0
D3/3: region item: cols3: 634
D3/3: region item: rows3: 477
D3/3: region item: depths: 1
D3/3: region item: e-w resol3: 30
D3/3: region item: n-s resol3: 30
D3/3: region item: t-b resol: 1
D2/3: G__read_Cell_head
D2/3: G__read_Cell_head_array
D3/3: region item: proj: 1
D3/3: region item: zone: 13
D3/3: region item: north: 4928000
D3/3: region item: south: 4914020
D3/3: region item: east: 609000
D3/3: region item: west: 590010
D3/3: region item: cols: 633
D3/3: region item: rows: 466
D3/3: region item: e-w resol: 30
D3/3: region item: n-s resol: 30
D3/3: region item: format: 1
D3/3: region item: compressed: 1
cell elevation.dem header compatible with region header
Elevation stored as FLOAT (4B)
BR╬DIN┬JUMS:raster elevation.dem is of type CELL_TYPE --you should use
r.terraflow.short
Region size is 477 x 634
STREAM temporary files in C:/Users/Maris/AppData/Local/Temp (THESE
INTERMEDIATE
STREAMS WILL NOT BE DELETED IN CASE OF ABNORMAL TERMINATION OF THE
PROGRAM. TO
SAVE SPACE PLEASE DELETE THESE FILES MANUALLY!)
stats.out: Permission denied
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1006#comment:21
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #843: v.digit broken on new WinGrass release
#843: v.digit broken on new WinGrass release ---+ Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: svn-releasebranch64 Resolution:|Keywords: wingrass,v.digit Platform: MSWindows XP | Cpu: x86-64 ---+ Comment (by marisn): Just tested v.digit launched from CMD and wxgui running WinGRASS-6.4.SVN- r41749-1 on Vista - everything works just fine (except strange window named dbf.exe after creating database). -- Ticket URL: http://trac.osgeo.org/grass/ticket/843#comment:29 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1020: Display of vector maps fails
#1020: Display of vector maps fails --+- Reporter: MilenaN | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: blocker | Milestone: 6.4.0 Component: wxGUI| Version: 6.4.0 RCs Resolution: |Keywords: wingrass Platform: MSWindows 7 | Cpu: x86-64 --+- Comment (by marisn): I also noticed, that enabling DEBUG will make WxGUI to hang (Not responding). MilenaN - can You run g.gisenv set='DEBUG=0' in GUI CMD prompt or CMD and then try to display vector map? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1020#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #843: v.digit broken on new WinGrass release
#843: v.digit broken on new WinGrass release
---+
Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.4.0
Component: Tcl | Version: svn-releasebranch64
Resolution:|Keywords: wingrass,v.digit
Platform: MSWindows XP | Cpu: x86-64
---+
Comment (by hamish):
Replying to [comment:29 marisn]:
Just tested v.digit launched from CMD and wxgui running
WinGRASS-6.4.SVN-r41749-1 on Vista - everything works just fine
(except strange window named dbf.exe after creating database).
... but do you see this as the last messages on exit, as I do on a XP
machine?
{{{
Region restored to original extent.
Building topology for vector map (null)...
Registering promitives...
Unable to read vector map
}}}
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/843#comment:30
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #962: wxGUI crash when moving an undocked map display toolbox
#962: wxGUI crash when moving an undocked map display toolbox
---+
Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-releasebranch64
Resolution:|Keywords:
Platform: Linux | Cpu: x86-64
---+
Comment (by marisn):
Docking an undocking works just fine when there are NO maps displayed.
Steps to reproduce:
* add raster or vector map;
* undock map display toolbar;
* dock back map display toolbar -- KaBOOM!
{{{
Problem signature:
Problem Event Name: APPCRASH
Application Name: python.exe
Application Version: 0.0.0.0
Application Timestamp:47bd6a89
Fault Module Name:wxmsw28u_core_vc.dll
Fault Module Version: 2.8.9.1
Fault Module Timestamp: 4983882d
Exception Code: c005
Exception Offset: 6ef0
OS Version: 6.0.6002.2.2.0.256.6
Locale ID:1062
Additional Information 1: 810f
Additional Information 2: 3f6c89115c5b2ca50b73ad2f37d5d605
Additional Information 3: 2fd0
Additional Information 4: de35a5710e4652ba50fa82643c57e6a1
}}}
{{{
GRASS 6.4.0svn (spearfish60) g.gui wxpython
WARNING: Vector digitizer is not available (No module named
grass6_wxvdigit).
Note that the vector digitizer is currently not working under MS Windows
(hopefu
lly this will be fixed soon). Please keep an eye out for updated versions
of GRA
SS.
BR╬DIN┬JUMS:Unable to execute command
}}}
WinGRASS-6.4.SVN-r41749-1 running Windows Vista.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/962#comment:2
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #928: 6.4: wx module GUIs never return
#928: 6.4: wx module GUIs never return ---+ Reporter: hamish| Owner: martinl Type: defect| Status: assigned Priority: critical | Milestone: 6.4.0 Component: default | Version: svn-releasebranch64 Resolution:|Keywords: addons Platform: Linux | Cpu: x86-64 ---+ Comment (by marisn): Replying to [comment:17 hamish]: that is due to the way that the icons/menu items are set up on WinGrass. If you look at the Properties they actually call `grass64 -tcltk` and `grass64 -wxpython`. Which has the effect of making the selection permanent. Solution: if you want the tcltk gui click on the tcltk menu item, if you want the wx gui click on the wx gui menu item. copy either one to your desktop as desired. Hamish Ah. That explains a bit, still I was using `grass64 -text`, as it gives me CMD. Lack of normal terminal is PITA. Also then probably g.gui should print a warning when launched with -u on windows, as I expect my later actions to take precedence over startup type. -- Ticket URL: https://trac.osgeo.org/grass/ticket/928#comment:18 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #843: v.digit broken on new WinGrass release
#843: v.digit broken on new WinGrass release
---+
Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.4.0
Component: Tcl | Version: svn-releasebranch64
Resolution:|Keywords: wingrass,v.digit
Platform: MSWindows XP | Cpu: x86-64
---+
Comment (by marisn):
Ah. Sorry - slipped under my radar. I clearly see error message, still
resulting vector seems to be fine, as displaying, query, v.info and
v.report are running fine without errors.
Here's output when creating new map bar with single point without
attribute information:
{{{
D2/3: Variable = 0040E0C0
D1/3: Vect_get_thresh(): thresh = 0.00
D2/3: topo body offset 142
D2/3: topo body offset 142
D1/3: Vector format: 0 (native)
D1/3: Vect_set_thresh(): thresh = 0.00
D1/3: Vect__read_head(): vector = b...@user1
D1/3: Vect_set_thresh(): thresh = 0.00
D1/3: Level request = 0
D1/3: Vect_open_topo(): name = bar mapset= user1
D1/3: get coor info: C:\Users\Maris\Documents\GIS
DataBase/spearfish60/user1/vector/bar/coor
D1/3: Info-size = 14, Info-mtime = 1270717167
D2/3: Topo header: file version 5.0 , supported from GRASS version 5.0
D2/3: byte order 0
D2/3: header size 142
D2/3: with_z 0
D2/3: coor size 14
D1/3: Topo head: coor size = 14, coor mtime = 1270717167
D1/3: dig_load_plus()
D3/3: dig_init_plus()
D1/3: dig_spidx_init()
D3/3: dig_cidx_init()
D2/3: Topo header: file version 5.0 , supported from GRASS version 5.0
D2/3: byte order 0
D2/3: header size 142
D2/3: with_z 0
D2/3: coor size 14
D3/3: dig_alloc_isle():
D2/3: Vect_cidx_open(): name = bar mapset= user1
D3/3: dig_cidx_init()
D3/3: dig_read_cidx()
D3/3: dig_cidx_init()
D3/3: Cidx header: file version 5.0 , supported from GRASS version 5.0
D2/3: Vect_cidx_save()
D2/3: Open cidx: C:\Users\Maris\Documents\GIS
DataBase/spearfish60/user1/vector/bar/cidx
D3/3: dig_write_cidx_head()
D3/3: cidx body offset 13
D3/3: dig_write_cidx_head()
D3/3: cidx body offset 13
D1/3: close history file
D1/3: V1_close_nat(): name = bar mapset= user1
D1/3: get coor info: C:\Users\Maris\Documents\GIS
DataBase/spearfish60/user1/vector/bar/coor
D2/3: ftell = 14
D1/3: Info-size = 14, Info-mtime = 1270717167
D1/3: dig__write_head()
D1/3: write coor size (14) to head
D2/3: coor body offset 14
D1/3: Vect_get_thresh(): thresh = 0.00
D1/3: Vect_write_dblinks(): map = bar, mapset = user1
D1/3: dbln file: C:\Users\Maris\Documents\GIS
DataBase/spearfish60/user1/vector/bar/dbln
D1/3: Dblinks written
D1/3: Vect_open_old(): name = bar mapset= user1 update = 1
D1/3: Vect_set_thresh(): thresh = 0.00
D3/3: dig_init_plus()
D1/3: dig_spidx_init()
D3/3: dig_cidx_init()
D1/3: open format file: 'user1/vector/bar/frmt'
D1/3: dig__write_head()
D1/3: write coor size (0) to head
D2/3: coor body offset 14
D3/3: dig_init_plus()
D1/3: dig_spidx_init()
D3/3: dig_cidx_init()
D3/3: Vect_build(): build = 4
Building topology for vector map bar...
D2/3: dig_cidx_free()
D3/3: dig_cidx_init()
D3/3: Vect_build_nat() build = 4
D1/3: Vect_Rewind(): name = bar
Registering primitives...
D3/3: Vect_read_next_line()
D3/3: V1_read_next_line_nat()
D3/3: Vect__Read_line_nat: offset = 14
0 primitives registered
0 vertices registered
Building areas...
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
D2/3: dig_cidx_sort()
Number of nodes: 0
Number of primitives: 0
Number of points: 0
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
D1/3: Vect_close(): name = bar, mapset = user1, format = 0, level = 2
D1/3: get coor info: C:\Users\Maris\Documents\GIS
DataBase/spearfish60/user1/vector/bar/coor
D2/3: ftell = 14
D1/3: Info-size = 14, Info-mtime = 1270717167
D1/3: Vect_save_topo()
D1/3: Open topo: C:\Users\Maris\Documents\GIS
DataBase/spearfish60/user1/vector/bar/topo
D2/3: G__read_Cell_head
D2/3: G__read_Cell_head_array
D3/3: region item: proj: 1
D3/3: region item: zone: 13
D3/3: region item: north: 4928010
D3/3: region item: south: 4913700
D3/3: region item: east: 609000
D3/3: region item: west: 589980
D3/3: region item: cols: 634
D3/3: region item: rows: 477
D3/3: region item: e-w resol: 30
D3/3: region item: n-s resol: 30
D3/3: region item: top:1
D3/3: region item: bottom: 0
D3/3: region item: cols3: 634
D3/3: region item: rows3: 477
D3/3: region item: depths: 1
D3/3: region item: e-w resol3: 30
D3/3: region item: n-s resol3: 30
D3/3: region item: t-b resol: 1
D1/3: Region: N =
[GRASS-dev] r.watershed broken in grass7 trunk?
Hi, it seems to me that r.watershed is broken in the latest grass7 trunk version? This may be related to r41705? Example from the r.watershed manual with spearfish data produces an error: grass_dev/grass_trunk g.list rast -- raster files available in mapset PERMANENT: aspect erosion1quads soils strm.dist bugsitesfields railroads soils.Kfactor texture density geology roads soils.Tfactor tractids elevation.10m landcover.30m rstrct.areassoils.phtransport.misc elevation.dem landcover.orig rushmoresoils.range trn.sites elevation.dted landuse slope spot.image uparea erode.index owner soil.br.depth streams vegcover grass_dev/grass_trunk g.region rast=elevation.dem grass_dev/grass_trunk r.watershed elev=elevation.dem accum=rwater.accum ERROR: USAGE for basin delineation: /1/gebbert/src/grass_dev/grass_trunk/dist.i686-pc-linux-gnu/etc/r.watershed.ram -4 elevation=elevation_map threshold=swale_threshold [flow=overland_flow_map] [drainage=drain_direction_map] [depression=depression_map] [accumulation=accumulation_map] [basin=watershed_basin_map] [stream=stream_segment_map] USAGE for slope length determination: /1/gebbert/src/grass_dev/grass_trunk/dist.i686-pc-linux-gnu/etc/r.watershed.ram [-4] elevation=elevation_map threshold=swale_threshold [drainage=drain_direction_map] [depression=depression_map] [accumulation=accumulation_map] [max_slope_length=max_slope_length] [blocking=overland_blocking_map] [slope_steepness=slope_steepness_map] length_slope=length_slope_map [disturbed_land=rill_erosion_map] [slope_deposition=slope_deposition value or map]USAGE for ARMSED FILE creation: /1/gebbert/src/grass_dev/grass_trunk/dist.i686-pc-linux-gnu/etc/r.watershed.ram [-4] elevation=elevation_map threshold=swale_threshold [flow=overland_flow_map] [drainage=drain_direction_map] [depression=depression_map] [accumulation=accumulation_map] [basin=watershed_basin_map] [stream=stream_segment_map] [half_basin=half_basin_map] ar=ARMSED_file_name WARNING: Subprocess failed with exit code 1 WARNING: category information for [rwater.accum] in [user1] missing or invalid Any suggestions how to fix that? Best regards Soeren ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #1030: r.li.* memory leak + patch
#1030: r.li.* memory leak + patch
-+--
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Keywords: |Platform: All
Cpu: All |
-+--
Hi,
I get some troubles when working on a (e.g.,) 1700 x 2500 map with
r.li.patchdensity, it swaps
like crazy on a 18GB RAM machine... eventually the processes crash.
Apparently there is memory leak (GRASS 6.4):
{{{
==30423== 826,105,500 bytes in 83,445 blocks are definitely lost in loss
record 49 of 49
==30423==at 0x4C21167: calloc (vg_replace_malloc.c:418)
==30423==by 0x4E3A0B7: G__calloc (alloc.c:74)
==30423==by 0x4E3A218: G_allocate_cell_buf (alloc_cell.c:66)
==30423==by 0x400E7C: patch_density (main.c:74)
==30423==by 0x54B775C: worker (worker.c:190)
==30423==by 0x54B458D: calculateIndex (daemon.c:91)
==30423==by 0x400DC5: main (main.c:53)
==30423==
==30423== LEAK SUMMARY:
==30423==definitely lost: 826,105,960 bytes in 83,495 blocks
==30423==indirectly lost: 0 bytes in 0 blocks
==30423== possibly lost: 39,600 bytes in 4 blocks
==30423==still reachable: 140,446 bytes in 69 blocks
==30423== suppressed: 0 bytes in 0 blocks
}}}
I observe that in these commands memory is allocated:
{{{
[nete...@north r.li]$ grep G_allocate_cell_buf */*
r.li.cwed/cwed.c:buf_sup = G_allocate_cell_buf();
r.li.cwed/cwed.c:buf_corr = G_allocate_cell_buf();
r.li.daemon/main.c.unused: sup = G_allocate_cell_buf();
r.li.daemon/worker.c: cm-cache[used + i] =
G_allocate_cell_buf();
r.li.daemon/worker.c:old = G_allocate_cell_buf();
r.li.edgedensity/edgedensity.c:buf_sup = G_allocate_cell_buf();
r.li.edgedensity/edgedensity.c: buf_inf = G_allocate_cell_buf();
r.li.mps/mps.c:buf_sup = G_allocate_cell_buf();
r.li.mps/mps.c:buf = G_allocate_cell_buf();
r.li.padcv/padcv.c:buf_sup = G_allocate_cell_buf();
r.li.padcv/padcv.c:buf = G_allocate_cell_buf();
r.li.padrange/padrange.c:buf_sup = G_allocate_cell_buf();
r.li.padrange/padrange.c:buf = G_allocate_cell_buf();
r.li.padsd/padsd.c:buf_sup = G_allocate_cell_buf();
r.li.padsd/padsd.c:buf = G_allocate_cell_buf();
r.li.patchdensity/main.c:sup = G_allocate_cell_buf();
r.li.patchnum/main.c:sup = G_allocate_cell_buf();
}}}
but never released:
{{{
[nete...@north r.li]$ grep G_free */* | grep 'buf\|sup' | grep -v mask
[nete...@north r.li]$
}}}
Attached patch seems to cure the problem.
Ok to submit?
Note: I am unsure about adding a G_free(old); in
raster/r.li/r.li.daemon/worker.c, line 262.
Markus
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1030
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.watershed broken in grass7 trunk?
Hi, 2010/4/8 Soeren Gebbert soerengebb...@googlemail.com: Hi, it seems to me that r.watershed is broken in the latest grass7 trunk version? This may be related to r41705? right, sorry, I will fix it ASAP. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #1031: More specific parameter information in command line help
#1031: More specific parameter information in command line help
--+-
Reporter: huhabla | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor | Milestone: 7.0.0
Component: libgis| Version: svn-trunk
Keywords: parser, help |Platform: All
Cpu: All |
--+-
I would like to suggest the implementation of a more informative command
line help for grass modules. Additionally to the current parameters the
status(age), type and if it is required or not should be displayed.
A patch for parser_help.c is attached.
Example r.buffer:
{{{
lib/gisr.buffer help
Description:
Creates a raster map layer showing buffer zones surrounding cells that
contain non-NULL category values.
Keywords:
raster, buffer
Usage:
r.buffer [-z] input=name output=name distances=value[,value,...]
[units=string] [--overwrite] [--verbose] [--quiet]
Flags:
-z Ignore zero (0) data cells instead of NULL cells
--o Allow output files to overwrite existing files
--v Verbose module output
--q Quiet module output
Parameters:
input Name of input raster map
output Name for output raster map
distances Distance zone(s)
units Units of distance
options: meters,kilometers,feet,miles,nautmiles
default: meters
}}}
Will change into
{{{
lib/gis r.buffer help
Description:
Creates a raster map layer showing buffer zones surrounding cells that
contain non-NULL category values.
Keywords:
raster, buffer
Usage:
r.buffer [-z] input=name output=name distances=value[,value,...]
[units=string] [--overwrite] [--verbose] [--quiet]
Flags:
-z Ignore zero (0) data cells instead of NULL cells
--o Allow output files to overwrite existing files
--v Verbose module output
--q Quiet module output
Parameters:
input Name of input raster map
status: input
type: cell
required: yes
output Name for output raster map
status: output
type: cell
required: yes
distances Distance zone(s)
type: float
required: yes
units Units of distance
options: meters,kilometers,feet,miles,nautmiles
default: meters
type: string
required: no
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1031
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS_EXTRA_PATHS and GRASS_EXTRA_LIBS for importing extra working environments?
Hello, Since I'm using GRASS(6.4.0RC6) concurrently with other software suites for image pre-processing, I'd like to propose an enhancement that will encourage some interesting applications of GRASS GIS combined with other tools that setup a working environment like grass. At the moment I'm using system's LD_LIBRARY_PATH for adding specific extra libs, and GRASS_ADDON_PATH to add extra scripts and executables I want to use within GRASS GIS. Especially for the case of some specific libraries, these are mostly useful within the data analysis session -- and are not useful as system-wide libraries, so I ended up with a custom Init.sh script that set them for me within the GRASS session. To enable a generic concurrent use of other software tools within the GRASS session, maybe we can enable Init.sh to read two new environmental variables: GRASS_EXTRA_PATH and GRASS_EXTRA_LIB, to be set by the user before the session, and then to be added to the PATH and GRASS_LD_LIBRARY_PATH by the Init.sh. Maybe there is a more smart or more safe way to do it, this is just an idea from which to start on. Regards, Alessandro -- Alessandro Frigeri, PhD University of Perugia, Italy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1026: Problems starting grass7 from tcsh
#1026: Problems starting grass7 from tcsh
--+-
Reporter: huhabla | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: default | Version: svn-trunk
Resolution: |Keywords: tcsh
Platform: Linux| Cpu: x86-32
--+-
Comment (by huhabla):
Setting the display variable unfortunately does not help:
{{{
grass_dev/grass_trunk r.buffer
No protocol specified
Unable to access the X Display, is $DISPLAY set properly?
grass_dev/grass_trunk echo $DISPLAY
:0
grass_dev/grass_trunk setenv DISPLAY unix:0
grass_dev/grass_trunk echo $DISPLAY
unix:0
grass_dev/grass_trunk r.buffer
No protocol specified
Unable to access the X Display, is $DISPLAY set properly?
grass_dev/grass_trunk setenv DISPLAY `hostname`:0
grass_dev/grass_trunk r.buffer
Unable to access the X Display, is $DISPLAY set properly?
grass_dev/grass_trunk
grass_dev/grass_trunk wx-config --version-full
2.8.10.1
grass_dev/grass_trunk cat /etc/SuSE-release
openSUSE 11.2 (i586)
VERSION = 11.2
grass_dev/grass_trunk
}}}
As default the variable DISPLAY set to :0 in my shell, which works with
any other programs outside of grass.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1026#comment:2
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Wed, Apr 7, 2010 at 7:58 AM, Glynn Clements gl...@gclements.plus.com wrote: Markus Neteler wrote: I think that we need to get out 6.4.0final. Can I suggest that lib/python is sync'd to the latest 6.x version. In 6.4.0-RC6, g.parser has been updated to the latest version (with the -s flag), but lib/python/core.py hasn't been updated to use it. It's still using the old (and unreliable) method of re-invoking the script. Is latest version 6.5 or 7? Since it isn't really my area, I am not sure what to sync (have sync'ed the file-internal documentation now). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.watershed broken in grass7 trunk?
Hi, 2010/4/8 Martin Landa landa.mar...@gmail.com: it seems to me that r.watershed is broken in the latest grass7 trunk version? This may be related to r41705? right, sorry, I will fix it ASAP. quick fix r41766. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [SoC] Improve multicriteria analysis tools (porting add-on to GRASS7)
Thank you very much Markus! Following your instructions, the modification was mostly straightforward. I also needed to add $(RASTERLIB) to LIBES and $(RASTERDEP) to DEPENDENCIES in the Makefile. Since I didn't test well the whole thing, I set up a mercurial repository. Interested people may follow development at http://bitbucket.org/jdenisgiguere/grass-mcda/ Regards, 2010/4/5 Markus Neteler nete...@osgeo.org: On Mon, Apr 5, 2010 at 9:25 PM, Jean-Denis Giguere jdenisgigu...@gmail.com wrote: ... It seems to have many changes in raster modules between GRASS6 and GRASS7. I would like to know if I can find documentation about porting GRASS6 add-on to GRASS7. It requires several updates to the new raster library architecture. Basically, the raster.h header must be added and functions renamed, for example G_put_raster_row() - Rast_put_row() etc. For an overview table, see http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions A good idea is also to compare modules between GRASS 6.5 and 7. Best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS_EXTRA_PATHS and GRASS_EXTRA_LIBS for importing extra working environments?
Alessandro Frigeri wrote: At the moment I'm using system's LD_LIBRARY_PATH for adding specific extra libs, and GRASS_ADDON_PATH to add extra scripts and executables I want to use within GRASS GIS. Especially for the case of some specific libraries, these are mostly useful within the data analysis session -- and are not useful as system-wide libraries, so I ended up with a custom Init.sh script that set them for me within the GRASS session. Note that you can use ~/.grass.bashrc for commands which are to be run at the beginning of a GRASS session. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
