[GRASS-dev] [GRASS GIS] #2591: error in grass.sh selecting python version

[GRASS GIS]

#2591: error in grass.sh selecting python version
---+
 Reporter:  foret37|   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Default| Version:  unspecified  
 Keywords: |Platform:  Unspecified  
  Cpu:  OSX/Intel  |  
---+
 I am running Grass 7.0.0RC1 on a Mac OSX 10.10.2. I launched the program
 using the Grass app, and it failed with an error.

 I then ran the script directly in the term, in order to see the error.

 > cd /Applications/GRASS/GRASS-7.0.app/Contents/MacOS/
 > ./grass.sh
 Rebuilding Addon HTML manual pages index...
 Rebuilding Addon menu...
 Python 2.7.9 found.
 arch: posix_spawnp: /opt/local/bin/pythonw2.7: Bad CPU type in executable

 This problem is well known, and has to do with the selection of the wrong
 version of python, as discussed at
 http://grasswiki.osgeo.org/wiki/MacOSX_GRASS_errors.
 Some sluthing showed that grass.sh selects a link in my MacPorts
 directory, /opt/local/bin, that points to the native Apple version of
 python.
 I followed the instructions at MacOSX_GRASS_errors and added the following
 environment variables:
 export GRASS_PYTHON=/usr/bin/python2.6
 export GRASS_PYTHONWX=/usr/bin/pythonw2.6
 but that did not fix the problem (same errors).
 After a lot of messing around, I found that I can get grass started by
 placing the directory with the right version of python as first in the
 path string:
 export PATH="/usr/bin:$PATH"
 Grass launches now, regardless of the status of the GRASS_PYTHON and
 GRASS_PYTHONWX variables.
 My casual reading of the grass.sh script suggests that it never checks
 GRASS_PYTHONWX to see if it has a value.
 That issue suggests that the solution to the problem is add a check for
 GRASS_PYTHONWX.

 One other issue that seems odd: Grass does not remember my initial
 settings. In other words, each time I login, it goes through the questions
 for a new user.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] r.mapcalc random result different on MS Windows with same seed

[Vaclav Petras]

Hello,

it seems that r.mapcalc gives different (pseudo-)random result on MS
Windows then it is giving on Linux. In NC sample dataset:

g.region n=20 s=10 e=25 w=15 res=1
r.mapcalc "rand_cell = rand(1, 200)" seed=500
r.info rand_cell -r

gives the following on Linux:

min=1
max=195

while on MS Windows it gives:

min=1
max=196

The test for r.mapcalc seed fails on MS Windows 8.1 (64bit) [1] but the
results are even worse, so I'm not sure what exactly is the issue there:

mismatch values (key, reference, actual): [('max', 0, 80), ('min', 0,
-119)]

Can somebody confirm this behavior and/or test it on different platforms?

Both the individual commands and the tests needs to be executed. The test
can be executed using:

cd raster/r.mapcalc/testsuite
python test_r_mapcalc.py
(g.remove rand_cell)

On Linux, I'm getting the same manually and from the test [2]. The thing
which is extra in the tests is the import from ASCII. There are similar
tests for r.mapcalc and seed but the only test which is failing is the one
with type CELL.

Vaclav

[1]
http://fatra.cnr.ncsu.edu/grassgistests/mswindows/reports_for_date-2015-02-18-21-00/report_for_nc_spm_08_grass7_nc/raster/r.mapcalc/test_r_mapcalc/index.html

[2]
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-02-18-08-00/report_for_nc_spm_08_grass7_nc/raster/r.mapcalc/test_r_mapcalc/index.html

[3]
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_r_mapcalc.py
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1819: problems compiling map swipe, animation, modeler, and r.li.setup

[GRASS GIS]

#1819: problems compiling map swipe, animation, modeler, and r.li.setup
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  g.gui.* modules  |Platform:  MacOSX   
  Cpu:  OSX/Intel|  
-+--

Comment(by cmbarton):

 Replying to [comment:12 wenzeslaus]:
 >
 > Replying to [comment:10 cmbarton]:
 > > This solved all the compiler errors except for g.gui.tplot
 >
 > I simply forgot to change `g.gui.tplot` because I was looking at the
 list in comment:7:ticket:2561. Fixed in r64674.
 >
 > Replying to [comment:10 cmbarton]:
 > >  and the failure to make the menu tree xml files.
 > Replying to [comment:11 cmbarton]:
 > > Because of the failure for some Python code to create the menu tree
 files during compilation, I have to launch a GRASS session, cd to the
 ../gui/wxpython directory, make clean, and make. This also 'fixed' the
 errors in animation, map swipe, etc.
 >
 > That's the part which should be fixed once #2142 is fixed.
 Unfortunately, I'm not able to fix it for the 7.0.0 release. It requires a
 lot of design decisions and testing.
 >
 > And as I said, these changes make sense in general but basically they
 are all workarounds. The actual issue is wrong runtime environment during
 compilation where 64 and 32 bit libraries are mixed.
 >
 > This ticket should be closed once r64664 and r64674 are backported to
 release branch 7.0.


 The compiling errors for mapswipe, etc (including tplot) are all now
 fixed. The automatic menu building is not fixed.

-- 
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] #1819: problems compiling map swipe, animation, modeler, and r.li.setup

[GRASS GIS]

#1819: problems compiling map swipe, animation, modeler, and r.li.setup
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  g.gui.* modules  |Platform:  MacOSX   
  Cpu:  OSX/Intel|  
-+--

Comment(by cmbarton):

 Replying to [comment:15 wenzeslaus]:
 > Replying to [comment:14 cmbarton]:
 > > Which items are fixed in  r64677? I can recompile on Thursday but need
 to know what to look for.
 >
 > `toolboxes.py` is called (as a script) during compilation to build the
 XMLs for toolboxes. `toolboxes.py` before r64677 required wxPython even
 when executed as a script. The environment to run GRASS modules (and
 `toolboxes.py` script) during compilation is somehow incomplete. The wrong
 environment cases wrong wxPython/wxWidgets to load. Then import fails and
 the thus `toolboxes.py` script fails to create the XMLs.
 >
 > r64677 removes the need to import wxPython when `toolboxes.py` is
 executed as a script. Thus the script does not need the build environment
 to be perfect. Thus it should work on Mac OS X and build the XMLs.
 >
 > This is unrelated to the original topic of this ticket. This relates to
 XML, toolboxes and menu problem mentioned in comment:10.
 >
 > > On the Mac, because of problems running wxPython for 64 bit, the
 compiling environment is forced to 32 bit for Python. That should not be a
 problem and indeed is not for all compiling except these modules, all of
 which use a new windowing class developed initially for map swipe.
 >
 > I have no idea about which class you are talking about. What the
 directories which were failing has in common is that they contain
 `g.gui.*` modules. All modules (`r.*`, `v.*`, ..., `g.gui.*`) needs to be
 executed during compilation to build manual pages. The issue is that
 `g.gui.*` required wxPython to be imported. Thus hitting the same issue
 with incomplete build environment as mentioned above. The commits r64664
 and r64674 remove the need to import wxPython packages in `g.gui.*` when
 only `grass.script.core.parser()` is called to obtain the interface
 description (execution ends with `parser()` call when the module is asked
 just for the interface using `--interface-description`). The trick in
 r64664 and r64674 is that imports are done only after `parser()` call in
 the body of `main()` function where the packages are needed (and not using
 the standard import at the begging of the file).
 >
 > > Perhaps they are trying to force the import of 64 bit wx, which is
 incorrect for current Mac compiling, and would conflict with the 32 bit
 Python environment set as default for compiling.
 >
 > They are not trying to do that, at least there is nothing in GRASS GIS
 source code which would indicate that (please check me). I cannot say what
 is in wxPython itself (do you think that there is some class?). Supposing
 that wxPython is all right, the compilation environment must be wrong.
 >
 > > That seems to be what is going on with the failure to correctly create
 the menu xml files too. The errors are the same--they cannot import wx.
 >
 > They are indeed the same and thus r64664, r64674 and r64677 are using
 the same approach of avoiding global imports of wx-related packages.
 >
 > > It acts like there is a hardwired call to Python or wxPython somewhere
 instead of calling it using the system default path.
 >
 > If there is something wrong in GRASS GIS wxGUI source code or source
 code of wxPython itself and you would find it, it would be very useful. I
 don't know where is the problem but I haven't seen anything like this in
 wxGUI source code. And wxGUI and modules are running when started from
 regular GRASS session. Therefore I think that the problem is in build
 environment, i.e. GRASS Makefiles.

 I am pretty sure that this must be either in a wxPython class created for
 mapswipe and reused for other modules OR something in the make/build
 environment used for part of the wxPython code. Or perhaps a combination
 of these. So far, I've tried to track it down, working with Anna but have
 failed so far.

 I hesitate to suggest a workaround instead of a fix. But one possibility
 that might be helpful is to automatically run the Python code to build the
 menu xml files each time GRASS is launched. This would eliminate the
 effects of this compiler problem (thought not the source). It could also
 have the benefit of providing an updated menu if there are any additions
 or subtractions to the modules in bin or scripts.

 Michael

-- 
Ticket URL: 
GRASS GIS 

_

[GRASS-dev] G7: add REVISION text file?

[Markus Neteler]

Hi,

on several build platforms "svnversion" is not supported which is
called by "configure".
I wonder if we should add in the release tarball a file "REVISION"
which could be added in include or the like and read if present to
populate

include/Make/Platform.make:GRASS_VERSION_SVN   = 64567
include/Make/Platform.make.in:GRASS_VERSION_SVN   = @GRASS_VERSION_SVN@

? It looks ugly to have r0:
Welcome to GRASS GIS 7.0.0svn (r0)

rather than

Welcome to GRASS GIS 7.0.0svn (r64634)

Ideas?

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Replying to [comment:193 martinl]:
 > Replying to [comment:192 neteler]:
 >
 > > Parameters renamed in r64083/r64085 + r64084/r64086.
 > > The default values I have still left as before.
 > >
 > > TODO: r.mapcalculator, r.reclass.area entry in lib/gis/renamed_option
 >
 > Is it still open?

 r.reclass.area is done.

 r.mapcalculator was proposed to be removed if not needed by QGIS
 Processing. I wonder how harmful it is to just keep it.

-- 
Ticket URL: 
GRASS GIS 

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