Re: [GRASS-dev] [GRASS GIS] #2063: Memory leak in Rast_read_color_rules() ?

[GRASS GIS]

#2063: Memory leak in Rast_read_color_rules() ?
-+--
 Reporter:  sprice   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Raster   | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by neteler):

  * version:  unspecified => svn-trunk
  * component:  Default => Raster


Comment:

 Diff'ing the updated file with the respective one in G6 it looks like a
 backport candidate.
 Backport it?

-- 
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] #1736: wxNVIZ volume display crashes Mac

[GRASS GIS]

#1736: wxNVIZ volume display crashes Mac
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.4
Component:  wxGUI  | Version:  svn-releasebranch64  
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
---+

Comment(by cmbarton):

 This is progress because 1) the error can be replicated on more than the
 Mac and 2) it is narrowing in on the place that is actually causing the
 crash. Thanks for keeping up the effort here. This kind of display could
 be very important to a new research project that was just funded by NSF.

 Michael

-- 
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] #1736: wxNVIZ volume display crashes Mac

[GRASS GIS]

#1736: wxNVIZ volume display crashes Mac
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.4
Component:  wxGUI  | Version:  svn-releasebranch64  
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
---+
Changes (by annakrat):

  * milestone:  6.4.3 => 6.4.4


Comment:

 Update: crash happens when drawing isosurfaces both on Mac and Linux
 (tested on G7). It does not happen always, I think it depends on data.
 Testing data from Helena are
 [http://skagit.meas.ncsu.edu/~helena/grasswork/JR_7408MR_2m_t70.asci.zip
 here]. Try e.g. isosurface of value 10. This is the relevant part of Mac
 report:


 {{{
 0   libgrass_ogsf.7.0.svn.dylib 0x077aaf09 gvl_read_char + 41
 (gvl_calc.c:770)
 1   libgrass_ogsf.7.0.svn.dylib 0x077b0d59 gvld_isosurf + 3577
 (gvld.c:329)
 2   libgrass_ogsf.7.0.svn.dylib 0x077afea6 gvld_vol + 134
 (gvld.c:54)
 3   libgrass_ogsf.7.0.svn.dylib 0x0777a4ed GVL_draw_vol + 45
 (GVL2.c:410)
 4   libgrass_nviz.7.0.svn.dylib 0x0787c2af Nviz_draw_all_vol + 63
 (draw.c:186)
 5   libgrass_nviz.7.0.svn.dylib 0x0787c399 Nviz_draw_all + 153
 (draw.c:241)
 }}}


 The problem is (as debugger in Qt shows) that variable 'crnt_ev' in gvld.c
 on line 320 is 12:

 {{{
 pos[i] = edge_pos[crnt_ev];
 }}}

 but 'edge_pos' is a field with size 12 (see line 111) so it reads wrong
 data. The value of the variable 'crnt_ev' comes from a big look-up table
 (mc33_table.h, line 340). So either the size of the field 'edge_pos' is
 wrong or the table is wrong. On line 323 in gvld.c 'crnt_ev' is tested on
 value 12 so it seems that 12 is valid?

 The marching cubes algorithm is unfortunately too complicated and there
 are almost no comments in the code so I have no idea what all the numbers
 mean. I tried to set the size of the field 'edge_pos' to 13 and
 isosurfaces don't crash anymore (tested on Linux only) and look normally.
 But I have no idea if they are drawn correctly. Any ideas?

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

[GRASS GIS]

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

  * milestone:  7.0.0 => 6.4.4


Comment:

 Replying to [comment:5 zarch]:
 > 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)
 }}}

 seems like an easy string to set in the Preferences menu? (General tab?)
 Rather than lots of input boxes maybe just a single one with a tooltip
 saying something like:
 {{{
  USAGE: http://[username[:password]@]hostname.example.org:portnumber
  EXAMPLE: http://jdoe:sec...@proxy.example.com:8181
 }}}
 ?

 stuck behind a firewall,
 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] #1068: unnecessary error information at GRASS startup

[GRASS GIS]

#1068: unnecessary error information at GRASS startup
---+
  Reporter:  msieczka  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  minor |   Milestone:  6.4.0
 Component:  Startup   | Version:  svn-releasebranch64  
Resolution:  wontfix   |Keywords:   
  Platform:  All   | Cpu:  All  
---+

Comment(by wenzeslaus):

 I'm not sure how much this is related however, for GRASS 7 GUI I've
 committed (r57549). It changes dialogs with messages

 {{{
 "No GRASS location found in '%s'."
 "Path '%s' doesn't exist."
 }}}

 to a message in the main window. It is behaves better when starting GRASS
 for the first time and with deleted location.

 I'm not sure how to correctly implemented but I like how it behaves to the
 user.

-- 
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] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by cmbarton):

 Or something...

  The problem you describe is indeed annoying. But it does not seem like a
 good idea to have modules behave inconsistently and unpredictably from the
 user perspective in order to solve it. The --ui flag should be default
 behavior and not need the flag. Consistent behavior was one of the goals
 of getting rid of persistent processes in modules.

 The actual problem, and to my mind implementing a solution, seems to lie
 in the modules that should run without a dialog rather than altering the
 default behavior of launching a dialog when a module is run without
 parameters. A logically better fix is to require the --ui flag only on
 modules whose normal behavior is to run without arguments. g.region is not
 such a module; d.erase is such a module. Perhaps there are even more
 elegant fixes.

 Michael

-- 
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] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by annakrat):

 So we need options to have another field (something like 'group_required')
 which tells the parser that the certain options belong to a group of
 options where one of them has to be specified by the user. Would it be
 complicated to implement?

-- 
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] #2065: grass70 not detecting latest source build of libLAS (1.7.0)

[GRASS GIS]

#2065: grass70 not detecting latest source build of libLAS (1.7.0)
---+
 Reporter:  rashadkm   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Compiling  | Version:  svn-trunk
 Keywords:  liblas |Platform:  Linux
  Cpu:  All|  
---+

Comment(by glynn):

 Replying to [ticket:2065 rashadkm]:
 > when compiling grass70 from source using the config below with libLAS
 enabled. I am getting an error

 Try r57541.

-- 
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] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:12 cmbarton]:
 > Remind me again why the parser was changed so that a module does not
 open a GUI window when it is called from the command line and there are no
 required parameters.

 Because it's a nuisance having e.g. "d.erase" pop up a parameter dialog
 (or getting an error message about $DISPLAY not being set). It's also a
 nuisance having to type "d.erase bgcolor=none" when that's the default.

 The --ui flag exists if you specifically want a parameter dialog to be
 displayed.

-- 
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] #2063: Memory leak in Rast_read_color_rules() ?

[GRASS GIS]

#2063: Memory leak in Rast_read_color_rules() ?
-+--
 Reporter:  sprice   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [ticket:2063 sprice]:
 > I was looking for memory leaks in my program and I think I found one in
 Rast_read_color_rules() (if I'm reading it correctly).

 Fixed in r57540.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2065: grass70 not detecting latest source build of libLAS (1.7.0)

[GRASS GIS]

#2065: grass70 not detecting latest source build of libLAS (1.7.0)
---+
 Reporter:  rashadkm   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Compiling  | Version:  svn-trunk
 Keywords:  liblas |Platform:  Linux
  Cpu:  All|  
---+
 when compiling grass70 from source using the config below with libLAS
 enabled. I am getting an error

 ''./configure --with-freetype-includes=/usr/include/freetype2 --with-
 postgres-includes=/usr/pgsql-9.2/include/ --with-postgres --with-readline
 --with-nls --with-blas --with-lapack --with-wxwidgets --with-sqlite
 --with-geos --with-mysql-includes=/usr/include/mysql --with-mysql --with-
 netcdf --with-liblas=/home/rashad/local/bin/liblas-config --with-
 freetype''


 '''Config output:'''


 {{{
 checking host system type... x86_64-unknown-linux-gnu
 checking for gcc... gcc
 checking whether the C compiler (gcc -Wall -g ) works... yes
 checking whether the C compiler (gcc -Wall -g ) is a cross-compiler... no
 checking whether we are using GNU C... yes
 checking whether gcc accepts -g... yes
 checking for Cygwin environment... no
 checking for mingw32 environment... no
 checking for executable suffix... no
 checking for full floating-point support... yes
 checking for pwd... /usr/bin/pwd
 checking for source directory... /home/rashad/repos/grass/grass70
 checking for build directory... /home/rashad/repos/grass/grass70
 checking for svnversion... /usr/bin/svnversion
 checking for MacOSX App... no
 checking for MacOSX architectures... no
 checking for MacOSX SDK... no
 checking how to build libraries... shared
 checking for additional include dirs...
 checking for additional library dirs...
 checking for a BSD compatible install... /usr/bin/install -c
 checking for flex... flex
 checking for yywrap in -lfl... no
 checking for bison... bison -y
 checking for ranlib... ranlib
 checking for ar... ar
 checking for env... env
 checking for perl... /usr/bin/perl
 checking how to run the C preprocessor... gcc -E
 checking for ANSI C header files... yes
 checking for limits.h... yes
 checking for termio.h... yes
 checking for termios.h... yes
 checking for unistd.h... yes
 checking for values.h... yes
 checking for f2c.h... no
 checking for g2c.h... no
 checking for sys/ioctl.h... yes
 checking for sys/mtio.h... yes
 checking for sys/resource.h... yes
 checking for sys/time.h... yes
 checking for sys/timeb.h... yes
 checking for sys/types.h... yes
 checking for sys/utsname.h... yes
 checking for libintl.h... yes
 checking for iconv.h... yes
 checking for langinfo.h... yes
 checking whether time.h and sys/time.h may both be included... yes
 checking for off_t... yes
 checking for uid_t in sys/types.h... yes
 checking return type of signal handlers... void
 checking for Cygwin environment... no
 checking for ftime... yes
 checking for gethostname... yes
 checking for gettimeofday... yes
 checking for lseek... yes
 checking for nice... yes
 checking for time... yes
 checking for uname... yes
 checking for seteuid... yes
 checking for setpriority... yes
 checking for setreuid... yes
 checking for setruid... no
 checking for drand48... yes
 checking for putenv... yes
 checking for setenv... yes
 checking for nanosleep... yes
 checking whether setpgrp takes no argument... yes
 checking for long long int... yes
 checking for W11... no
 checking for X... libraries , headers
 checking for dnet_ntoa in -ldnet... no
 checking for dnet_ntoa in -ldnet_stub... no
 checking for gethostbyname... yes
 checking for connect... yes
 checking for remove... yes
 checking for shmat... yes
 checking for IceConnectionNumber in -lICE... yes
 checking for library containing cuserid... none required
 checking for asprintf... yes
 checking for atan... no
 checking for atan in -lm... yes
 checking for dlsym... no
 checking for dlsym in -ldl... yes
 checking for iconv... yes
 checking for socket... yes
 checking for location of zlib includes...
 checking for zlib.h... yes
 checking for location of zlib library...
 checking for deflate in -lz... yes
 checking for location of External PROJ.4 includes...
 checking for proj_api.h... yes
 checking External PROJ.4 version... 480
 checking for location of External PROJ.4 library...
 checking for pj_get_def in -lproj... yes
 checking for location of External PROJ.4 data files...
 configure: warning: *** External PROJ.4 directory not specified; default
 will be used
 checking for /usr/local/share/proj/epsg... no
 configure: warning: *** Unable to locate PROJ data files.
 checking for nad2bin... /usr/bin/nad2bin
 checking whether to use regex... yes
 checking for location of regex includes...
 checking for regex.h... yes
 checking for locatio