Re: [GRASS-dev] [GRASS GIS] #2854: results in winGRASS7 32bit vs 64bit: should they be identical?

[GRASS GIS]

#2854: results in winGRASS7 32bit vs 64bit: should they be identical?
-+-
  Reporter:  hellik  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Raster  |Version:  svn-releasebranch70
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by neteler):

 Please also add the "r.univar -e ..." output of

 {{{
 r.mapcalc "difftestepsilon_values = if( abs( accum_wg32bit@watershedtest -
 accum_wg64bit@watershedtest  ) <= 1.0e-15 , 1 ,
 accum_wg32bit@watershedtest - accum_wg64bit@watershedtest )"
 }}}

 to see the actual differences and not 100. Thanks.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] SUCCESS (running): Compiling grass 7 svn trunk on OS X El Capitan

[Rainer M Krug]

William Kyngesburye  writes:

> It's probably the new SIP security protection, which makes executables
> ignore DYLD_LIBRARY_PATH.  Part of GRASS compilation is to run the
> modules to generate help files.  Since they're not in their install
> location yet, DYLD_LIBRARY_PATH is needed for them to find the GRASS
> libraries, but DYLD_LIBRARY_PATH is now ignored, and it fails.
>
> One option is to disable SIP before compilation and reenble it after
> installation.  I haven't upgraded to El Capitan yet so I don't know
> the exact way to do this.  Probably in System Prefs-Security.

OK - I don't want to go this road as it is going to deep in the OS.

But I am one step further: The problem is *not* the compilation of the
binaries which works. I followed theses steps and got quite a bit
further:

1) Checkout grass
#+begin_src sh 
cd ~
mkdir ownCompiled/grass/
cd ownCompiled/grass/
svn checkout https://svn.osgeo.org/grass/grass/trunk grass7_trunk
cd grass7_trunk
#+end_src

and do the following change to ./include/Make/Install.make to *not*
create symlinls in protected directories:

--8<---cut here---start->8---
Index: Install.make
===
--- Install.make(revision 67509)
+++ Install.make(working copy)
@@ -118,7 +118,7 @@
 
 ifneq ($(findstring darwin,$(ARCH)),)
@# enable OSX Help Viewer
-   @/bin/ln -sfh "$(INST_DIR)/docs/html" 
/Library/Documentation/Help/GRASS-$(GRASS_VERSION_MAJOR).$(GRASS_VERSION_MINOR)
+   @# /bin/ln -sfh "$(INST_DIR)/docs/html" 
/Library/Documentation/Help/GRASS-$(GRASS_VERSION_MAJOR).$(GRASS_VERSION_MINOR)
 endif
 
 $(INST_DIR) $(UNIX_BIN):
--8<---cut here---end--->8---


2) Configure GRASS 7
#+begin_src sh 
export LDFLAGS='-L/usr/local/lib -L/usr/local/opt/sqlite/lib'
export CPPFLAGS='-I/usr/local/include -I/usr/local/opt/sqlite/include'
./configure --with-opengl=aqua --with-freetype=no --with-cxx --with-sqlite 
--prefix=~/ownCompiled/grass
#+end_src

3) Make the first time. I use all eight cores for compilation (-j 8) 
#+begin_src sh 
make -j 8
#+end_src

Here I get many errors. I ignore these for now.

4) Install grass
#+begin_src sh 
make install  
#+end_src
Which ends without errors due to the patch above.

5) Now I run make again
#+begin_src sh 
make -j 8  
#+end_src

This now ends with several errors in t.* modules which I guess are
likely caused by the first one in v.what.stdrs:

,
| 1:27:42 ~/ownCompiled/grass/grass7_trunk/scripts/v.what.strds$ make
| if [ 
"/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/v.what.strds"
 != "" ] ; then 
GISRC=/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/demolocation/.grassrc71
 
GISBASE=/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0
 
PATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts:$PATH"
 
PYTHONPATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/gui/wxpython:$PYTHONPATH"
 
DYLD_LIBRARY_PATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib:"
 LC_ALL=C 
/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/v.what.strds
 --html-description < /dev/null | grep -v '\|' > 
v.what.strds.tmp.html ; fi
| Traceback (most recent call last):
|   File 
"/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/v.what.strds",
 line 53, in 
| import grass.temporal as tgis
|   File 
"/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python/grass/temporal/__init__.py",
 line 1, in 
| from core import *
|   File 
"/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python/grass/temporal/core.py",
 line 39, in 
| from c_libraries_interface import *
|   File 
"/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python/grass/temporal/c_libraries_interface.py",
 line 22, in 
| import grass.lib.gis as libgis
|   File 
"/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python/grass/lib/gis.py",
 line 23, in 
| _libs["grass_gis.7.1.svn"] = 

Re: [GRASS-dev] [GRASS GIS] #2845: Build failure with 7.0.3RC1 on Linux

[GRASS GIS]

#2845: Build failure with 7.0.3RC1 on Linux
+-
  Reporter:  scimmia|  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  blocker|  Milestone:  7.0.3
 Component:  Compiling  |Version:  unspecified
Resolution: |   Keywords:
   CPU:  x86-64 |   Platform:  Linux
+-

Comment (by neteler):

 Replying to [comment:16 scimmia]:
 > OK, new info. I was able to build from r67442 just fine. I ran a
 recursive diff to see what the difference was between the tarball and the
 svn checkout, and found that gui/wxpython/xml/menudata.xml and
 gui/wxpython/xml/module_tree_menudata.xml don't exist in SVN. Removing
 those two files from the tarball lets me build.

 Great you found the issue! Yet I am surprised since

 {{{
 gui/wxpython/Makefile
 }}}

 contains

 {{{
 EXTRA_CLEAN_FILES = menustrings.py build_ext.pyc xml/menudata.xml
 xml/module_tree_menudata.xml */*.pyc
 }}}

 ... so it is wiped out here:

 {{{
 grep EXTRA_CLEAN_FILES include/Make/Rules.make
 -rm -f $(EXTRA_CLEAN_FILES) *.tab.[ch] *.yy.c *.output *.backup
 *.tmp.html *.pyc $(DEPFILE)
 }}}

 I have updated the release procedure to explicitly delete these files in
 r67511, r67512.
 Now this should no longer happen.

 I suggest to take these EXTRA_CLEAN_FILES files away from "svn propset"
 whitelisting to be sure that they become visible when running `svn
 status`. How to do that?

--
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] #2814: digitizer crashes, leaves vector broken

[GRASS GIS]

#2814: digitizer crashes, leaves vector broken
--+---
  Reporter:  harrikoo |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  wxGUI|Version:  7.0.2
Resolution:   |   Keywords:  digitizer, vector
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 Replying to [comment:7 martinl]:
 > Replying to [comment:1 mlennert]:
 > > 1.
 > >
 > > * Digitize one straight line.
 > > * Digitize a second straight line that crosses the first
 > > * Hit undo
 > >
 > > => Segmentation fault
 > >
 > > 2.
 > >
 > > * Digitize an area with the last line crossing the first
 > > * Undo
 > >
 > > => Segmentation fault
 > >
 > >
 > > 3.
 > >
 > > * Digitize one straight line
 > > * Undo
 > > * Redo
 > >
 > > => Segmentation fault
 >
 > 1. and 3. should be fixed in r67508. I don't understand 2. (what does
 mean "an area with the last line crossing the first"?)

 2. means: digitize an area, but instead of closing the area correctly, you
 draw the last (closing) line in a way that it intersects the first (or
 actually any of the other lines making up your area) and then you undo.
 It's just another case of intersecting lines causing problems with undo...

 Everything works great now. Thanks a lot for this fix !

 Could others help testing if they can find any bad side effects of this
 change ?

 If not, and unless someone (MarkusM ?) has any special reason to delay
 this, I would suggest to backport this to release70

 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] R and GRASS integration

[Paulo van Breugel]

On 06-01-16 18:24, Rainer M Krug wrote:

Paulo van Breugel  writes:


On Wed, Jan 6, 2016 at 10:27 AM, Rainer M Krug 
wrote:

 Paulo van Breugel  writes:
 
 > I by any stretch of imagination a developer, but I did use the

 > combination of shell or pythons script with R, basically
 following the
 > approach you described, having a python or shell script write a
 R
 > script to a text file and run it. I think it can work well, and
 not
 > that much harder to maintain. But I also would be very
 interested to
 > learn how to do this better. I also would be interested to see
 the
 > randomForest scripts you mentioned Steven, are you already
 sharing it
 > somewhere?
 >
 > As you mentioned, there are probably many people using / writing
 R
 > scripts that interact with GRASS. For some it will be easier, or
 it
 > may be more logical for them, to turn these into R packages
 rather
 > than writing a GRASS addon.
 
 I am one of those. I have thought about making a GRASS (or QGIS)

 addon /
 plugin, but I stayed with the R package. I have a complete
 simulation
 written in R which uses spatial data from GRASS, does simulations,
 and
 returns the results to GRASS.
 


 To run the simulations in itself is a three liner in R.
 
 > It would be nice if there would be some kind of repository where

 > people share such code (github perhaps?). I am sure there are
 existing
 > ones on e.g., github, so perhaps just a GRASS-wiki page listing
 > existing repositories would be enough. I know there is
 > https://grasswiki.osgeo.org/wiki/R_statistics, but I don't think
 there
 > is an place on the GRASS website, wiki or trac to share/list R
 code?
 > Would this be of interest to create such page (on the Wiki
 perhaps?).
 
 Different people use different repos (I use e.g. github and

 gitlab) so
 creating another place where I should publish my code would be not
 really an option. What would be an idea to make it easy (probably
 even
 easier even than editing a wiki page?) to add a repo to a list of
 projects which integrate R in GRASS or GRASS in R, and which could
 indicate the last commit to aser if the repos are current or just
 archives from e.g. papers or finished projects.
 


+1 That would be something quick to implement. However, what form did
you have in mind, if not a wiki page? I wouldn't mind creating such
page, but perhaps first some further ideas on the best form from
others as well.

I thought about a field, where I just add the link to the repository and
some info (Author, short description, possibly License type, ...) and
this is automatically added to the page including information from the
repo like last updated, link to the README, ... But this might be
getting to complicated. But I know it from my side - editing a wiki page
is often a "will do later" thing.

Also a system where there is an form where one fills in the info and it
is emailed to somebody to add it to the wiki would work.
Creating an automated form, etc wouldn't be something I could do, but I 
wouldn't mind maintaining a a list on the GRASS wiki based on 
information from a user form. Perhaps a Google form? Any ideas / 
opinions on this from the devs?



 My repo is private at the moment, but I plan to make it open in
 the next
 few weeks.
 
 A brief presentation about a very similar simulation model can be

 found at
 
 https://github.com/rkrug/INTECOL_2013_Optimizing
 
 
 


Thanks for sharing, interesting. Looking forwards seeing some further
code

Thanks - I will keep you posted.

Coming back to the initial question:

What we would need in the meantime is possibly a discussion, on how R
functions could be used in an automated way - i.e. something along the
lines of an R package, which contains a set of defined functions like:

getFunctionNames() :: which returns the function names which can be
called from GRASS

getFunctionInterface(functionName) :: which returns the arguments of the
function functionName (similar to the interfaceDescription (I think it
is called differently) in GRASS commands)

would make it possible to just

1) load any R package which has these functions
2) and get all function names and arguments needed
3) and just call the R function in an easy way like
g.call.R package=PACKAGENAME function=FUNCTIONNAME
arguments="arguments for the R function)

The function could than be executed by using either a relatively simple python 
or
direct Rscript approach.

Also, one could even dynamically load an R package and construct all the
calls including help, so they could be called by using
g.call.R.PACKAGENAME.FUNCTIONNAME arg1=ARG1 arg2=ARG2

 From the R side, this would be relatively 

Re: [GRASS-dev] [GRASS GIS] #2814: digitizer crashes, leaves vector broken

[GRASS GIS]

#2814: digitizer crashes, leaves vector broken
--+---
  Reporter:  harrikoo |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  wxGUI|Version:  7.0.2
Resolution:   |   Keywords:  digitizer, vector
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 Replying to [comment:8 mlennert]:
 > Could others help testing if they can find any bad side effects of this
 change ?
 >
 The test cases work now for me as well.

--
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] #2814: digitizer crashes, leaves vector broken

[GRASS GIS]

#2814: digitizer crashes, leaves vector broken
--+---
  Reporter:  harrikoo |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  wxGUI|Version:  7.0.2
Resolution:   |   Keywords:  digitizer, vector
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 Replying to [comment:11 annakrat]:
 > Replying to [comment:8 mlennert]:
 > > Could others help testing if they can find any bad side effects of
 this change ?
 > >
 > The test cases work now for me as well.

 Thanks for testing (and thanks for the tips on QtCreator).

 AFAICS, the functions that were changed are only used in the wx digitizer,
 so I don't have the feeling that there is much to be expected in terms of
 unwanted side effects. I, therefore, think that we can backport.

 Martin, will you do that, or should I (I don't know how much the code of
 the digitizer has changed between trunk and release70) ?

--
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] #2854: results in winGRASS7 32bit vs 64bit: should they be identical?

[GRASS GIS]

#2854: results in winGRASS7 32bit vs 64bit: should they be identical?
-+-
  Reporter:  hellik  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Raster  |Version:  svn-releasebranch70
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by hellik):

 Replying to [comment:1 neteler]:
 > Please also add the "r.univar -e ..." output of
 >
 > {{{
 > r.mapcalc "difftestepsilon_values = if( abs( accum_wg32bit@watershedtest
 - accum_wg64bit@watershedtest  ) <= 1.0e-15 , 1 ,
 accum_wg32bit@watershedtest - accum_wg64bit@watershedtest )"
 > }}}
 >
 > to see the actual differences and not 100. Thanks.

 {{{
 r.mapcalc expression=difftestepsilon_values = if(abs(
 accum_wg32bit@watershedtest - accum_wg64bit@watershedtest  ) <= 1.0e-15, 1
 , accum_wg32bit@watershedtest - accum_wg64bit@watershedtest )
 }}}

 {{{
 r.univar -e map=difftestepsilon_values@watershedtest
 total null and non-null cells: 2025000
 total null cells: 0
 Of the non-null cells:
 --
 n: 2025000
 minimum: -8.14907e-010
 maximum: 1
 range: 1
 mean: 0.681817
 mean of absolute values: 0.681817
 standard deviation: 0.465771
 variance: 0.216942
 variation coefficient: 68.3131 %
 sum: 1380679.9932
 1st quartile: 3.55271e-015
 median (even number of cells): 1
 3rd quartile: 1
 90th percentile: 1
 }}}

--
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] #2814: digitizer crashes, leaves vector broken

[GRASS GIS]

#2814: digitizer crashes, leaves vector broken
--+---
  Reporter:  harrikoo |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  wxGUI|Version:  7.0.2
Resolution:   |   Keywords:  digitizer, vector
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 Replying to [comment:9 mlennert]:
 > Replying to [comment:5 neteler]:
 > > Replying to [comment:4 mlennert]:
 > > > Found the change at fault: r64214. Now we need to identify what in
 that change causes the segfault.
 > >
 > > Cannot you run it all through "gdb" for a backtrace?
 >
 > Well, I've never managed to debug GUI issues via gdb, notably since
 g.gui.vdigit is a Python script, not a C-module. Do you have tips on how
 to debug such issues with gdb ?

 For this case I use gdb trough QtCreator, you can attach external process
 - the gui and if gui crashes, it will show where in the c code it
 happened. This is quite easy, there is a wiki on using QtCreator with
 GRASS[https://grasswiki.osgeo.org/wiki/Using_QtCreator_for_GRASS_C_development
 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] #2854: results in winGRASS7 32bit vs 64bit: should they be identical?

[GRASS GIS]

#2854: results in winGRASS7 32bit vs 64bit: should they be identical?
-+-
  Reporter:  hellik  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Raster  |Version:  svn-releasebranch70
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by hellik):

 Replying to [comment:1 neteler]:
 > Please also add the "r.univar -e ..." output of
 >
 > {{{
 > r.mapcalc "difftestepsilon_values = if( abs( accum_wg32bit@watershedtest
 - accum_wg64bit@watershedtest  ) <= 1.0e-15 , 1 ,
 accum_wg32bit@watershedtest - accum_wg64bit@watershedtest )"
 > }}}
 >
 > to see the actual differences and not 100. Thanks.

 tested with r.slope.aspect


 {{{
 r.slope.aspect elevation=elevation@PERMANENT slope=slope_wg32bit
 aspect=aspect_wg32bit
 r.slope.aspect elevation=elevation@PERMANENT slope=slope_wg64bit
 aspect=aspect_wg64bit
 }}}

 {{{
 r.mapcalc expression=diff_slope = slope_wg32bit@slope_test -
 slope_wg64bit@slope_test

 r.univar -e map=diff_slope@slope_test
 total null and non-null cells: 2025000
 total null cells: 5696
 Of the non-null cells:
 --
 n: 2019304
 minimum: 0
 maximum: 0
 range: 0
 mean: 0
 mean of absolute values: 0
 standard deviation: 0
 variance: 0
 variation coefficient: nan %
 sum: 0
 1st quartile: 0
 median (even number of cells): 0
 3rd quartile: 0
 90th percentile: 0
 }}}

 and also tested with r.topidx

 {{{
 r.topidx input=elevation@PERMANENT output=topidx_wg32bit
 r.topidx input=elevation@PERMANENT output=topidx_wg64bit
 }}}

 {{{
 r.mapcalc expression=diff_topidx_epsilon = if( abs(
 topidx_wg32bit@test_topidx - topidx_wg64bit@test_topidx ) <= 1.0e-15 ,
 null()  , topidx_wg32bit@test_topidx - topidx_wg64bit@test_topidx )
 }}}

 {{{
 r.mapcalc expression=diff_topidx_epsilon = if( abs(
 topidx_wg32bit@test_topidx - topidx_wg64bit@test_topidx ) <= 1.0e-15 ,
 null()  , topidx_wg32bit@test_topidx - topidx_wg64bit@test_topidx )

 r.univar -e map=diff_topidx_epsilon@test_topidx
 total null and non-null cells: 2025000
 total null cells: 1920831
 Of the non-null cells:
 --
 n: 104169
 minimum: -3.55271e-015
 maximum: 3.55271e-015
 range: 7.10543e-015
 mean: -1.67607e-015
 mean of absolute values: 1.7849e-015
 standard deviation: 0
 variance: 0
 variation coefficient: -0 %
 sum: -1.74594561030972e-010
 1st quartile: -1.77636e-015
 median (odd number of cells): -1.77636e-015
 3rd quartile: -1.77636e-015
 90th percentile: -1.77636e-015
 }}}

--
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] #2854: results in winGRASS7 32bit vs 64bit: should they be identical?

[GRASS GIS]

#2854: results in winGRASS7 32bit vs 64bit: should they be identical?
-+-
  Reporter:  hellik  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Raster  |Version:  svn-releasebranch70
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by hellik):

 Replying to [comment:5 hellik]:
 >
 > tested with r.slope.aspect
 >
 >
 > {{{
 > r.slope.aspect elevation=elevation@PERMANENT slope=slope_wg32bit
 aspect=aspect_wg32bit
 > r.slope.aspect elevation=elevation@PERMANENT slope=slope_wg64bit
 aspect=aspect_wg64bit
 > }}}
 >
 > {{{
 > r.mapcalc expression=diff_slope = slope_wg32bit@slope_test -
 slope_wg64bit@slope_test
 >
 > r.univar -e map=diff_slope@slope_test
 > total null and non-null cells: 2025000
 > total null cells: 5696
 > Of the non-null cells:
 > --
 > n: 2019304
 > minimum: 0
 > maximum: 0
 > range: 0
 > mean: 0
 > mean of absolute values: 0
 > standard deviation: 0
 > variance: 0
 > variation coefficient: nan %
 > sum: 0
 > 1st quartile: 0
 > median (even number of cells): 0
 > 3rd quartile: 0
 > 90th percentile: 0
 > }}}

 {{{
 r.mapcalc expression=diff_aspect = aspect_wg32bit@slope_test -
 aspect_wg64bit@slope_test

 r.univar -e map=diff_aspect@slope_test
 total null and non-null cells: 2025000
 total null cells: 5696
 Of the non-null cells:
 --
 n: 2019304
 minimum: 0
 maximum: 0
 range: 0
 mean: 0
 mean of absolute values: 0
 standard deviation: 0
 variance: 0
 variation coefficient: nan %
 sum: 0
 1st quartile: 0
 median (even number of cells): 0
 3rd quartile: 0
 90th percentile: 0
 }}}

--
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] #2855: Closing GUI Cancel button doesn't work

[GRASS GIS]

#2855: Closing GUI Cancel button doesn't work
--+-
 Reporter:  annakrat  |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.0.3
Component:  wxGUI |Version:  unspecified
 Keywords:|CPU:  Unspecified
 Platform:  All   |
--+-
 It happens when you close GUI and a dialog appears with the choice of
 closing either GUI only or GRASS session followed by a dialog asking to
 save your workspace. The second dialog has a Cancel button which doesn't
 work if you previously selected close GRASS session - GRASS just shuts
 down. Perhaps the Cancel button should not be there at all?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.mapcalc: warning: field width should have type 'int', but argument has type 'yy_size_t'

[Glynn Clements]

Markus Neteler wrote:

> compiling relbranch70 (likely the same on trunk), I got

Try r67518.

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

Re: [GRASS-dev] [GRASS GIS] #2845: Build failure with 7.0.3RC1 on Linux

[GRASS GIS]

#2845: Build failure with 7.0.3RC1 on Linux
+-
  Reporter:  scimmia|  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  blocker|  Milestone:  7.0.3
 Component:  Compiling  |Version:  unspecified
Resolution: |   Keywords:
   CPU:  x86-64 |   Platform:  Linux
+-

Comment (by glynn):

 Replying to [comment:17 neteler]:

 > I suggest to take these EXTRA_CLEAN_FILES files away from "svn propset"
 whitelisting to be sure that they become visible when running `svn
 status`. How to do that?
 {{{
 svn propdel svn:ignore gui/wxpython/xml
 }}}

--
Ticket URL: 
GRASS GIS 

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