Re: [GRASS-dev] [GRASS GIS] #2110: error registering maps outside mapset
#2110: error registering maps outside mapset --+- Reporter: lucadelu | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Temporal | Version: svn-trunk Keywords: register |Platform: All Cpu: All | --+- Comment(by huhabla): I have discussed this topic off the list with Luca and investigated the problem in more detail. Luca suggested to register only maps from foreign mapsets that are not already in the temporal database and that have a timetsamp attached with r.timestamp, so that there is no need anymore to modify the timestamp in the spatial database metadata. Revision r58084 allows now to use existing time stamps in the registration process that were set with (r|r3|v).timestamp. This works only if the map is not already registered in the temporal database. However, timestamps will be rewritten in the spatial database metadata, since the registration method is generic and does not care where the timestamps originated from. A more fundamental problem that occurs when registering maps from foreign mapsets is the following: Space time datasets are defined by the spatio-temporal extents and the metadata of their maps. Hence, if you modify a map, then you will modify the space time datasets in which this map is registered. That's one reason why space time datasets are mapset specific. Consider to have a work-mapset A and foreign mapset B. Now you register maps from mapset B in a space time dataset of mapset A. Now the owner of mapset B creates several space time datasets in his mapset and modifies some maps that are registered in the space time dataset of mapset A using the temporal framework (t.snap, t.shift, ...). The metadata modification of maps in mapset B will result in the modification of the space time dataset in mapset A. Hence the owner of mapset B can compromise the space time datasets of the owner of mapset A. This will violate the GRASS permission system, hence, its not allowed will be prevented by the temporal framework. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2110#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2117: GRASS 7: NVIZ: Transparency error for constant surface in
#2117: GRASS 7: NVIZ: Transparency error for constant surface in --+- Reporter: richardc | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: NVIZ |Platform: Linux Cpu: x86-32| --+- Hi, I notice that setting the constant surface transparency to any value other that zero, causes the constant surface to disappear above a raster layer. The surface remains visible surrounding the image. Only if the constant surface is given a transparency of zero (i.e., 100% opaque) is it possible to position above a raster image. GRASS 7.0.svn (version 57721) Linux Mint 13 (ubuntu precise) Richard -- Ticket URL: https://trac.osgeo.org/grass/ticket/2117 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
Hi, On Tue, Oct 22, 2013 at 1:51 AM, Michael Barton michael.bar...@asu.eduwrote: Here is a bit more. When I try to send an extension to a directory where I do have permissions without using sudo, g.extension on GRASS 7 still insists on putting it into the GRASS app. GRASS 7.0.svn (nc_spm_08):~ g.extension extension=r.stream.order prefix=/Users/cmbarton/Library/GRASS/7.0/Modules Fetching r.stream.order from GRASS-Addons SVN (be patient)... Compiling... mkdir: /Applications/GRASS/bin: Permission denied make: *** [/Applications/GRASS/bin] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. I don't have any problem with installing extensions on Mac, I've just tried installing both C and Python extensions. My GRASS_ADDON_BASE is /Users/akratoc/Library/GRASS/7.0/Modules and GRASS_ADDON_PATH is empty. Tell me if there is something to test. Anna Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change 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 Oct 21, 2013, at 10:08 PM, Michael Barton michael.bar...@asu.edu wrote: So responding to a query from a colleague I just tried g.extension in GRASS 7 that I compiled a few hours ago. Note that I'm running this from the terminal and yes GRASS_ADDON_PATH is set properly. $GRASS_ADDON_PATH bash: :/Library/GRASS/7.0/Modules/bin I start running g.extensions with just the normal default settings g.extension extension=r.stream.order Fetching r.stream.order from GRASS-Addons SVN (be patient)... Compiling... mkdir: /Applications/GRASS/bin: Permission denied make: *** [/Applications/GRASS/bin] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. First of all, this is wrong. Instead of putting this into the default, GRASS_ADDON_PATH, it is trying to create a new bin directory inside the GRASS app. GRASS 7.0.svn (nc_spm_08):~ sudo g.extension extension=r.stream.order dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid You must be in GRASS GIS to run this program. Now it won't let me use sudo to run g.extension. So I try to force g.extension to use the proper directory specified by GRASS_ADDON_PATH GRASS 7.0.svn (nc_spm_08):~ g.extension extension=r.stream.order prefix=/Library/GRASS/7.0/Modules/bin ERROR: Unable to create '/Library/GRASS/7.0/Modules/bin/bin': [Errno 13] Permission denied: '/Library/GRASS/7.0/Modules/bin/bin' Again permission denied. sudo g.extension extension=r.stream.order prefix=/Library/GRASS/7.0/Modules/bin dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid You must be in GRASS GIS to run this program. And again, I get a bogus message when I use sudo to override the permissions issue. So there is no way this can work AFAICT. Maybe it work in GRASS 6. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change 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 ___ 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] future after d.frame?
(picking up an old topic)
On Wed, Oct 8, 2008 at 3:05 PM, Glynn Clements gl...@gclements.plus.com wrote:
Yann Chemin wrote:
attached is a composition that should be dumped as
image file at each new temporal increment,
in order to become an animation eventually.
As d.frame is gone in GRASS 7,
I'd like to know if anyone has an idea on how to make
this happen within the new environmental conditions?
For d.rast.leg (scripts/d.rast.leg/d.rast.leg.py in 7.0), I used the
following function as a drop-in replacement for the d.frame command:
def make_frame(f, b, t, l, r):
(ft, fb, fl, fr) = f
t /= 100.0
b /= 100.0
l /= 100.0
r /= 100.0
rt = fb + t * (ft - fb)
rb = fb + b * (ft - fb)
rl = fl + l * (fr - fl)
rr = fl + r * (fr - fl)
s = '%f,%f,%f,%f' % (rt, rb, rl, rr)
os.environ['GRASS_FRAME'] = s
This converts the coordinates used by d.frame (percentages, with the
origin at the lower left) to the coordinates used by the GRASS_FRAME
variable (display units, typically pixels (raster) or points
(PostScript etc), with the origin at the upper left).
The first argument, f, is the parent frame, which was obtained with:
s = grass.read_command('d.info', flags = 'f')
f = tuple([float(x) for x in s.split()[1:5]])
This allows the output to nest inside an existing frame rather than
forcibly resetting to full screen (the notion of resetting doesn't
fit well with EPS or SVG).
Also, to compose multiple d.* commands into a single image when using
immediate rendering, you need to set GRASS_PNG_READ=TRUE. Otherwise,
each d.* command will erase the image (raster formats, e.g. PNG) or
truncate the file (vector formats, e.g. PS/PDF/SVG).
One feature which the display architecture currently lacks is the
ability to create multiple frames (in the sense of animation) from a
single command. Actually, you can almost do this with the PostScript
driver; call R_erase() between each frame, and manually change the
ERASE function in the output to use showpage instead of erasepage.
It would be great to have something corresponding to d.frame also in GRASS 7.
And,or, have not only GRASS_FRAME but also GRASS_FRAME_PERCENT
in order to easier split the wx monitor from command line.
Any thoughts? Or is there anything more recent I am not aware of?
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2108: default temporal database
#2108: default temporal database -+-- Reporter: lucadelu | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Temporal | Version: svn-trunk Keywords: connect |Platform: All Cpu: Unspecified | -+-- Comment(by huhabla): The reason to put the temporal database by default in the PERMANENT mapset is an ongoing discussion in ticket #2110. However, the temporal database should not be placed in the same folder as the vector attribute database [1]. [1] http://lists.osgeo.org/pipermail/grass-dev/2012-December/061138.html -- Ticket URL: http://trac.osgeo.org/grass/ticket/2108#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
Hi Anna, It works fine for me in GRASS 6.4, but does not work in GRASS 7. I get somewhat different errors on different machines. On both tested so far, GRASS_ADDON_BASE is correctly set: GRASS 7.0.svn (nc_spm_08):~ $GRASS_ADDON_BASE bash: /Users/cmbarton/Library/GRASS/7.0/Modules: is a directory On one machine, GRASS_ADDON_PATH is also set. It is not set on the other one. This is odd of course because AFAICT, both are set in the Mac startup scripts. On one machine (the one with GRASS_ADDON_PATH set), I get the errors reported below. On the other machine, I get the following different set of errors: GRASS 7.0.svn (nc_spm_08):~ g.extension extension=r.fuzzy Fetching r.fuzzy from GRASS-Addons SVN (be patient)... Compiling... main.c: In function 'main': main.c:152: warning: format not a string literal and no format arguments main.c:156: warning: format not a string literal and no format arguments main.c: In function 'main': main.c:152: warning: format not a string literal and no format arguments main.c:156: warning: format not a string literal and no format arguments ERROR: MAPSET PERMANENT - permission denied make[1]: *** [r.fuzzy.set.tmp.html] Error 1 ERROR: MAPSET PERMANENT - permission denied make[1]: *** [r.fuzzy.logic.tmp.html] Error 1 main.c: In function 'main': main.c:151: warning: format not a string literal and no format arguments main.c:155: warning: format not a string literal and no format arguments main.c:157: warning: format not a string literal and no format arguments main.c: In function 'main': main.c:151: warning: format not a string literal and no format arguments main.c:155: warning: format not a string literal and no format arguments main.c:157: warning: format not a string literal and no format arguments map_parser.c: In function 'parse_map_file': map_parser.c:92: warning: format not a string literal and no format arguments map_parser.c: In function 'parse_map_file': map_parser.c:92: warning: format not a string literal and no format arguments rule_parser.c: In function 'parse_rules': rule_parser.c:132: warning: format not a string literal and no format arguments rule_parser.c: In function 'parse_rules': rule_parser.c:132: warning: format not a string literal and no format arguments ERROR: MAPSET PERMANENT - permission denied make[1]: *** [r.fuzzy.system.tmp.html] Error 1 Installing... make: *** No rule to make target `install'. Stop. WARNING: Installation failed, sorry. Please check above error messages. Bulent gets an entirely different set of errors in GRASS 6.5 Fetching r.stream.order from GRASS-Addons SVN (be patient)... Ar.stream.order/main.c Ar.stream.order/description.html Ar.stream.order/global.h Ar.stream.order/io.c Ar.stream.order/r_stream_order_orders.png Ar.stream.order/order.c Ar.stream.order/Makefile U r.stream.order Checked out revision 58089. Compiling r.stream.order... /Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/MacOS/include/Make/Grass.make:423: warning: overriding commands for target `/Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/bin' /Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/MacOS/include/Make/Grass.make:414: warning: ignoring old commands for target `/Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/bin' mkdir -p /Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/bin mkdir -p /Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/include/grass mkdir -p /Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/etc mkdir -p /Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/driver mkdir -p /Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/driver/db mkdir -p /Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/fonts test -d OBJ.x86_64-apple-darwin12.4.0 || mkdir -p OBJ.x86_64-apple-darwin12.4.0 gcc '-I/Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/MacOS/include' '-I/Users/bulentarikan/Library/GRASS/6.4/Modules/bin/include' '-I/Users/bulentarikan/grassdata/spearfish60/PERMANENT/.tmp/bulent-arikans-macbook-pro.local/6007.0/dist.x86_64-apple-darwin12/include' -g -O2 -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -I/Library/Frameworks/GDAL.framework/Versions/1.9/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grassmods\ '-I/Applications/GRASS_6.4.3/GRASS-6.4.3.app/Contents/MacOS/include' '-I/Users/bulentarikan/Library/GRASS/6.4/Modules/bin/include'
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
On Tue, Oct 22, 2013 at 9:28 PM, Michael Barton michael.bar...@asu.edu wrote: ... On one machine (the one with GRASS_ADDON_PATH set), I get the errors reported below. On the other machine, I get the following different set of errors: GRASS 7.0.svn (nc_spm_08):~ g.extension extension=r.fuzzy Fetching r.fuzzy from GRASS-Addons SVN (be patient)... Compiling... main.c: In function 'main': main.c:152: warning: format not a string literal and no format arguments main.c:156: warning: format not a string literal and no format arguments main.c: In function 'main': main.c:152: warning: format not a string literal and no format arguments main.c:156: warning: format not a string literal and no format arguments ERROR: MAPSET PERMANENT - permission denied ...here is the (general, also on Linux) bug: g.extension miserably fails when the GRASS session user is not the owner of PERMANENT as often the case in multi-user environments (shared grassdata directory). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] test of skeleton functionality in v.voronoi
Moritz Lennert wrote: Markus M, I know this is still very fresh, but I was excited about seeing your addition to v.voronoi allowing to calculate skeletons and longest lines for areas. Amongst others, this could be useful for calculating some shape parameters of polygons for region-based classification. So, just a quick feedback. I ran the module on the entire urbanarea map, in order to test scalability. The results are really nice and I haven't found evident errors, yet. I found evident errors in some other test data. The voronoi algorithm suffers from problems related to floating point representation errors, also sometimes apparent when calculating voronoi diagrams for areas. It takes quite a while, though: Yes, because it is a brute force approach. The problem of finding the center line for areas, or an area skeleton from which the center line can be extracted, must have been solved previously. A literature research might help. On first glance, I did not find a solution, though. Only for straight skeletons which are not suitable to extract a center line. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2105: Missing guidelines for testing
#2105: Missing guidelines for testing
+---
Reporter: wenzeslaus | Owner: grass-dev@…
Type: task| Status: new
Priority: normal | Milestone: 7.0.0
Component: Tests | Version: svn-trunk
Keywords: testing, tests |Platform: Unspecified
Cpu: Unspecified |
+---
Comment(by huhabla):
Replying to [comment:3 wenzeslaus]:
Replying to [comment:1 huhabla]:
Replying to [ticket:2105 wenzeslaus]:
There is a page about the test framework we wish to have:
* http://grasswiki.osgeo.org/wiki/Test_Suite
But since it does not exists the page creates just confusion.
This page describes in very detail how the testsuite can be
implemented for modules and libraries. Python doctests and how to
implement automated testing in the make system are not covered. It
includes a guideline howto implement tests for modules based on shell
scripts. Hence it is unclear to me how this leads to confusion?
However, i am all for a complete new test suite design. I would
suggest to implement all module and Python library tests in Python, so
that these tests can be executed independently from the OS or the used
command line interpreter, with or without the make system.
For me it seems that it is not worth to build our own tests system and
bash-like language interpreter (as proposed on the wiki page). I vote for
writing module tests directly in Python. From my experience I was writing
module test in bash and it is easier at the beginning but if you want to
do something more special than calling a module and check the return code
bash-like language is not sufficient. Moreover, we want cross platform
tests and I think we don't want to implement bash-like syntax parser and
interpreter for variables, if-statements, for loops in Python, although it
sounds interesting. When writing directly in Python, the tests dependents
on GRASS or Python process calling capabilities but they would depend
anyway if the interpreter would be build. The only advantage in writing in
bash-like syntax is that it can run as bash/sh... script, but Python
script is great too, isn't it?
It is. Writing module tests directly in Python will give us much more
flexibility. But we have to implement a GRASS specific Python test
framework to test and validate GRASS modules. This framework should
provide classes and functions to test different module configurations and
check their output with reference data automatically. The suggested
framework in [1] is still valid in several aspects (location creation,
cleaning, data check). I would suggest to use the PyUnit framework for
module testing. The PyGRASS Module interface should be used to configure
module runs. Configured modules should be run by specific test functions
that check the module output and stdout/stderr with reference data that is
located in the modules test directory. It should be possible to configure
the test suite so that all modules are executed in a virtual environment
like valgrind for memory leak checks.
Here an PyUnit example of a r.info test:
{{{
#!/usr/bin/python
import unittest
import grass.pygrass.modules as pymod
import grass.test_suite as test_suite
class r_info_test(unittest.TestCase):
@classmethod
def setUpClass(cls):
! Set up the test mapset and create test data for all tests
# Create the temporary test mapset and set up the test environment
test_suite.init()
# Create test data for each test
m = pymod.Module(r.mapcalc, expr=test = 1, run_=False)
# We simply run this module, if the module run fails,
# the whole test will be aborted
test_suite.run_module(module=m)
def test_flag_g(self):
! Test to validate the output of r.info using flag g
# Configure a r.info test
m = pymod.Module(r.info, map=test, flags=g, run_=False)
# Run the test using the test suite functionality and check
# the output on stdout with reference data that is located in the
# r.info test directory
# This function will call an exception if the module run fails
# or if the output in comparison to the reference data is
incorrect
test_suite.test_module(module=m, check=stdout,
reference=r_info_g.ref)
def test_flag_e(self):
! Test to validate the output of r.info using flag e
# Configure a r.info test
m = pymod.Module(r.info, map=test, flags=e, run_=False)
# Run the test using the test suite functionality and check
# the output on stdout with reference data that is located in the
# r.info test
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
Why is g.extension even trying to put something into PERMANENT (in what location???) anyway? It is supposed to be installing into $GRASS_ADDON_BASE Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Oct 22, 2013, at 1:28 PM, Markus Neteler nete...@osgeo.org wrote: On Tue, Oct 22, 2013 at 9:28 PM, Michael Barton michael.bar...@asu.edu wrote: ... On one machine (the one with GRASS_ADDON_PATH set), I get the errors reported below. On the other machine, I get the following different set of errors: GRASS 7.0.svn (nc_spm_08):~ g.extension extension=r.fuzzy Fetching r.fuzzy from GRASS-Addons SVN (be patient)... Compiling... main.c: In function 'main': main.c:152: warning: format not a string literal and no format arguments main.c:156: warning: format not a string literal and no format arguments main.c: In function 'main': main.c:152: warning: format not a string literal and no format arguments main.c:156: warning: format not a string literal and no format arguments ERROR: MAPSET PERMANENT - permission denied ...here is the (general, also on Linux) bug: g.extension miserably fails when the GRASS session user is not the owner of PERMANENT as often the case in multi-user environments (shared grassdata directory). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
Michael, it tries to run the virtual session therein to generate the header of the manual. So it wants to use PERMANENT rather than store anything there. Perhaps there is a switch needed/existing to not test who the owner of the mapset is. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
Sounds like a plan. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Oct 22, 2013, at 3:05 PM, Markus Neteler nete...@osgeo.org wrote: Michael, it tries to run the virtual session therein to generate the header of the manual. So it wants to use PERMANENT rather than store anything there. Perhaps there is a switch needed/existing to not test who the owner of the mapset is. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
In Makefiles there is way how to run something within a GRASS session without requiring the current session. It is used for building documentation and for example in gui/wxpython Makefile: $(call run_grass,$(PYTHON) $ manager $@) which uses this from include/Make/Rules.make: GRASS_PYTHONPATH := $(call mkpath,$(GISBASE)/etc/python,$$PYTHONPATH) GRASS_PYTHONPATH := $(call mkpath,$(ARCH_DISTDIR)/etc/python,$(GRASS_PYTHONPATH)) run_grass = \ GISRC=$(RUN_GISRC) \ GISBASE=$(RUN_GISBASE) \ PATH=$(ARCH_DISTDIR)/bin:$(GISBASE)/bin:$(GISBASE)/scripts:$$PATH \ PYTHONPATH=$(GRASS_PYTHONPATH) \ $(LD_LIBRARY_PATH_VAR)=$(BIN):$(ARCH_LIBDIR):$(BASE_LIBDIR):$($(LD_LIBRARY_PATH_VAR)) \ LC_ALL=C \ $(1) This is all I know now. I cannot look at it now more but hopefully this information will be useful. On Tue, Oct 22, 2013 at 6:16 PM, Michael Barton michael.bar...@asu.eduwrote: Sounds like a plan. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Oct 22, 2013, at 3:05 PM, Markus Neteler nete...@osgeo.org wrote: Michael, it tries to run the virtual session therein to generate the header of the manual. So it wants to use PERMANENT rather than store anything there. Perhaps there is a switch needed/existing to not test who the owner of the mapset is. Markus ___ 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] #2116: r.kappa: call to r.stats fails if spaces in path
#2116: r.kappa: call to r.stats fails if spaces in path -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Default | Version: svn-releasebranch64 Keywords: kappa path |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by hamish): Replying to [ticket:2116 mlennert]: The attached patch solves the problem for me, but I imagine that there is a more elegant solution. right, we should use G_vspawn_ex() instead of system(). It's already done for r.kappa in G7; just needs to be backported tested. see r40146 and r44964. In addition, as a minor style tweak/simplification I'd suggest to consider using the r.stats output= file option instead of a shell redirect/dealing with the stdout pipe. regards, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2116#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
Forgot to ask, if anyone as an idea as to *which* PERMANENT it is looking for. I'm the owner of all the directories in by GISDatabase folder. So where is it finding a PERMANENT that I don't have permissions for? Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Oct 22, 2013, at 3:05 PM, Markus Neteler nete...@osgeo.org wrote: Michael, it tries to run the virtual session therein to generate the header of the manual. So it wants to use PERMANENT rather than store anything there. Perhaps there is a switch needed/existing to not test who the owner of the mapset is. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2116: r.kappa: call to r.stats fails if spaces in path
#2116: r.kappa: call to r.stats fails if spaces in path -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Default | Version: svn-releasebranch64 Keywords: kappa path |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by hamish): on the other hand, for choosing the path of least change in the stable branch your patch might be the way to go. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2116#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac
On Wed, Oct 23, 2013 at 1:36 AM, Michael Barton michael.bar...@asu.edu wrote: Forgot to ask, if anyone as an idea as to *which* PERMANENT it is looking for. I'm the owner of all the directories in by GISDatabase folder. So where is it finding a PERMANENT that I don't have permissions for? IMHO the only way is to add some debug statements and print the variable contents. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
