date:20160913

Re: [GRASS-dev] [GRASS GIS] #3151: raster digitizer crashes GUI in trunk

2016-09-13 Thread GRASS GIS

#3151: raster digitizer crashes GUI in trunk
--+--
  Reporter:  cmbarton |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  raster digitizer
   CPU:  Unspecified  |   Platform:  MacOSX
--+--
Changes (by annakrat):

 * keywords:   => raster digitizer
 * platform:  Unspecified => MacOSX


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] test of compiling GRASS Mac under El Capitan - very strange results

2016-09-13 Thread Michael Barton

I now have versions of GRASS 7.0.5, 7.2, and 7.3 that were compiled on a Mac 
running El Capitan that seem to work fine. They may work with Mac SIP/Rootless 
mode enabled. They work on my Mac but it would be good if someone else could 
test them on another Mac.

You can download them at: 
https://www.dropbox.com/sh/4t0h1x8xwz9qnlh/AACFl4WQNtUPSAPtFE4Eg1Eua?dl=0

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Sep 11, 2016, at 6:27 PM, Michael Barton 
> wrote:

I've tested with SIP disabled. GRASS 7.0.5svn works fine--with 3D and digitizer.

7.2 still looks like it is using wxPython 3 and 7.3 still won't launch. I will 
check compiling of 7.2 and 7.3 (tomorrow I hope) to see if there are any errors.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, 
http://csdc.asu.edu

On Sep 11, 2016, at 6:10 PM, Michael Barton 
> wrote:

I just tried all 3 versions of GRASS I compiled this week on my MacBook laptop. 
All three versions were compiled in exactly the same way with the same 
environment, as I have been compiling for a couple years now: dual 32/64 bit 
architecture, wxPython 2.8.12 (32 bit). No change to frameworks either.

The MacBook is running El Capitan. I had previously turned off SIP and it was 
running all versions of GRASS I compiled several months back. I recently 
updated the OS and apparently SIP was re-enabled. My laptop no longer will run 
the versions of GRASS I compiled several months back.

But weirdly it WILL run some of the versions I compiled this week. Or let us 
say that it mostly runs those versions.

7.0.5svn
Starts up with the error:

Unable to import pyGRASS: grass_gis.7.0.5svn not found.
Some functionality will be not accessible

No other problems. It appears to be running wxPython 2.8.12, and is running 
Python 32 bit as expected.

But there is no 3D mode and no vector digitizer. In the console are the errors:

3D view mode not available
Reason: grass_gis.7.0.5svn not found.
Vector digitizer not available
Reason: cannot import name GV_LINES
Note that the wxGUI's vector digitizer is currently disabled
(hopefully this will be fixed soon). Please keep an eye out
for updated versions of GRASS. In the meantime you can use
"v.digit" from the Develop Vector menu.

The rest of GRASS seems to work fine--even though SIP is enabled.

GRASS 7.2svn
Seems to function much as 7.0.5svn, except that it has a raster digitizer 
enabled. And it also has the looks of running wxPython 3.0.2.0 (even the 
errors, like no mouse control on specialized pull down lists)--even though 
Python reports that it running 32 bit. I'm not sure how to check which version 
of wxPython GRASS is running.

GRASS 7.3
Fails to launch with the following error:

ImportError: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so: no 
appropriate 64-bit architecture (see "man python" for running in 32-bit mode)

This is different from the error I get from trying to launch older versions 
with SIP enabled. But the SIP launch errors are misleading and differ on 
different systems sometimes.

I will re-disable SIP on the MacBook now and test again. But it would be good 
if someone else could test these with SIP enabled El Capitan to see if we are 
close to a useable version under Apples new (and soon to be updated) OS.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, 
http://csdc.asu.edu

On Sep 8, 2016, at 1:33 PM, Michael Barton 
> wrote:

I finally have a test Mac with El Capitan on it to see if it can compile GRASS. 
It looks like it does so with no problem. If anyone is able and would like to 
test it, I've compiled builds fresh from the SVN today of GRASS 7.0, 7.2, and 
7.3 and put them into a sharable

Re: [GRASS-dev] [GRASS GIS] #3151: raster digitizer crashes GUI in trunk

2016-09-13 Thread GRASS GIS

#3151: raster digitizer crashes GUI in trunk
--+-
  Reporter:  cmbarton |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by cmbarton):

 Forgot to add: compiled from trunk a few hours ago, version: 69469

--
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] #3151: raster digitizer crashes GUI in trunk

2016-09-13 Thread GRASS GIS

#3151: raster digitizer crashes GUI in trunk
-+-
 Reporter:  cmbarton |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.4.0
Component:  wxGUI|Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 When the raster digitizer is selected, it generates the error below and
 then locks ups the GUI so that you can't even quit it without killing
 Python from the OS.

 error:

 {{{

 Traceback (most recent call last):
   File "/Users/cmbarton/Dropbox (ASU)/GRASS_dropbox/GRASS-7.
 3.app/Contents/MacOS/gui/wxpython/mapdisp/toolbars.py", line
 255, in OnSelectTool

 self.parent.AddRDigit()
   File "/Users/cmbarton/Dropbox (ASU)/GRASS_dropbox/GRASS-7.
 3.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py", line
 1507, in AddRDigit

 toolSwitcher=self._toolSwitcher)
   File "/Users/cmbarton/Dropbox (ASU)/GRASS_dropbox/GRASS-7.
 3.app/Contents/MacOS/gui/wxpython/rdigit/toolbars.py", line
 56, in __init__

 self._previousMap = self._mapSelectionCombo.GetValue()
   File "/Users/cmbarton/Dropbox (ASU)/GRASS_dropbox/GRASS-7.
 3.app/Contents/MacOS/etc/python/wx/_controls.py", line 610,
 in GetValue

 return _controls_.ComboBox_GetValue(*args, **kwargs)
 wx._core
 .
 PyAssertionError
 :
 C++ assertion "IsValid(n)" failed at /BUILD/wxPython-
 src-2.8.12.1/src/mac/carbon/choice.cpp(242) in GetString():
 wxChoice::GetString(): invalid index

 }}}

 I don't know if this is just a Mac issue or more general.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] What is considered as valid location and valid mapset

2016-09-13 Thread Vaclav Petras

Hi all,

I wonder what is a valid location and what is a valid mapset. The
lib/init/grass.py file says:

def is_mapset_valid(full_mapset):
return os.access(os.path.join(full_mapset, "WIND"), os.R_OK)

def is_location_valid(gisdbase, location):
return os.access(os.path.join(gisdbase, location, "PERMANENT",
"DEFAULT_WIND"), os.F_OK)

This is what I've done based on the code which was there before
refactoring. I wonder if it is correct. If I need to switch to a mapset, I
want the region to be editable, so I need os.W_OK in that case. On the
other hand, is WIND file needed? Isn't it created automatically from
DEFAULT_WIND?

And further, is DEFAULT_WIND the right requirement for a valid PERMANENT
mapset? Are some PROJ_* files needed?

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

Re: [GRASS-dev] 7.0.5 release planning

2016-09-13 Thread Markus Neteler

On Tue, Sep 13, 2016 at 8:27 PM, Martin Landa  wrote:
> 44 days are counted from soft freeze, RC2 comes 14 days after RC1, so
>
> date -d '2016-08-27 +14 days' +"%Y-%m-%d"
> 2016-09-10

After re-reading the docs twice I also arrived there :)

So, yes, RC2 is due.

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

Re: [GRASS-dev] 7.0.5 release planning

2016-09-13 Thread Martin Landa

Hi,

2016-09-11 20:32 GMT+02:00 Markus Neteler :
> # release timestamp plus 44 days
> date -d '2016-08-27 +44 days' +"%Y-%m-%d"
> 2016-10-10

44 days are counted from soft freeze, RC2 comes 14 days after RC1, so

date -d '2016-08-27 +14 days' +"%Y-%m-%d"
2016-09-10

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fixed: GRASS-GIS/grass-ci#1550 (master - b7b90c4)

2016-09-13 Thread Travis CI

Build Update for GRASS-GIS/grass-ci
-

Build: #1550
Status: Fixed

Duration: 58 minutes and 48 seconds
Commit: b7b90c4 (master)
Author: Markus Metz
Message: v.category: fix r49413

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69469 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/3da472019169...b7b90c484013

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/159641003

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

Re: [GRASS-dev] grass 7.2 planning

2016-09-13 Thread Markus Neteler

On Wed, Sep 7, 2016 at 10:03 PM, Martin Landa  wrote:
> 2016-07-01 0:42 GMT+02:00 Martin Landa :
...
> I would suggest to
> postpone also milestone for G72 - hardfreezing + RC1 ~ 25/9.

Yes, 7.2.0RC1 around 25th of Sept might be good.

> Feel free
> to update blockers [1] (currently no tickets marked as blockers and
> critical). Thanks, Ma
>
> [1] 
> https://trac.osgeo.org/grass/query?priority=blocker=critical=assigned=new=reopened=7.2.0=type=priority

Let's assign a few :)  Open issue are here:

https://trac.osgeo.org/grass/query?status=new=assigned=reopened=7.2.0=type=priority

And please all update
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

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

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

2016-09-13 Thread Helmut Kudrnovsky

Markus Neteler wrote
> On Tue, Sep 13, 2016 at 4:52 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
>>>Thanks for your swift reply!
>>>
>>>In v.in.pygbif the import of pygbif is also done in a try-except
statement.
>>>
>>>Maybe the difference is that pyspatialite is installed on the build
system,
>> while pygbif is (naturally) not >(yet)?
> 
> Exactly...
> 
> root@osgeo6:/home/neteler# pip install pygbif
> bash: pip: command not found
> 
> How to get pip into this Debian box? (keeping the other 10 virtual
> sites on the system intact)
> Will be easy but I am more RPM oriented...

apt-get install python-pip?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-in-pygbif-addon-Manual-does-not-build-tp5285571p5285594.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

2016-09-13 Thread Vaclav Petras

On Tue, Sep 13, 2016 at 11:15 AM, Markus Neteler  wrote:

> root@osgeo6:/home/neteler# pip install pygbif
> bash: pip: command not found
>

I don't think it's necessary to install all addon dependencies on the build
server for Python where it is easy to work around it. Moreover the code is
useful also when user installs the module not having the dependencies (then
it installs, shows the GUI but gives a proper error message as opposed to
failing somewhere in between).
___
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

2016-09-13 Thread GRASS GIS

#2534: i.segment.hierarchical install error
---+
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  reopened
  Priority:  normal|  Milestone:  7.0.5
 Component:  Addons|Version:  svn-releasebranch70
Resolution:|   Keywords:  i.segment.hierarchical
   CPU:  x86-64|   Platform:  Linux
---+

Comment (by neteler):

 Maybe follow the style of

 grass-addons/grass7/imagery/i.fusion.hpf/Makefile

 which also comes with extra .py files but a very simple Makefile

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

2016-09-13 Thread Vaclav Petras

On Tue, Sep 13, 2016 at 10:52 AM, Helmut Kudrnovsky  wrote:

> the difference ist that in v.in.natura2000 it's done in def main(); in
> v.in.pygbif it's done before def main()
>

Right, this must be done only after calling grass.script.parser() function
but also in the right scope, so main is usually the right place for short
modules. There are other solutions with using another variable suitable for
more complicated modules (used e.g. in wxGUI), see m.printws:

https://trac.osgeo.org/grass/browser/grass-addons/grass7/misc/m.printws/m.printws.py?rev=69427#L177
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

2016-09-13 Thread Markus Neteler

On Tue, Sep 13, 2016 at 4:52 PM, Helmut Kudrnovsky  wrote:
>>Thanks for your swift reply!
>>
>>In v.in.pygbif the import of pygbif is also done in a try-except statement.
>>
>>Maybe the difference is that pyspatialite is installed on the build system,
> while pygbif is (naturally) not >(yet)?

Exactly...

root@osgeo6:/home/neteler# pip install pygbif
bash: pip: command not found

How to get pip into this Debian box? (keeping the other 10 virtual
sites on the system intact)
Will be easy but I am more RPM oriented...

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

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

2016-09-13 Thread Helmut Kudrnovsky

>Thanks for your swift reply!
>
>In v.in.pygbif the import of pygbif is also done in a try-except statement.
>
>Maybe the difference is that pyspatialite is installed on the build system,
while pygbif is (naturally) not >(yet)?

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.pygbif/v.in.pygbif.py#L179

179 try:
180 from pygbif import occurrences
181 from pygbif import species
182 except ImportError:
183 grass.fatal(_("Cannot import pygbif
(https://github.com/sckott/pygbif)"
184   " library."
185   " Please install it (pip install pygbif)"
186   " or ensure that it is on path"
187   " (use PYTHONPATH variable)."))
188 
189 
190 def main():

the difference ist that in v.in.natura2000 it's done in def main(); in
v.in.pygbif it's done before def main()



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-in-pygbif-addon-Manual-does-not-build-tp5285571p5285580.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

2016-09-13 Thread Helmut Kudrnovsky

SBL wrote
> Hei,
> 
> Does anyone have an idea why the v.in.pygbif addon-manual does not build?
> I managed to install it through g.extension and it works fine.
> The pygbif library is a dependency of v.in.pygbif. Therefore, I tried to
> align dependency handling (import) with the working solution in
> v.class.mlpy as another module with external dependencies. That obviously
> did not help, unfortunately.
> Are error logs from the automatic builds available online somewhere I
> could check?
> 
> I have some uncommitted modifications for the module I like to commit. It
> would be great to fix the built of the manual in one go.
> 
> Thanks for helping in advance.

the error is:

ERROR: Cannot import pygbif (https://github.com/sckott/pygbif) library.
   Please install it (pip install pygbif) or ensure that it is on path
   (use PYTHONPATH variable).

in an addon (1) I've used this way for testing if a python package is
available; the manual is building:

151 try:
152 import pyspatialite.dbapi2 as db
153 except:
154 grass.fatal( "pyspatialite is needed to run this
script.\n"
155 "source: https://pypi.python.org/pypi/pyspatialite
\n"
156 "Please activate/install it in your python stack.") 


try/except is done in   def main():

[1]
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.natura2000/v.in.natura2000.py#L151

HTH



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-in-pygbif-addon-Manual-does-not-build-tp5285571p5285574.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

2016-09-13 Thread Helmut Kudrnovsky

SBL wrote
> Hei,
> 
> Does anyone have an idea why the v.in.pygbif addon-manual does not build?
> I managed to install it through g.extension and it works fine.
> The pygbif library is a dependency of v.in.pygbif. Therefore, I tried to
> align dependency handling (import) with the working solution in
> v.class.mlpy as another module with external dependencies. That obviously
> did not help, unfortunately.
> Are error logs from the automatic builds available online somewhere I
> could check?
> 
> I have some uncommitted modifications for the module I like to commit. It
> would be great to fix the built of the manual in one go.
> 
> Thanks for helping in advance.

the logs from tha addon builds for winGRASS can be found here:

https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-in-pygbif-addon-Manual-does-not-build-tp5285571p5285572.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.in.pygbif addon: Manual does not build

2016-09-13 Thread Blumentrath, Stefan

Hei,

Does anyone have an idea why the v.in.pygbif addon-manual does not build? I 
managed to install it through g.extension and it works fine.
The pygbif library is a dependency of v.in.pygbif. Therefore, I tried to align 
dependency handling (import) with the working solution in v.class.mlpy as 
another module with external dependencies. That obviously did not help, 
unfortunately.
Are error logs from the automatic builds available online somewhere I could 
check?

I have some uncommitted modifications for the module I like to commit. It would 
be great to fix the built of the manual in one go.

Thanks for helping in advance.

Cheers
Stefan
___
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

2016-09-13 Thread GRASS GIS

#2534: i.segment.hierarchical install error
---+
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  reopened
  Priority:  normal|  Milestone:  7.0.5
 Component:  Addons|Version:  svn-releasebranch70
Resolution:|   Keywords:  i.segment.hierarchical
   CPU:  x86-64|   Platform:  Linux
---+

Comment (by mlennert):

 When I install i.segment.hierarchical using the url parameter, I get the
 following warning:


 {{{
 > g.extension i.segment.hierarchical url=SRC/GRASS/grass-
 addons/grass7/imagery/i.segment.hierarchical/
 Fetching  from
 
 (be patient)...
 Compiling...
 Makefile:17: warning: overriding recipe for target
 
'/tmp/grass7-mlennert-27332/tmpGjZYI8/i.segment.hierarchical/etc/i.segment.hierarchical'
 /home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/include/Make/ScriptRules.make:19: warning: ignoring old recipe for
 target
 
'/tmp/grass7-mlennert-27332/tmpGjZYI8/i.segment.hierarchical/etc/i.segment.hierarchical'
 Installing...
 Makefile:17: warning: overriding recipe for target
 
'/tmp/grass7-mlennert-27332/tmpGjZYI8/i.segment.hierarchical/etc/i.segment.hierarchical'
 /home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/include/Make/ScriptRules.make:19: warning: ignoring old recipe for
 target
 
'/tmp/grass7-mlennert-27332/tmpGjZYI8/i.segment.hierarchical/etc/i.segment.hierarchical'
 Installation of  successfully finished
 }}}

 It seems to me (but I'm no expert on Makefiles) that the Makefile is
 overly complicated. Could someone check on that ?

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] status of python script find_program() for addons in Windows ?

2016-09-13 Thread Moritz Lennert

I'm debugging the addon i.segment.stats with a colleague working on
windows. In the module, I call find_program() from the python scripting
library to check whether another addon (r.object.geometry) is
installed. However, the test seems to fail on Windows even if the addon
is installed.

There was some discussions related to this in #2008 [1], but not
specifically concerning windows, except for a comment by Hamish saying:

"works on linux with g.extension, not on Windows due to .bat wrapper
files and .py extension $0 != $0 fun with g.parser"

What is the status of this ? Should this work ?

Moritz



[1] http://trac.osgeo.org/grass/ticket/2008
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3151: raster digitizer crashes GUI in trunk

Re: [GRASS-dev] test of compiling GRASS Mac under El Capitan - very strange results

Re: [GRASS-dev] [GRASS GIS] #3151: raster digitizer crashes GUI in trunk

[GRASS-dev] [GRASS GIS] #3151: raster digitizer crashes GUI in trunk

[GRASS-dev] What is considered as valid location and valid mapset

Re: [GRASS-dev] 7.0.5 release planning

Re: [GRASS-dev] 7.0.5 release planning

[GRASS-dev] Fixed: GRASS-GIS/grass-ci#1550 (master - b7b90c4)

Re: [GRASS-dev] grass 7.2 planning

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Re: [GRASS-dev] [GRASS GIS] #2534: i.segment.hierarchical install error

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

[GRASS-dev] v.in.pygbif addon: Manual does not build

Re: [GRASS-dev] [GRASS GIS] #2534: i.segment.hierarchical install error

[GRASS-dev] status of python script find_program() for addons in Windows ?

20 matches

Site Navigation

Mail list logo

Footer information