Re: [GRASS-dev] [GRASS GIS] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Replying to [comment:6 neteler]:
 >
 > We are (also upon request of the devs posting in this ticket who
 complained about the past release procedure) following a new release
 procedure:
 >
 > http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
 >
 > " Step 5 ... - RC2:
 >
 > RC2 is released as almost final.
 >
 > Step 6 - Bug squashing: & Release preparation:
 >
 > A final, concerted bug squashing effort by all developers of '''no
 more than one week'''.
 >
 > ..."

 Yes, but the first half of the sentence is just as important as the second
 in this procedure. And I don't see as much effort on that side as there
 needs to be for this kind of procedure to work... We're still learning :-)

 I do think that it would be serious regression to release G7 with non-
 functional network analysis on Windows...

 Unfortunately, I'm travelling this weekend+Monday and won't have much time
 in front of a computer. (Maybe another lesson for the release procedure:
 put important release dates at the end of a work week, not during the
 weekend, as I have the feeling most developers are more active during
 office hours...). I'll try to look at it this morning, but wifi connection
 is really slow, so just downloading different versions of the win
 installer means long waits. And I don't have a win dev chain installed and
 therefore cannot easily debug...

 Moritz

-- 
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] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:12 annakrat]:
 > Sorry, the command should be:
 >
 > {{{
 > v.net streets_wake points=schools_wake operation=connect thresh=1000
 output=network
 > }}}

 Replying to [comment:12 annakrat]:
 > Sorry, the command should be:
 >
 {{{
 > v.net streets_wake points=schools_wake operation=connect thresh=1000
 output=network
 }}}

 right, now it makes more sense. I can confirm crash in vlib

 {{{
 Podpis problému:
   Název události problému:  APPCRASH
   Název aplikace:   v.net.exe
   Verze aplikace:   7.0.0.0
   Časové razítko aplikace:  54dd6fcd
   Název chybného modulu:libgrass_vector.7.0.0svn.dll
   Verze chybného modulu:0.0.0.0
   Časové razítko chybného modulu:   54dd6ae1
   Kód výjimky:  c005
   Posun výjimky:0003d935
   Verze operačního systému: 6.0.6002.2.2.0.274.10
   ID národního prostředí:   1029
   Další informace 1:fd00
   Další informace 2:ea6f5fe8924aaa756324d57f87834160
   Další informace 3:fd00
   Další informace 4:ea6f5fe8924aaa756324d57f87834160

 Přečtěte si prohlášení o zásadách ochrany osobních údajů:
   http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0405
 }}}

 The last debug messages are:

 {{{
 D3/5: V2_read_line_nat(): line = 45191
 D3/5: Vect__Read_line_nat: offset = 7334408
 D3/5: type = 2, do_cats = 1 dead = 0
 D3/5: n_cats = 1
 D3/5: n_points = 12
 D3/5: off = 7334617
 D3/5:  line = 45191 distance = 119.381284
 D3/5: min distance found = 22.835685
 D3/5: Vect_read_line(): line = 48182
 D3/5: V2_read_line_nat(): line = 48182
 D3/5: Vect__Read_line_nat: offset = 7826327
 D3/5: type = 2, do_cats = 1 dead = 0
 D3/5: n_cats = 1
 D3/5: n_points = 3
 D3/5: off = 7826392
 D3/5: Vect_rewrite_line(): name = network, format = 0, level = 2,
 line/offset =
 48182
 D3/5: V2_read_line_nat(): line = 48182
 D3/5: Vect__Read_line_nat: offset = 7826327
 D3/5: type = 2, do_cats = 1 dead = 0
 D3/5: n_cats = 1
 D3/5: n_points = 3
 D3/5: off = 7826392
 }}}

-- 
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] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Replying to [comment:13 mlennert]:
 ...
 > I do think that it would be serious regression to release G7 with non-
 functional network analysis on Windows...

 I guess that "final" only one week after RC2 is too close. But that's OT
 for this ticket.

 Likely this bug had been spotted if there was a test case in place (and
 executed on Windows of course).

 Anyone willing to write a test case for this line?

 {{{
 v.net streets_wake points=schools_wake operation=connect thresh=1000
 output=network
 }}}

-- 
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] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--
Changes (by neteler):

  * priority:  critical => blocker


-- 
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] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Replying to [comment:8 neteler]:
 > Replying to [comment:7 annakrat]:
 > > I just don't like releasing grass with a serious bug when we haven't
 even tried to fix it.
 >
 > Well, it does not happen e.g. on Linux.
 >
 > > I am talking about postponing it max one week. Basically, my question
 is: can Markus Metz look at it soon enough?
 >
 > No idea.
 >
 > > If not, then we can probably release it now.
 >
 > Changes I see after RC1:
 >
 >  * r64200 diglib: add numerical stability to dig_test_for_intersection()
 >  * r64198 diglib: add numerical stability to
 dig_distance2_point_to_line()
 >  * r64196 diglib: add numerical stability to dig_x_intersect()
 >  * many changes in
 
http://trac.osgeo.org/grass/log/grass/branches/releasebranch_7_0/lib/vector/Vlib

 These also do not respect the proposed release procedure:

 "Any commits from that point [RC] on can only be well-tested, non-invasive
 bug fixes."

 Many of these changes do not even seem to be bug fixes, but optimization.
 Typically the stuff that should have been tested in trunk and if stable
 integrated into the next point release...
 And, yes, tests should help, but they also would have to be run on
 different platforms before commits.

 And my level of understanding does not allow me to understand what in
 there might cause a MSWin-specific issue. My highest contender, in light
 of Martin's debug info above is r64215.

 Do I understand correctly that r64163 was just in time to be included into
 RC1 ?

 Martin, could you rerun your windows builds to get versions before and
 after the above change, or is that too much work ?

 Or maybe Glynn could have a look at these changes to see if there's
 anything obvious to more informed eyes than mine ?

 Moritz

-- 
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] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:14 martinl]:

 it seems to crash at source:grass/trunk/vector/v.net/connect.c#L87

-- 
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] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Probably it is a memory issue on Windows 32bit? --> "possibly lost:
 15,516,703 bytes".

 Also an "Uninitialised value was created by a stack allocation" - see
 below:

 {{{
 CMD="v.net streets_wake points=schools_wake operation=connect thresh=1000
 output=network"
 valgrind --tool=memcheck --leak-check=yes --show-reachable=yes  $CMD --o

 ...
 ==27244== 795,176 bytes in 41,775 blocks are indirectly lost in loss
 record 626 of 636
 ==27244==at 0x4A06BCF: malloc (in /usr/lib64/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 ==27244==by 0x4E9708F: G__realloc (alloc.c:124)
 ==27244==by 0x57432A4: dig_node_alloc_line (struct_alloc.c:83)
 ==27244==by 0x574CA1B: dig_Rd_P_node (plus_struct.c:69)
 ==27244==by 0x5741F01: dig_load_plus (plus.c:226)
 ==27244==by 0x4C2CE79: Vect_open_topo (open.c:1152)
 ==27244==by 0x4C2D6DC: Vect__open_old (open.c:333)
 ==27244==by 0x4C2DFCE: Vect_open_old (open.c:566)
 ==27244==by 0x402C9F: main (main.c:65)
 ==27244==
 ==27244== 936,576 bytes in 19,512 blocks are possibly lost in loss record
 627 of 636
 ==27244==at 0x4A06BCF: malloc (in /usr/lib64/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 ==27244==by 0x4E96F38: G__malloc (alloc.c:39)
 ==27244==by 0x5743200: dig_alloc_node (struct_alloc.c:34)
 ==27244==by 0x5742B68: dig_add_node (plus_node.c:120)
 ==27244==by 0x574534C: add_line (plus_line.c:60)
 ==27244==by 0x574559A: dig_add_line (plus_line.c:147)
 ==27244==by 0x4C31DB0: Vect_build_nat (build_nat.c:99)
 ==27244==by 0x4C344D7: Vect_build_partial (build.c:882)
 ==27244==by 0x4C3459A: Vect_build (build.c:577)
 ==27244==by 0x402FC1: main (main.c:157)
 ==27244==
 ==27244== 1,085,808 bytes in 22,621 blocks are possibly lost in loss
 record 628 of 636
 ==27244==at 0x4A06BCF: malloc (in /usr/lib64/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 ==27244==by 0x4E96F38: G__malloc (alloc.c:39)
 ==27244==by 0x5743200: dig_alloc_node (struct_alloc.c:34)
 ==27244==by 0x5742B68: dig_add_node (plus_node.c:120)
 ==27244==by 0x574549A: add_line (plus_line.c:95)
 ==27244==by 0x574559A: dig_add_line (plus_line.c:147)
 ==27244==by 0x4C31DB0: Vect_build_nat (build_nat.c:99)
 ==27244==by 0x4C344D7: Vect_build_partial (build.c:882)
 ==27244==by 0x4C3459A: Vect_build (build.c:577)
 ==27244==by 0x402FC1: main (main.c:157)
 ==27244==
 ==27244== 1,193,808 bytes in 49,742 blocks are indirectly lost in loss
 record 629 of 636
 ==27244==at 0x4A06BCF: malloc (in /usr/lib64/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 ==27244==by 0x4E96F38: G__malloc (alloc.c:39)
 ==27244==by 0x5743339: dig_alloc_line (struct_alloc.c:128)
 ==27244==by 0x574CD0C: dig_Rd_P_line (plus_struct.c:165)
 ==27244==by 0x5741F9A: dig_load_plus (plus.c:236)
 ==27244==by 0x4C2CE79: Vect_open_topo (open.c:1152)
 ==27244==by 0x4C2D6DC: Vect__open_old (open.c:333)
 ==27244==by 0x4C2DFCE: Vect_open_old (open.c:566)
 ==27244==by 0x402C9F: main (main.c:65)
 ==27244==
 ==27244== 1,205,904 bytes in 50,246 blocks are possibly lost in loss
 record 630 of 636
 ==27244==at 0x4A06BCF: malloc (in /usr/lib64/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 ==27244==by 0x4E96F38: G__malloc (alloc.c:39)
 ==27244==by 0x5743339: dig_alloc_line (struct_alloc.c:128)
 ==27244==by 0x5745252: add_line (plus_line.c:27)
 ==27244==by 0x574559A: dig_add_line (plus_line.c:147)
 ==27244==by 0x4C31DB0: Vect_build_nat (build_nat.c:99)
 ==27244==by 0x4C344D7: Vect_build_partial (build.c:882)
 ==27244==by 0x4C3459A: Vect_build (build.c:577)
 ==27244==by 0x402FC1: main (main.c:157)
 ==27244==
 ==27244== 1,256,112 bytes in 8,723 blocks are possibly lost in loss record
 631 of 636
 ==27244==at 0x4A06BCF: malloc (in /usr/lib64/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 ==27244==by 0x5B5DA65: RTreeAllocNode (node.c:88)
 ==27244==by 0x5B5E87D: RTreeAddBranch (node.c:587)
 ==27244==by 0x5B5CF27: RTreeInsertRect2M (indexm.c:135)
 ==27244==by 0x5B5D488: RTreeInsertRectM (indexm.c:231)
 ==27244==by 0x5B6001A: RTreeInsertRect (index.c:324)
 ==27244==by 0x5747325: dig_spidx_add_line (spindex.c:339)
 ==27244==by 0x574527B: add_line (plus_line.c:33)
 ==27244==by 0x574559A: dig_add_line (plus_line.c:147)
 ==27244==by 0x4C31DB0: Vect_build_nat (build_nat.c:99)
 ==27244==by 0x4C344D7: Vect_build_p

Re: [GRASS-dev] [GRASS GIS] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by marisn):

 On ~AMD64 Linux I don't see any crash but Valgrind is complaining about
 use of uninitialized values. Seems that there is a problem when vector is
 not a 3D one. Don't know it could be the source of a crash in the Windows
 version.

 Still in the light of recent Martin comments it could be the case.

 Markus - leak-check doesn't matter unless we are optimizing code. Lost
 memory is just wasted memory - it doesn't harm (except consuming few bytes
 of RAM).

 {{{
 ==10082== Conditional jump or move depends on uninitialised value(s)
 ==10082==at 0x5FBA939: dig_line_box (box.c:51)
 ==10082==by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895)
 ==10082==by 0x4E752A4: V2_rewrite_line_nat (write_nat.c:228)
 ==10082==by 0x4E51082: Vect_rewrite_line (write.c:231)
 ==10082==by 0x405979: connect_arcs (connect.c:87)
 ==10082==by 0x403164: main (main.c:146)
 ==10082==  Uninitialised value was created by a stack allocation
 ==10082==at 0x405550: connect_arcs (connect.c:23)
 ==10082==
 ==10082== Conditional jump or move depends on uninitialised value(s)
 ==10082==at 0x4E63D63: Vect_box_extend (box.c:126)
 ==10082==by 0x4E74B47: V2__add_line_to_topo_nat (write_nat.c:908)
 ==10082==by 0x4E752A4: V2_rewrite_line_nat (write_nat.c:228)
 ==10082==by 0x4E51082: Vect_rewrite_line (write.c:231)
 ==10082==by 0x405979: connect_arcs (connect.c:87)
 ==10082==by 0x403164: main (main.c:146)
 ==10082==  Uninitialised value was created by a stack allocation
 ==10082==at 0x405550: connect_arcs (connect.c:23)
 ==10082==
 ==10082== Conditional jump or move depends on uninitialised value(s)
 ==10082==at 0x5FBA939: dig_line_box (box.c:51)
 ==10082==by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895)
 ==10082==by 0x4E75161: V2_write_line_nat (write_nat.c:80)
 ==10082==by 0x4E50FA3: Vect_write_line (write.c:189)
 ==10082==by 0x405856: connect_arcs (connect.c:99)
 ==10082==by 0x403164: main (main.c:146)
 ==10082==  Uninitialised value was created by a stack allocation
 ==10082==at 0x405550: connect_arcs (connect.c:23)
 ==10082==
 ==10082== Conditional jump or move depends on uninitialised value(s)
 ==10082==at 0x5FBA944: dig_line_box (box.c:53)
 ==10082==by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895)
 ==10082==by 0x4E75161: V2_write_line_nat (write_nat.c:80)
 ==10082==by 0x4E50FA3: Vect_write_line (write.c:189)
 ==10082==by 0x405856: connect_arcs (connect.c:99)
 ==10082==by 0x403164: main (main.c:146)
 ==10082==  Uninitialised value was created by a stack allocation
 ==10082==at 0x405550: connect_arcs (connect.c:23)
 ==10082==
 ==10082== Conditional jump or move depends on uninitialised value(s)
 ==10082==at 0x4E63D63: Vect_box_extend (box.c:126)
 ==10082==by 0x4E74B47: V2__add_line_to_topo_nat (write_nat.c:908)
 ==10082==by 0x4E75161: V2_write_line_nat (write_nat.c:80)
 ==10082==by 0x4E50FA3: Vect_write_line (write.c:189)
 ==10082==by 0x405856: connect_arcs (connect.c:99)
 ==10082==by 0x403164: main (main.c:146)
 ==10082==  Uninitialised value was created by a stack allocation
 ==10082==at 0x405550: connect_arcs (connect.c:23)
 ==10082==
 ==10082== Conditional jump or move depends on uninitialised value(s)
 ==10082==at 0x5FBA8D8: dig_line_box (box.c:51)
 ==10082==by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895)
 ==10082==by 0x4E75161: V2_write_line_nat (write_nat.c:80)
 ==10082==by 0x4E50FA3: Vect_write_line (write.c:189)
 ==10082==by 0x405A1B: connect_arcs (connect.c:122)
 ==10082==by 0x403164: main (main.c:146)
 ==10082==  Uninitialised value was created by a stack allocation
 ==10082==at 0x405550: connect_arcs (connect.c:23)
 ==10082==
 ==10082== Conditional jump or move depends on uninitialised value(s)
 ==10082==at 0x5FBA8D8: dig_line_box (box.c:51)
 ==10082==by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895)
 ==10082==by 0x4E752A4: V2_rewrite_line_nat (write_nat.c:228)
 ==10082==by 0x4E51082: Vect_rewrite_line (write.c:231)
 ==10082==by 0x405979: connect_arcs (connect.c:87)
 ==10082==by 0x403164: main (main.c:146)
 ==10082==  Uninitialised value was created by a stack allocation
 ==10082==at 0x405550: connect_arcs (connect.c:23)
 ==10082==
 ==10082== Conditional jump or move depends on uninitialised value(s)
 ==10082==at 0x4E68F68: Vect_line_prune (

Re: [GRASS-dev] [GRASS GIS] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:18 martinl]:
 > Replying to [comment:14 martinl]:
 >
 > it seems to crash at source:grass/trunk/vector/v.net/connect.c#L87

 more precisely it's somewhere here:
 source:grass/trunk/lib/vector/Vlib/write.c#L231. In my case before calling
 rewrite fn from array `points = 04033a60`, inside `V2_rewrite_line_nat()`
 it's lost `points = 0002`.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

[Javier Martínez-López]

Hi Paulo,

you can see an implementation of the mahalanobis distance computed in
parallel (using all computer processors) for a single image here:

https://github.com/javimarlop/eHabpy/blob/master/ehab.py

see lines 32-86 and 597. I hope it helps! Cheers, Javier

On Sat, Feb 14, 2015 at 7:29 PM, Vaclav Petras  wrote:
>
> On Sat, Feb 14, 2015 at 11:47 AM, Paulo van Breugel 
> wrote:
>>
>>
>> For a quick solution, what about using r.tile to split the input data in
>> tiles and compute the mahalanobis distance per tile.
>
>
> See PyGRASS GridModule class which will do tiling (and a lot of other
> things) for you.
>
> http://grass.osgeo.org/grass70/manuals/libpython/pygrass.modules.grid.html
>
> ___
> 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] #2534: i.segment.hierarchical install error

[Javier Martínez-López]

Thank you Markus! Cheers, Javier

On Sat, Feb 14, 2015 at 12:36 PM, Markus Neteler  wrote:
> On Fri, Feb 13, 2015 at 7:44 PM, Javier Martínez-López
>  wrote:
>> I have the same issue in GRASS 7.1 revision: 63930 under Fedora linux
>> 21, is it possible to go around this problem?
>
> Sure (I'm also on Fedora) but this is vali for any Linux distro
>
> you need to specify where your GRASS GIS sources are:
>
> e.g.:
>
> make MODULE_TOPDIR=$HOME/software/grass71
>
> then it compiles fine.
>
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  LibVector| Version:  svn-releasebranch70  
 Keywords:  v.net|Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:15 neteler]:
 > Anyone willing to write a test case for this line?
 >
  {{{
  v.net streets_wake points=schools_wake operation=connect thresh=1000
 output=network
  }}}

 Done in r64639.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

Hi Javier,

This looks really useful, thanks! My python skills are very limited, so I
will have to look at it better to see what I can understand. But to start,
the parallel function, does that also solve the handling of potentially
very large raster layers?

Btw, this does look like a very useful set of functions, any plan to
develop this into a GRASS addon or function?

Paulo


On Sun, Feb 15, 2015 at 9:22 PM, Javier Martínez-López <
javi.martinez.lo...@gmail.com> wrote:

> Hi Paulo,
>
> you can see an implementation of the mahalanobis distance computed in
> parallel (using all computer processors) for a single image here:
>
> https://github.com/javimarlop/eHabpy/blob/master/ehab.py
>
> see lines 32-86 and 597. I hope it helps! Cheers, Javier
>
> On Sat, Feb 14, 2015 at 7:29 PM, Vaclav Petras 
> wrote:
> >
> > On Sat, Feb 14, 2015 at 11:47 AM, Paulo van Breugel <
> p.vanbreu...@gmail.com>
> > wrote:
> >>
> >>
> >> For a quick solution, what about using r.tile to split the input data in
> >> tiles and compute the mahalanobis distance per tile.
> >
> >
> > See PyGRASS GridModule class which will do tiling (and a lot of other
> > things) for you.
> >
> >
> http://grass.osgeo.org/grass70/manuals/libpython/pygrass.modules.grid.html
> >
> > ___
> > 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] Howto use a Python function as error handler in libgis

[Sören Gebbert]

Hi Glynn,
thanks a lot, that solved the issue.

Best regards
Soeren

2015-02-14 4:10 GMT+01:00 Glynn Clements :
>
> Sören Gebbert wrote:
>
>> Dear developers,
>> i am trying to register a Python function as error handler callback
>> using ctypes in libgis.
>> I use this code in the temporal framework:
>>
>>
>> {{{
>> def error_handler(data):
>> pass
>>
>> CALLBACK = CFUNCTYPE(None, c_void_p)
>
> AFAICT, this needs to be:
>
> CALLBACK = CFUNCTYPE(c_void_p, c_void_p)
>
> For callbacks, ctypesgen converts any return type which isn't a
> primitive C type to c_void_p. And None isn't a primitive C type.
>
> --
> Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1658: g.rename, g.copy do not ask for --overwrite, they just do it

[GRASS GIS]

#1658: g.rename, g.copy do not ask for --overwrite, they just do it
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…
  
 Type:  defect   |  Status:  new
  
 Priority:  major|   Milestone:  6.5.0  
  
Component:  Default  | Version:  svn-develbranch6   
  
 Keywords:  g.rename, g.copy, overwrite  |Platform:  Linux  
  
  Cpu:  x86-64   |  
-+--

Comment(by wenzeslaus):

 Please, have a look at a test for `g.rename` in version 7 (trunk) and add
 cases which you think are missing:
  * source:trunk/general/g.rename/testsuite
  *
 
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-02-15-08-00/report_for_nc_spm_08_grass7_nc/general/g.rename/test_overwrite/index.html

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Updating tests for t.connect

[Vaclav Petras]

Hi,

in past days [1] several tests related to t.connect were failing with the
following error message [2]:

Process ended with non-zero return code g.mapset(mapset='test1',
flags=u'c'). See the following errors:
ERROR: There appears to be an active GRASS session in selected mapset
   

The tests are unique because they are creating custom Mapsets and switching
into them. I committed a fix for the tests [r64641] which should be applied
anyway and documented what is needed in these cases [r64642]. However, the
tests were happily running for quite some time and I'm not sure what caused
the Mapsets to contain the lock.

It seems as a local problem, I was not able to reproduce it on other
machine, but I don't have an idea what would be the problem on the testing
server. I'm just little bit worried if there might be some unexpected
change between r64535 (day before the potential problem), r64546 (day
before failed tests) and r64581 (first day with failed tests) [3]. It's
probably nothing but I just wanted to let everybody know if somebody would
have some doubts too.

Vaclav

[1] http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
[2]
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-02-12-08-00/report_for_nc_spm_08_grass7_nc/temporal/t.connect/test_distr_tgis_db_raster/index.html
[3] https://trac.osgeo.org/grass/log/grass/trunk?rev=64581&stop_rev=64535
https://trac.osgeo.org/grass/changeset/64641
https://trac.osgeo.org/grass/changeset/64642

BTW, I did also some PEP8 and Pylint cleaning in the files. Please, use
these tools to check the Python files. Please check wiki, doc, and tools
directory for more info:

http://grasswiki.osgeo.org/wiki/Tools_for_Python_programming
http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#analyzing-quality-of-source-code
https://trac.osgeo.org/grass/browser/grass/trunk/tools
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev