date:20160615

Re: [GRASS-dev] [GRASS GIS] #3013: support background and border for d.legend

2016-06-15 Thread GRASS GIS

#3013: support background and border for d.legend
-+-
  Reporter:  annakrat|  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.3.0
 Component:  Display |Version:  svn-trunk
Resolution:  |   Keywords:  d.legend, background, gsoc2016,
   CPU:  |  cartography
  Unspecified|   Platform:  All
-+-

Comment (by annakrat):

 > > Replying to [comment:7 lazaa]:
 > > > Added flag {{{-b}}} and option {{{brdcolor}}} and {{{bgcolor}}} to
 draw background. Also added option{{{font_size}}} as requested. Code was
 separeted from main.c to background.c and draw.c. For background purpose
 in case of {{{-d}}} flag (histogram) added function calc_histogram in
 histrogram2.c

 Tested, it works. However, the code is not maintainable like this, you
 have too large overlap between `draw` and `background` functions. I
 suggest to merge those functions and use ifs and put some parts into
 separate functions. Also check during compilation for warnings, there were
 a couple of them, probably not serious, but better to fix them.

--
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] #3062: Segmentation fault with r.buffer

2016-06-15 Thread GRASS GIS

#3062: Segmentation fault with r.buffer
---+-
  Reporter:  escheper  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  7.0.5
 Component:  Raster|Version:  7.0.4
Resolution:|   Keywords:  r.buffer
   CPU:  Other |   Platform:  Linux
---+-

Comment (by neteler):

 Replying to [comment:7 escheper]:
 > {{{
 > G_message(_("cur_zone: %i ZONE_INCR: %i ndist: %i to_ptr:
 %i"),cur_zone,ZONE_INCR,ndist,to_ptr);
 > if ((cur_zone = *--to_ptr))
 > cur_zone -= ZONE_INCR;
 > else
 > cur_zone = ndist;
 > }}}
 ...
 > cur_zone: 16538 ZONE_INCR: 2 ndist: 1 to_ptr: -2116621104

 Good analysis, this number looks like an integer overflow to me (it is
 negative). A C expert wanted here...

--
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] #3062: Segmentation fault with r.buffer

2016-06-15 Thread GRASS GIS

#3062: Segmentation fault with r.buffer
---+-
  Reporter:  escheper  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  7.0.5
 Component:  Raster|Version:  7.0.4
Resolution:|   Keywords:  r.buffer
   CPU:  Other |   Platform:  Linux
---+-

Comment (by escheper):

 Thanks for your support!

 Reading the map didn't cause the problem. The method read_input_map()
 finishes without a fault.
 The segmentation fault occurs in execute_distance() in execute.c after the
 message "Finding buffer zones..." is shown.

 After adding "G_free(map);" in read_input_map() the r.buffer command
 crashes within that method and execute_distances() isn't executed. So I
 removed the "G_free(map)" again.

 After adding some debug statements I have noticed the program crashes at
 the following point in process_left().


 {{{
 /* convert 1,2,3,4 to -1,0,1,2 etc. 0 becomes ndist */

 G_message(_("PL6"));
 G_message(_("cur_zone: %i ZONE_INCR: %i ndist: %i to_ptr:
 %i"),cur_zone,ZONE_INCR,ndist,to_ptr);
 if ((cur_zone = *--to_ptr))
 cur_zone -= ZONE_INCR;
 else
 cur_zone = ndist;
 }}}

 The last lines of the debug output was:

 PL6

 cur_zone: 16538 ZONE_INCR: 2 ndist: 1 to_ptr: -2116621104

 Segmentation fault

 I do not have much experience with C so maybe you can give me a clue.

--
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] #3059: r.external.out does not write CRS information

2016-06-15 Thread GRASS GIS

#3059: r.external.out does not write CRS information
--+
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  Raster   |Version:  7.0.4
Resolution:   |   Keywords:  r.external.out
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by neteler):

 Replying to [comment:3 glynn]:
 > Replying to [comment:2 neteler]:
 >
 > > Apparently some GDAL part is not initialized completely. I see in
 > >
 > >
 https://trac.osgeo.org/grass/browser/grass/trunk/lib/raster/gdal.c#L431
 > >
 > > that the use of GPJ_grass_to_wkt() is commented. Maybe that part needs
 to be updated/completed?
 >
 > The main problem is that gproj depends upon libgis, which means that
 libgis cannot depend upon gproj. However, it may be possible to load gproj
 dynamically, in the same manner as GDAL.

 Rather than merging libproj into libgis, your suggestion of dynamical
 loading of libproj sounds more viable to avoid a dependency "hell".

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoC weekly report 2006_0612_yb

2016-06-15 Thread Yang, Bo (yangb2)

Hi Markus, Maris,

Thanks! It is a very useful tools for me. 
That "random bug" has been fixed for the time being (an input threshold 
parameter was too large previously). But I will learn to use Valgrind and let 
you know if I have further questions. 

Best,
Bo yang

> -Original Message-
> From: neteler.os...@gmail.com [mailto:neteler.os...@gmail.com] On Behalf
> Of Markus Neteler
> Sent: Wednesday, June 15, 2016 5:11 AM
> To: Maris Nartiss 
> Cc: Yang, Bo (yangb2) ; GRASS developers list  d...@lists.osgeo.org>
> Subject: Re: [GRASS-dev] GSoC weekly report 2006_0612_yb
> 
> On Wed, Jun 15, 2016 at 9:30 AM, Maris Nartiss  wrote:
> > Hello,
> > you are mentioning some kind of "random bug". To hunt it down, please,
> > run failing command under valgrind, as in most of cases it indicates
> > on an erroneous code that should be tracked down sooner than later as
> > memory corruption quite often is hard to catch.
> >
> > Running under valgrind is easy - just install it and execute "valgrind
> > my_command with all parameters".
> 
> See also here:
> https://grasswiki.osgeo.org/wiki/GRASS_Debugging#Using_Valgrind
> 
> > If you have trouble understanding its
> > output, you can ask any of us to help you.
> >
> > WBR,
> > Māris.
> 
> best,
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

2016-06-15 Thread GRASS GIS

#3062: Segmentation fault with r.buffer
---+-
  Reporter:  escheper  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  7.0.5
 Component:  Raster|Version:  7.0.4
Resolution:|   Keywords:  r.buffer
   CPU:  Other |   Platform:  Linux
---+-

Comment (by neteler):

 {{{
 CMD='r.buffer input=r120749038 output=rasbuf distances=10.0
 units=kilometers --o'
 valgrind --tool=memcheck --leak-check=yes --show-reachable=yes  $CMD --o
 ==11148== Memcheck, a memory error detector

 ==11148==
 ==11148== 933,120,000 bytes in 1 blocks are still reachable in loss record
 73 of 73
 ==11148==at 0x4C2AB80: malloc (in /usr/lib/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 ==11148==by 0x5076A4A: G__malloc (alloc.c:39)
 ==11148==by 0x40333B: read_input_map (read_map.c:39)
 ==11148==by 0x402814: main (main.c:141)
 ...
 }}}

 There is no G_free(map) it seems:

 {{{
 raster/r.buffer $ grep 'alloc\|free' *.c | grep -v GNU
 parse_dist.c:distances = (struct Distance *)G_calloc(count,
 sizeof(struct Distance));
 read_map.c:map = (MAPTYPE *) G_malloc((size_t) window.rows *
 window.cols * sizeof(MAPTYPE));
 read_map.c:cell = Rast_allocate_c_buf();
 read_map.c:G_free(cell);
 support.c:Rast_free_cats();
 write_map.c:cell = Rast_allocate_c_buf();
 write_map.c:G_free(cell);
 }}}

--
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] #3062: Segmentation fault with r.buffer

2016-06-15 Thread GRASS GIS

#3062: Segmentation fault with r.buffer
---+-
  Reporter:  escheper  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  7.0.5
 Component:  Raster|Version:  7.0.4
Resolution:|   Keywords:  r.buffer
   CPU:  Other |   Platform:  Linux
---+-
Changes (by martinl):

 * keywords:  buffer => r.buffer


--
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] #3062: Segmentation fault with r.buffer

2016-06-15 Thread GRASS GIS

#3062: Segmentation fault with r.buffer
---+-
  Reporter:  escheper  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  7.0.5
 Component:  Raster|Version:  7.0.4
Resolution:|   Keywords:  buffer
   CPU:  Other |   Platform:  Linux
---+-

Comment (by escheper):

 The original file can be downloaded
 [http://www.gistools.nl/grass/settlements2.pack here].

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoC weekly report 2006_0612_yb

2016-06-15 Thread Maris Nartiss

Hello,
you are mentioning some kind of "random bug". To hunt it down, please,
run failing command under valgrind, as in most of cases it indicates
on an erroneous code that should be tracked down sooner than later as
memory corruption quite often is hard to catch.

Running under valgrind is easy - just install it and execute "valgrind
my_command with all parameters". If you have trouble understanding its
output, you can ask any of us to help you.

WBR,
Māris.


2016-06-13 6:54 GMT+03:00 Yang, Bo (yangb2) :
> Dear all,
>
>
>
> Please see the link below for GSoC_2016_Additional_segmentation_algorithms
> week 3 report.
>
>
>
> https://trac.osgeo.org/grass/wiki/GSoC/2016/Additional_segmentation_algorithms/weekly_report#a4June--11Juneweek3:implementmean-shiftimagesegmentationalgorithm
>
>
>
> Best,
>
> Bo Yang
>
>
> ___
> 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] #3013: support background and border for d.legend

Re: [GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

Re: [GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

Re: [GRASS-dev] [GRASS GIS] #3059: r.external.out does not write CRS information

Re: [GRASS-dev] GSoC weekly report 2006_0612_yb

Re: [GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

Re: [GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

Re: [GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

Re: [GRASS-dev] GSoC weekly report 2006_0612_yb

9 matches

Site Navigation

Mail list logo

Footer information