Re: [GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

On Tue, Oct 6, 2015 at 12:26 PM, Glynn Clements wrote: > > Markus Neteler wrote: > > > >> Sorry for being -pedantic but I don't think we should leave the code > > >> messy. > > > > > > +1 > > > > Then it needs to be removed everywhere here: > > > > cd grass-addons > >

Re: [GRASS-dev] I've tripled GRASS's I/O speed

iles (9%) were successful and 115 files (91%) failed. > > GRASS 7.1.svn > (nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > > > I'd really like to work on these unit tests. Any ideas as to where I'm > going wrong? I feel like I've exhausted the vario

Re: [GRASS-dev] I've tripled GRASS's I/O speed

On Mon, Oct 5, 2015 at 5:07 PM, Seth Price wrote: > > --location /usr/local/grass/nc_basic_spm_grass7/ python -m grass.gunittest.main --location locname --location-type nc where locname is a name of location in current GRASS GIS data(base) directory (GISDBASE) and nc is a

Re: [GRASS-dev] I've tripled GRASS's I/O speed

e test failed. This is the result you will get today in best case (on 64bit): http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-10-05-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html Was this result with or without your changes? > > On Mon, Oct 5, 2015 at 2:13 PM, Vac

Re: [GRASS-dev] I've tripled GRASS's I/O speed

On Mon, Oct 5, 2015 at 6:41 PM, Seth Price wrote: > The tests are without my changes on 64 bit Mac v10.10.5, Mac Pro with 64 > GB of RAM. Good, I hope now you are ready to run tests with your changes as well. BTW, great that you run tests on Mac!

Re: [GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

On Mon, Oct 5, 2015 at 3:44 AM, Martin Landa wrote: > > Hi, > > 2015-10-05 9:41 GMT+02:00 Martin Landa : > > compilation was simply failing on build server (Debian stable): It is working on Ubuntu and probably Fedora as well. Perhaps it is a local

Re: [GRASS-dev] wx.metadata installation issues & pygrass set_path() question

On Sun, Oct 4, 2015 at 8:30 AM, Martin Landa wrote: > when trying to fix all compilation and installation issues I replaced > get_lib_path() by set_path() [1]. These functions are not used in > GRASS core codebase. Their usage is not clear to me. The replacement was

Re: [GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

On Sun, Oct 4, 2015 at 9:08 AM, wrote: > > Author: neteler > Date: 2015-10-04 06:08:45 -0700 (Sun, 04 Oct 2015) > New Revision: 66413 > > Modified: >grass-addons/grass7/vector/v.kriging/local_proto.h > Log: > v.kriging: add missing la.h header > > @@ -13,6 +13,7 @@ >

Re: [GRASS-dev] I've tripled GRASS's I/O speed

On Fri, Oct 2, 2015 at 7:12 PM, Seth Price wrote: > I imagine the best test will need pretty low level access to the cellhd > structure to look at the compression flags. Is that what you mean? Or would > a better way include looking at the output of `r.compress`? > Yes, best

Re: [GRASS-dev] I've tripled GRASS's I/O speed

On Sat, Oct 3, 2015 at 12:19 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Sat, Oct 3, 2015 at 5:05 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > On Fri, Oct 2, 2015 at 7:12 PM, Seth Price <s...@planet.com> wrote: > ... > > I suggest to start

[GRASS-dev] Failing tests overview for September 2015

t.rast.accumulate: created file differ from the reference Needs investigation. ./temporal/t.rast.accumulate/testsuite/test.t.rast.accumulate.sh

Re: [GRASS-dev] Planning of 7.0.2 release

On Sat, Oct 3, 2015 at 12:02 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > On 03/10/15 11:01, Martin Landa wrote: >> >> Hi, >> >> 2015-10-03 10:45 GMT+02:00 Markus Neteler : >> >>> - r64404 - libpython: move cmd list <-> tuple from wxGUI: martinl >>> Date: Feb 2,

Re: [GRASS-dev] I've tripled GRASS's I/O speed

On Fri, Oct 2, 2015 at 12:49 PM, Seth Price wrote: > ..by adding the option of a few different compression schemes, including > LZ4. I've had the ticket open for a week now with no responses. I'd love to > get it incorporated into trunk. For more info, see here: >

Re: [GRASS-dev] installing v.kriging addon fails

On Thu, Oct 1, 2015 at 9:29 AM, Markus Neteler wrote: > > > In file included from geostat.c:1:0: > > > > local_proto.h:72:3: error: unknown type name ‘mat_struct’ > > > >mat_struct *trend; > > > >^ > > ok - next check: > > > cd /where/your/grass/is/lib > > ldd

Re: [GRASS-dev] Write array to (point) attribute table

On Thu, Oct 1, 2015 at 11:28 AM, Paulo van Breugel wrote: > with VectorTopo('testB', mode='rw') as vectormap: At the and it makes sense. 'w' removes the vectors and starts over. 'rw' keep the file but ones it for writing. Perhaps 'a' would make better sense in this

Re: [GRASS-dev] no addons metadata

On Thu, Oct 1, 2015 at 10:42 AM, Paulo van Breugel wrote: > The same problem as reported earlier is back it seems, no addons metadata > available. This was a problem for 7.1 I think? > > WARNING: Unable to parse > >

[GRASS-dev] v.decimate: point cloud decimation of native vector maps

Hi all, I have added v.decimate to trunk in r66387 [1]. The current version can do count-based decimation in the same way as the current v.in.lidar module [2]. Additionally, a grid-based decimation is supported. The grid is 2D and the points are preserved based on z, category or count (within one

[GRASS-dev] Using layers and categories for something else than ID and class

[Was: v.in.lidar: store return or class as category] Changing the subject as this is more general than just v.in.lidar. On Wed, Sep 30, 2015 at 4:20 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > On 29/09/15 19:49, Vaclav Petras wrote: > >> >> On Tue,

Re: [GRASS-dev] v.in.lidar: store return or class as category

On Tue, Sep 29, 2015 at 9:52 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > On 29/09/15 15:26, Newcomb, Doug wrote: > >> As an example, the new North Carolina data set ( 2014 +) , the LiDAR >> classes above 12 are being used for roads, (13) and bridges (14) . >> > > Maybe if we go

[GRASS-dev] Vect_open_old versus Vect_open_old2 and layer/field constraint

Hi all, what is the difference between Vect_open_old() and Vect_open_old2()? Vect_open_old() doc says "this function is replaced by Vect_open_old2() to handle also direct OGR support." Vect_open_old2() has a parameter "layer name (OGR layer for direct OGR access)". However, it is not clear to

Re: [GRASS-dev] Vect_open_old versus Vect_open_old2 and layer/field constraint

On Mon, Sep 28, 2015 at 11:22 AM, Martin Landa <landa.mar...@gmail.com> wrote: > > Hi, > > 2015-09-28 16:56 GMT+02:00 Vaclav Petras <wenzesl...@gmail.com>: > > [...] > > > what is the meaning for native vector maps? Does this limit the layer as in > >

Re: [GRASS-dev] v.in.lidar: store return or class as category

On Sat, Sep 26, 2015 at 8:40 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > Dear all, > > in r66343 I've added the option to store return or class as category. This > is much faster than storing them as attributes. Also, the further > processing will be faster supposin

[GRASS-dev] v.in.lidar: store return or class as category

Dear all, in r66343 I've added the option to store return or class as category. This is much faster than storing them as attributes. Also, the further processing will be faster supposing that the subsequent workflow can use categories in the same way as attributes. Return and class can be stored

Re: [GRASS-dev] [GRASS-SVN] r61363 - grass/branches/releasebranch_7_0/raster/r.in.gdal

Hi Markus, On Wed, Jul 23, 2014 at 5:43 AM, wrote: > Author: neteler > Date: 2014-07-23 02:43:05 -0700 (Wed, 23 Jul 2014) > New Revision: 61363 > > Modified: >grass/branches/releasebranch_7_0/raster/r.in.gdal/main.c > Log: > r.in.gdal: GDALGetCacheMax() is limited to

Re: [GRASS-dev] Collecting ideas for training manual for GRASS GIS

On Tue, Sep 22, 2015 at 8:40 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > Ideally, the things should be in the OSGeo Educational Content Inventory >>> and >>> we should be adding the stable or valuable things there as we are >>> collecting >>> them. >>> >> > +1 (but let's create it

Re: [GRASS-dev] TGRASS: mapset management question

On Mon, Sep 21, 2015 at 5:06 PM, Markus Neteler wrote: > > Is there a way to add an extra condition within the case 0. Or do we > need a new G_mapset_permissions3() being less picky about ownership? I'm not completely following the discussion but if there is a need to test

Re: [GRASS-dev] Planning of 7.0.2 release

On Sun, Sep 20, 2015 at 2:07 PM, Markus Neteler wrote: > r64877 - > grass/trunk/raster/r.patch: call Rast_cell_size just once, not for every > cell I would be more comfortable backporting it if there would be at least a simple

Re: [GRASS-dev] GRASS wiki down

On Sat, Sep 19, 2015 at 10:31 AM, Markus Neteler <nete...@osgeo.org> wrote: > On Sat, Sep 19, 2015 at 4:25 PM, Vaclav Petras <wenzesl...@gmail.com> > wrote: > > Hi, > > > > GRASS wiki is down with > > > > MediaWiki 1.25.2 > > LocalSettings

[GRASS-dev] GRASS wiki down

Hi, GRASS wiki is down with MediaWiki 1.25.2 LocalSettings.php not readable. Please correct file permissions and try again. Thanks, Vaclav https://grasswiki.osgeo.org/ ___ grass-dev mailing list grass-dev@lists.osgeo.org

Re: [GRASS-dev] Some wxPython 3 issues

On Thu, Sep 17, 2015 at 6:42 AM, Markus Neteler wrote: > > - wxpython3_textfield_bug.jpg: this is in the bulk raster import, the > change of name during import is not readable (the text field is of one > pixel height, see red ellipsis in the screenshot What do you think is the

Re: [GRASS-dev] r.in.lidar not running in Mac binaries for 7.1

On Wed, Sep 16, 2015 at 9:41 AM, William Kyngesburye wrote: > So the question is if GRASS supports one or the other library or both, or > does it also use the tools in a script so it doesn't matter. GRASS uses only the library, not the tools, and is designed/tested/known

Re: [GRASS-dev] Display library documentation?

On Tue, Sep 15, 2015 at 6:06 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > On 14/09/15 15:53, Vaclav Petras wrote: > >> Hi, >> >> is there some documentation on how to use the display library, i.e. how >> to write a d.* module? &g

[GRASS-dev] r.in.lidar not running in Mac binaries for 7.1

[Was: Re: [GRASS-dev] New Mac binaries uploaded] Hi Michael, On Mon, Aug 24, 2015 at 11:45 PM, Michael Barton wrote: > That would be wonderful. I sort of got that impression too. But will the > GRASS lidar tools be able to use LASlib instead of Liblas? > the binary in

Re: [GRASS-dev] TGRASS: mapset management question

On Tue, Sep 15, 2015 at 3:06 AM, Sören Gebbert wrote: > > However, the warning about mapset access is generated in > "lib/temporal/lib/connect.c" which checks the output of > G_mapset_permissions2. I will remove this check > since only the owner is checked, not

[GRASS-dev] Display library documentation?

Hi, is there some documentation on how to use the display library, i.e. how to write a d.* module? I've tried reading d.vect code but I miss the general rules and concepts like how to set color or which coordinates should be used when as well as information which functions should be used in which

Re: [GRASS-dev] TGRASS: mapset management question

On Mon, Sep 14, 2015 at 4:53 PM, Markus Neteler wrote: > > > If the point of using that env var is to simply suppress the warning > in the upper case, then maybe G_suppress_warnings(1) is better? > Something like > > Index: lib/python/temporal/c_libraries_interface.py >

[GRASS-dev] v.in.lidar: decimation (skip, preserve, offset, limit)

Hi all, in r66181 I've added a simple decimation to v.in.lidar. It reduces number of imported points by skipping or limiting number of imported points. Here are the new options: skip Do not import every n-th point. For example, 5 will import 80 percent of points. If not specified, all points are

Re: [GRASS-dev] addon mismatch

On Fri, Sep 11, 2015 at 1:37 PM, Paulo van Breugel <p.vanbreu...@gmail.com> wrote: > On 11-09-15 19:31, Vaclav Petras wrote: > > > On Fri, Sep 11, 2015 at 1:13 PM, Paulo van Breugel < > <p.vanbreu...@gmail.com>p.vanbreu...@gmail.com> wrote: > >> >&g

Re: [GRASS-dev] installing v.mapcalc fails

On Fri, Sep 11, 2015 at 4:56 AM, Paulo van Breugel wrote: > I am trying to install v.mapcalc through g.extension, but I am getting the > following error message: > > Fetching from GRASS GIS Addons repository (be patient)... > Have you tried t.vect.algebra module in

Re: [GRASS-dev] addon mismatch

On Fri, Sep 11, 2015 at 1:13 PM, Paulo van Breugel wrote: > > PS: no idea what "WARNING: No addons metadata available. Addons > metadata file not updated." means > > No clue either, but maybe the reason it doesn't show in the g.extension > GUI? Well, I did pretty heavy

Re: [GRASS-dev] addon mismatch

On Thu, Sep 10, 2015 at 10:15 AM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > > > On Thu, Sep 10, 2015 at 10:01 AM, Helmut Kudrnovsky <hel...@web.de> wrote: > > > > hi, > > > > in https://trac.osgeo.org/grass/browser/grass-addons/grass7/

Re: [GRASS-dev] r.resample.rst behavior does not match manual

On Sun, Sep 6, 2015 at 1:01 PM, Michael Barton wrote: > Thanks for all the responses and fixes. I should have some time in the > next week to look at these. > Please see also my comments in "r.in.lidar: height aboveground" where I say: r.resamp.rst should honor the

Re: [GRASS-dev] addon mismatch

On Thu, Sep 10, 2015 at 10:01 AM, Helmut Kudrnovsky wrote: > > hi, > > in https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector there is > > e.g. the addon v.in.gbif > > https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.gbif > > it seems the addon is

Re: [GRASS-dev] r.in.lidar: height above ground

.osgeo.org/grass/changeset/66151 https://trac.osgeo.org/grass/changeset/66094 On Thu, Sep 3, 2015 at 10:49 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > Hi, > > in r66094, I've added base raster map to r.in.lidar. When provided, > r.in.lidar with subtract its values from the p

Re: [GRASS-dev] Graphical index in manual

On Sun, Sep 6, 2015 at 5:03 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > > 2) wxGUI introduction points to non-existing wxguiintro.html > > Similar issues (broken intro/topic/keyword links) are all over the place > (not only with the new code). Sometimes we shou

Re: [GRASS-dev] Graphical index in manual

On Sun, Sep 6, 2015 at 11:39 AM, Martin Landa wrote: > 1) there is no graphical modeler, even the manual contains a screenshot Thanks for reporting that. There might be more issues like this. The search for pictures is not 100%, I'm using something more like a "heuristic"

Re: [GRASS-dev] Travis-ci and tests of grass 7

Hi Rainer, On Thu, Sep 3, 2015 at 11:24 AM, Rainer M Krug wrote: > > Hi > > is anything happening in regards to the travis-ci integration? I did not > get any feedback or how I can submit it to the svn. Ideally open a ticket a submit a diff. That's what I do (although I can

Re: [GRASS-dev] Errored: GRASS-GIS/grass-ci#225 (master - a69e8aa)

This seems like an issue with connection between Travis and package archives. See the error messages from Travis below. It complies fine for me with and without LAPACK and BLAS. Vaclav Err http://ppa.launchpad.net/ubuntugis/ppa/ubuntu/ precise/main libspatialite5 amd64 4.1.0-2~precise1 Unable

[GRASS-dev] r.in.lidar: height above ground

Hi, in r66094, I've added base raster map to r.in.lidar. When provided, r.in.lidar with subtract its values from the points' z values. In this way, one can get height about ground. Needs testing before general anouncement, so feel free to do so. Adding a simple suggestion how to do a benchmark

[GRASS-dev] Direct OGR access requires layer and is unclear about read only

Hi, in the source code I stumbled on direct OGR access and realized that I don't know what it is. I haven't found any documentation (now I think there might be something on the wiki) but at the end I remembered I've seen it (probably lately for the GSoC idea) and figured out that you can do the

Re: [GRASS-dev] GRASS GIS and PDAL: C API?

On Tue, Sep 1, 2015 at 7:45 AM, Howard Butler <how...@hobu.co> wrote: > > On Aug 31, 2015, at 9:28 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > Is there any ongoing or planned work on C API for PDAL? > > There is no specific GDAL-style C API work planned for

Re: [GRASS-dev] G_OPT_V_TYPE cannot be recognized in --interface-description in GRASS GIS

On Tue, Sep 1, 2015 at 5:14 AM, Radim Blazek <radim.bla...@gmail.com> wrote: > > On Tue, Aug 25, 2015 at 3:31 AM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > Was: [Qgis-developer] QGIS GRASS plugin - modules upgrade > >> >> 2) define relations betw

[GRASS-dev] GRASS GIS and PDAL: C API?

Dear all, first, thanks Howard for detailed answer in the original thread "New Mac binaries uploaded". The listed points are really encouraging. (I'm creating a new thread to keep it organized; cross posting grass-dev and pdal.) Removing the Boost dependency and an actual release with packages

Re: [GRASS-dev] Some wxPython 3 issues

My system is: GRASS version: 7.1.svn GRASS SVN revision: 66067M Build date: 2015-08-29 Build platform: x86_64-unknown-linux-gnu GDAL: 1.11.2 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.8.7.4 Python: 2.7.9 wxPython: 3.0.1.1 Platform: Linux-3.19.0-26-generic-x86_64-with-Ubuntu-15.04-vivid Splash is fine

Re: [GRASS-dev] Graphical index in manual

On Mon, Aug 24, 2015 at 11:16 AM, Vaclav Petras wenzesl...@gmail.com wrote: Hi, in r65999 [1] I added a graphical index. Hopefully it is an appropriate name. Run make in man dir to get graphical_index.html. The page itself is quite simple, just images, highlight and link title attribute

Re: [GRASS-dev] Grass flyer

Nice work, Vincent. The history should be really short, I prefer something like ...celebrated 30 years of GRASS GIS development in 2013...last change was probably just few hours ago... On Tue, Aug 25, 2015 at 8:52 AM, Vincent Bain b...@toraval.fr wrote: - Is this meant as a flyer to be

Re: [GRASS-dev] New Mac binaries uploaded

On Mon, Aug 24, 2015 at 1:40 PM, Michael Barton michael.bar...@asu.edu wrote: If I am understanding the compiling instructions correctly, it installs binaries of the open source LAStools and Liblas too. But I may misunderstand. The GRASS LAS tool set needs both I believe. GRASS GIS is fine

[GRASS-dev] G_OPT_V_TYPE cannot be recognized in --interface-description in GRASS GIS

Was: [Qgis-developer] QGIS GRASS plugin - modules upgrade On Mon, Aug 24, 2015 at 2:42 PM, Radim Blazek radim.bla...@gmail.com wrote: On Tue, Aug 18, 2015 at 9:39 PM, Vaclav Petras wenzesl...@gmail.com wrote: I wonder why UI is not generated on the fly or during compilation? To maintain

Re: [GRASS-dev] Python scripts receiving input from the GRASS GUI?

On Thu, Aug 20, 2015 at 5:49 AM, Michel Wortmann wortm...@pik-potsdam.de wrote: I agree that it is a bit of a dirty implementation, but I guess I just wanted to make this work quickly. Sure this happens, but we need to avoid that as much as possible. That's why I was mentioning that there is

Re: [GRASS-dev] Running python test: why are they not running?

On Wed, Aug 19, 2015 at 11:02 AM, Rainer M Krug rai...@krugs.de wrote: Hi I am working on the homebrew script for OS X and am trying to implement the tests. I download the test dataset, extract it, and run --8---cut here---start-8--- grass71

Re: [GRASS-dev] Running python test: why are they not running?

On Thu, Aug 20, 2015 at 10:25 AM, Rainer M Krug rai...@krugs.de wrote: The easiest might be to checkout the tests before usage. How can I check them out from svn and in which folder are they located? But I assume they have to be compiled before usage? What needs to be compiled should (i.e.

Re: [GRASS-dev] Python scripts receiving input from the GRASS GUI?

Hi Michel, On Thu, Aug 13, 2015 at 10:32 AM, Michel Wortmann wortm...@pik-potsdam.de wrote: Dear Devs, what would be the best and least invasive way of receiving input from the grass GUI to use in python scripts. The following functionalities are on my mind: - when double-clicking a line

Re: [GRASS-dev] Python scripts receiving input from the GRASS GUI?

code. Vaclav Regards, Michel On 08/19/2015 03:47 PM, Vaclav Petras wrote: Hi Michel, On Thu, Aug 13, 2015 at 10:32 AM, Michel Wortmann wortm...@pik-potsdam.de wrote: Dear Devs, what would be the best and least invasive way of receiving input from the grass GUI to use in python

Re: [GRASS-dev] Python scripts receiving input from the GRASS GUI?

Michel, one more thing: On Wed, Aug 19, 2015 at 9:47 AM, Vaclav Petras wenzesl...@gmail.com wrote: 4. For attribute data (dbmgr), copy and paste the line's content can be enough. Same for query results. For query, the copy is implemented but the format might not be good for parsing. For dbmgr

[GRASS-dev] Failing tests and t.connect 3 hour test solved

Hi all, as reported earlier [1, 2] t.connect test test_distr_tgis_db_raster.py [3] in Piemonte Location [4] takes 3.5 hours to execute [5]. This is happening constantly for a long time already [6] but it was not happening at the very beginning [7]. Now I realized (the hard way) that the test was

Re: [GRASS-dev] Add support for Python3

On Tue, Aug 4, 2015 at 2:14 AM, Pietro peter.z...@gmail.com wrote: I've stopped to go on with the syncronization of my local changes and trunk since I noticed that from the 27th of July the tests are not running anymore: http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html

Re: [GRASS-dev] Add support for Python3

On Wed, Aug 5, 2015 at 10:49 AM, Markus Neteler nete...@osgeo.org wrote: table = '%s.%s' (schema, table) TypeError: 'str' object is not callable As I said, I think it is missing percent operator. Probably trivial to fix but we should understand how it happen to be in the source code.

Re: [GRASS-dev] Travis CI

On Mon, Jul 27, 2015 at 11:11 AM, Ivan Mincik ivan.min...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Pietro, I have missed your email. Sorry for late answer. On 23.07.2015 09:22, Pietro wrote: Dear Ivan, On Tue, Jul 21, 2015 at 11:52 AM, Ivan Minčík

[GRASS-dev] Tests now using NC basic

Hi, in r65613 I switched all tests to NC SPM basic location (smaller subset NC location) [2]. My automated test runs [3] are now using this location as well. Please check the currently failing tests [4]. See the documentation [5] to add new tests. Vaclav [1]

Re: [GRASS-dev] Parser checking output maps but not input maps

On Mon, Jul 6, 2015 at 7:56 PM, Glynn Clements gl...@gclements.plus.com wrote: is there some reason for GRASS parser not checking if the input map exists? It checks if the output map exists and if it it does it ends execution with an error. If an input map (or file) doesn't

Re: [GRASS-dev] Parser checking output maps but not input maps

On Sat, Jul 4, 2015 at 12:55 PM, Glynn Clements gl...@gclements.plus.com wrote: Vaclav Petras wrote: is there some reason for GRASS parser not checking if the input map exists? It checks if the output map exists and if it it does it ends execution with an error. If an input map

[GRASS-dev] Parser checking output maps but not input maps

Hi, is there some reason for GRASS parser not checking if the input map exists? It checks if the output map exists and if it it does it ends execution with an error. Having this interface definition (full script attached): #%option G_OPT_R_INPUT #% key: elevation #%end #%option G_OPT_R_OUTPUT

Re: [GRASS-dev] G7.0.svn: g.remove segfault

On Fri, Jun 26, 2015 at 3:54 PM, Sören Gebbert soerengebb...@googlemail.com wrote: may i suggest a patch to solve this issue? Sure! Ok, i will commit the patch. I'm not sure if I can judge the path. However, sprintf is used a lot in GRASS, so I'm not sure if we can just replace

Re: [GRASS-dev] G7.0.svn: g.remove segfault

for gunittest. Which is even more advanced then I expected because valgrind is not need for the tested module but just for a helper one, anyway, the testing framework should allow that. I'm not sure if Soeren can repeat it in more direct way. Māris. 2015-06-25 3:47 GMT+03:00 Vaclav Petras wenzesl

Re: [GRASS-dev] Weekly snapshot - link with non-changing name?

On Fri, Jun 26, 2015 at 4:52 AM, Rainer M Krug rai...@krugs.de wrote: Hi Vaclav, Vaclav Petras wenzesl...@gmail.com writes: On Mon, Jun 22, 2015 at 9:40 AM, Rainer M Krug rai...@krugs.de wrote: Markus Neteler nete...@osgeo.org writes: On Jun 20, 2015 5:16 PM, Rainer M Krug rai

Re: [GRASS-dev] G7.0.svn: g.remove segfault

to be in M_do_remove calling some sort of sprintf?? Maybe line 102, since the colr2 buffer is only 50 chars in length ... however, sprintf() function shouldn't be used at all. Best regards Soeren 2015-06-26 16:11 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: On Fri, Jun 26, 2015 at 6:09 AM

Re: [GRASS-dev] [GRASS-user] Error in pansharp tool: missing grass.script

On Thu, Jun 25, 2015 at 3:41 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 24/06/15 15:09, Vaclav Petras wrote: It seems like one. I think it might help, at least help to debug, if you replace import grass.script as grass by import grass.script as gscript and grass. by gscript

Re: [GRASS-dev] [GRASS-user] Error in pansharp tool: missing grass.script

On Thu, Jun 25, 2015 at 11:38 AM, Nikos Alexandris n...@nikosalexandris.net wrote: Yep, but a scripter wouldn't want to repeat `grass.script.` everytime. Would he? That's why I think import grass.script as gscript should be used. The examples were just showing different scenarios and

Re: [GRASS-dev] temporal modules cannot open database

On Thu, Jun 25, 2015 at 5:53 AM, Sören Gebbert soerengebb...@googlemail.com wrote: Hi Luca, i just committed a patch in SVN that can handle modified location path's. Thanks Soeren, I think I actually hit the issue before. Please make an update of grass7.1 and then call t.connect -d in the

Re: [GRASS-dev] G7.0.svn: g.remove segfault

On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler nete...@osgeo.org wrote: On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler nete...@osgeo.org wrote: Hi, to my surprise I managed to generate a segfault using g.remove: please disregard. Apparently a system update triggered this (no idea how).

Re: [GRASS-dev] G7.0.svn: g.remove segfault

On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler nete...@osgeo.org wrote: On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler nete...@osgeo.org wrote: Hi, to my surprise I managed to generate a segfault using

Re: [GRASS-dev] Weekly snapshot - link with non-changing name?

On Mon, Jun 22, 2015 at 9:40 AM, Rainer M Krug rai...@krugs.de wrote: Markus Neteler nete...@osgeo.org writes: On Jun 20, 2015 5:16 PM, Rainer M Krug rai...@krugs.de wrote: Vaclav Petras wenzesl...@gmail.com writes: It is really just a automatic snapshot, not a tested release

Re: [GRASS-dev] Weekly snapshot - link with non-changing name?

On Sat, Jun 20, 2015 at 9:02 AM, Rainer M Krug rai...@krugs.de wrote: Rainer M Krug rai...@krugs.de writes: Markus Neteler nete...@osgeo.org writes: On Fri, Jun 19, 2015 at 10:42 AM, Rainer M Krug rai...@krugs.de wrote: Hi I have a homebrew recipe for installing grass 7.1 on a Mac.

Re: [GRASS-dev] [GRASS-SVN] r65497 - grass/trunk/locale/po

On Wed, Jun 17, 2015 at 10:14 AM, svn_gr...@osgeo.org wrote: Modified: grass/trunk/locale/po/grasslibs_fr.po === --- grass/trunk/locale/po/grasslibs_fr.po 2015-06-17 13:53:52 UTC (rev 65496) +++

Re: [GRASS-dev] [GRASS-SVN] r65497 - grass/trunk/locale/po

On Thu, Jun 18, 2015 at 10:08 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 18/06/15 15:48, Vaclav Petras wrote: On Wed, Jun 17, 2015 at 10:14 AM, svn_gr...@osgeo.org mailto:svn_gr...@osgeo.org wrote: Modified: grass/trunk/locale/po/grasslibs_fr.po

Re: [GRASS-dev] [GRASS-SVN] r65497 - grass/trunk/locale/po

On Thu, Jun 18, 2015 at 1:48 PM, Maris Nartiss maris@gmail.com wrote: _(ERROR: ) + msg is also not a bright idea as it would not play nicely with right to left (RTL) languages. I am not an expert in RTL and thus can not comment too much. At the moment there seems to be no feedback from

Re: [GRASS-dev] Debugging QGIS with GRASS provider on Windows

On Tue, Jun 16, 2015 at 2:01 PM, Radim Blazek radim.bla...@gmail.com wrote: Hi, I need to debug QGIS GRASS provider on Windows. I have successfully compiled GRASS 7 using MinGW [1] and QGIS using MSVC [2]. The problem is that MSVC does not support GCC debugging symbols and vice versa. Do you

Re: [GRASS-dev] Making sense of packages for Ubuntu

On Mon, Jun 15, 2015 at 9:12 AM, Vaclav Petras wenzesl...@gmail.com wrote: Recently, I helped my colleague to install GRASS from packages and Synaptic showed grass and grass7 packages both with version 7.0.0. I used grass7 and it works. So what is the actual state and preferred way

Re: [GRASS-dev] All Python addons are missing

On Sun, Jun 14, 2015 at 4:15 AM, Martin Landa landa.mar...@gmail.com wrote: 2015-06-14 1:56 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: Sorry to report but grass.script cannot be imported when building addons, e.g.: http://grass.osgeo.org/addons/grass7/logs/d.vect.thematic2.log

Re: [GRASS-dev] All Python addons are missing

On Sun, Jun 14, 2015 at 7:01 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Sun, Jun 14, 2015 at 6:43 AM, Markus Neteler nete...@osgeo.org wrote: On Sun, Jun 14, 2015 at 12:40 PM, Vaclav Petras wenzesl...@gmail.com wrote: ... If you want to avoid problems run `make distclean` before

Re: [GRASS-dev] All Python addons are missing

On Sun, Jun 14, 2015 at 4:49 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-06-14 1:56 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: http://grass.osgeo.org/addons/grass7/logs/d.vect.thematic2.log btw, I am getting strange error on server when compiling relbr70: ``` GRASS GIS

Re: [GRASS-dev] grass bug tracker: any action not forwarded to ticket reporter anymore?

On Sun, Jun 14, 2015 at 4:29 PM, Helmut Kudrnovsky hel...@web.de wrote: if I remember correctly: if an open ticket reported by me/commented by me was commented/closed/etc by me/another one, an email with the comment/action was forwarded to my email address. I'm little bit confused about

[GRASS-dev] r65348: Mapset's tmp dir placement and broken element search

Moving the conversation from the ticket. On Sat, Jun 6, 2015 at 9:16 AM, GRASS GIS t...@osgeo.org wrote: #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE --+--- Reporter: neteler |

Re: [GRASS-dev] r65348: Mapset's tmp dir placement and broken element search

On Wed, Jun 10, 2015 at 3:05 PM, Martin Landa landa.mar...@gmail.com wrote: 2015-06-10 17:41 GMT+02:00 Glynn Clements gl...@gclements.plus.com: Vaclav Petras wrote: First, it allows unorthodox behavior of GRASS but this behavior is (or at least should be) applied only when

[GRASS-dev] Not all new Trac features should be used every day

Hi devs and users, new Trac has a lot of new features (I sent separate emails about it [1, 2]), but not all of them are useful all the time. Specifically, you can now edit your comments. This is good for fixing typos but it shouln't be used for updates on the topic. The edits are not so clear as

[GRASS-dev] Documentation server build log full of syntax errors in pygrass

Hi Pietro, the build log on a server which is creating the documentation is full of syntax errors in coming from pygrass. It's actually just one error but in broadly used part (t.* as well as gunittest are affected). I guess that the other error is just the result of the first one (see end of

[GRASS-dev] Availability of packages for 7.0 release branch

On Fri, Jun 5, 2015 at 5:17 PM, svn_gr...@osgeo.org wrote: Author: martinl Date: 2015-06-05 14:17:01 -0700 (Fri, 05 Jun 2015) New Revision: 65381 Modified: grass-addons/tools/wingrass-packager/grass_addons.sh grass-addons/tools/wingrass-packager/grass_compile.sh

Re: [GRASS-dev] [GRASS-SVN] r65425 - in grass-addons/grass7/raster: . r.seg

On Tue, Jun 9, 2015 at 8:51 AM, svn_gr...@osgeo.org wrote: Author: avitti Date: 2015-06-09 05:51:48 -0700 (Tue, 09 Jun 2015) New Revision: 65425 Added: grass-addons/grass7/raster/r.seg/ grass-addons/grass7/raster/r.seg/Makefile grass-addons/grass7/raster/r.seg/main.c

Re: [GRASS-dev] [GRASS-SVN] r65425 - in grass-addons/grass7/raster: . r.seg

On Tue, Jun 9, 2015 at 1:54 PM, Markus Neteler nete...@osgeo.org wrote: On Jun 9, 2015 7:03 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Tue, Jun 9, 2015 at 8:51 AM, svn_gr...@osgeo.org wrote: Author: avitti Date: 2015-06-09 05:51:48 -0700 (Tue, 09 Jun 2015) New Revision

Re: [GRASS-dev] GRASS GIS 7.0.1 planning: potential backports

What is the status of r65057, #2626, and #2655? In 70 release branch, I'm not able to use PostgreSQL attribute table but it works in trunk. I think that this is thanks to r65057. The bug was probably also reason for encountering #2626. Thanks, Vaclav db.login + pg mysql driver: support

<    3   4   5   6   7   8   9   10   11   12   >