Re: [GRASS-dev] Fwd: Re: [OSGeo-Discuss] OSGeo4W maintenance activities

On Sun, Feb 21, 2016 at 5:15 PM, Rashad Kanavath wrote: > > Hello Markus, > > As this part related to GRASS, I am writing it here. > > Moving to cmake is one thing. But I don't know if that is blocking msvc > build. Did anybody tried to build grass with msvc? Yes I

Re: [GRASS-dev] Fwd: Re: [OSGeo-Discuss] OSGeo4W maintenance activities

On Sun, Feb 21, 2016 at 4:19 PM, Markus Neteler wrote: > FYI > (ongoing discussion in the other list) > > -- Forwarded message -- > From: "Jürgen E." > Date: Feb 21, 2016 4:14 PM > Subject: Re: [OSGeo-Discuss] OSGeo4W maintenance activities >

Re: [GRASS-dev] Open/close db drivers order

On Thu, Oct 22, 2015 at 11:58 PM, Glynn Clements wrote: >> But there may be other file descriptors not related to db drivers. Is >> it possible to close all of them in driver process? > > Maybe. > > When fork() clones a process, the descriptor table is cloned along >

Re: [GRASS-dev] Open/close db drivers order

On Thu, Oct 22, 2015 at 4:16 AM, Glynn Clements <gl...@gclements.plus.com> wrote: > > Radim Blazek wrote: > >> I found, that db drivers must be closed in reverse order to the order >> in which were opened, otherwise it hangs (Linux). I vaguely remember >>

[GRASS-dev] SF_UNKNOWN conflict

JFYI, SF_UNKNOWN defined in dig_defines.h is in conflict with SF_UNKNOWN defined in oaidl.h on Windows. Radim ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Open/close db drivers order

I have created https://trac.osgeo.org/grass/ticket/2775 It works if DB_PROC_SHUTDOWN_DRIVER is sent like on Windows. Patch (very simple) is supplied. Radim On Wed, Oct 21, 2015 at 10:16 AM, Radim Blazek <radim.bla...@gmail.com> wrote: > On Tue, Oct 20, 2015 at 7:18 PM, Radim Blazek &

Re: [GRASS-dev] Open/close db drivers order

On Tue, Oct 20, 2015 at 7:18 PM, Radim Blazek <radim.bla...@gmail.com> wrote: > I found, that db drivers must be closed in reverse order to the order > in which were opened, otherwise it hangs (Linux). I vaguely remember > that this was a problem years ago. Is it still an issue

[GRASS-dev] Vect_cidx_find_next returns 0 for empty cidx

It seems that Vect_cidx_find_next returns 0 instead of -1 if there are no cats in the index (Vect_cidx_get_num_cats_by_index return 0). Radim ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Open/close db drivers order

I found, that db drivers must be closed in reverse order to the order in which were opened, otherwise it hangs (Linux). I vaguely remember that this was a problem years ago. Is it still an issue, anybody knows more about the problem? Radim ___ grass-dev

[GRASS-dev] t.list slow

Hi, I found t.list module to be quite slow, about 500ms. Simple "select * from strds_absolute_time;" takes about 8ms with sqlite3 or db.select. If I want to get list of more types for more mapsets (for example mapsets which are not in SEARCH_PATH) it takes seconds. Is there a chance to make it

Re: [GRASS-dev] t.list slow

t#grassdataexplorerdialog.py-739 > > The function from the temporal framework is: tgis.get_dataset_list() > This should be almost as fast as the direct sqlite interface. > > Best regards > Soeren > > 2015-10-18 13:15 GMT+02:00 Radim Blazek <radim.bla...@gmail.com>

Re: [GRASS-dev] db_start_driver without window

On Thu, Oct 15, 2015 at 9:00 AM, Markus Neteler <nete...@osgeo.org> wrote: > On Wed, Oct 14, 2015 at 7:39 PM, Radim Blazek <radim.bla...@gmail.com> wrote: >> When a driver is started from QGIS on Windows using db_start_driver -> >> G_spawn_ex -> do_spawn ->

[GRASS-dev] db_start_driver without window

When a driver is started from QGIS on Windows using db_start_driver -> G_spawn_ex -> do_spawn -> win_spawn > CreateProcess, it opens black window. Is there a possibility to prevent opening that window by setting some global Windows param before db_start_driver is called? If not, would it be

Re: [GRASS-dev] [Qgis-developer] New GRASS plugin: a test drive

On Mon, Oct 5, 2015 at 11:16 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > On Mon, Oct 5, 2015 at 1:16 PM, Radim Blazek <radim.bla...@gmail.com> wrote: >> >> >> There is v.build.all in modules. >> > >> > yes, but the user has no hint

Re: [GRASS-dev] How to get data from a location where the user does not own any mapset?

On Sun, Sep 27, 2015 at 9:14 PM, Glynn Clements <gl...@gclements.plus.com> wrote: > > Radim Blazek wrote: > >> Perfect, that is what I need. Why GRASS_SKIP_MAPSET_OWNER_CHECK should >> not be set by programs for read only access? > > If you only need to read a m

Re: [GRASS-dev] How to get data from a location where the user does not own any mapset?

Thanks for the extensive explanation, Glynn. On Tue, Sep 22, 2015 at 5:18 PM, Glynn Clements <gl...@gclements.plus.com> wrote: > > Radim Blazek wrote: > >> Is it possible to access data through GRASS modules in a location >> where the user does not own any mapset? Ea

[GRASS-dev] How to get data from a location where the user does not own any mapset?

Is it possible to access data through GRASS modules in a location where the user does not own any mapset? Each GRASS module calls first G_gisinit() which checks if current mapset returned by G_mapset() is owned by current user. If it is not, it ends with fatal error. How to get around this for

Re: [GRASS-dev] Vect_rewrite_line using off_t as line id

On Fri, Sep 18, 2015 at 11:08 AM, Martin Landa wrote: > Hi, > > 2015-09-18 10:29 GMT+02:00 Glynn Clements : > >> Ultimately, the only place where the actual off_t size is "known" is >> in compiled code. It might be worth adding this information to

[GRASS-dev] Vect_rewrite_line using off_t as line id

Hi, I see that in r55582 was changed the type of line parameter in Vect_rewrite_line, Vect_restore_line and Vect_delete_line from int to off_t. It makes it impossible to use those functions from an application compiled with a compiler which has different off_t size, which is the case for QGIS /

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

On Tue, Aug 25, 2015 at 3:31 AM, Vaclav Petras wrote: > Was: [Qgis-developer] QGIS GRASS plugin - modules upgrade >> >> 2) define relations between options (e.g. type or column option >> >> relation with input vector) or special options which has dedicated >> >> widget in UI

Re: [GRASS-dev] Vect_new_map_struct

until we drop GRASS 6 and GRASS 7.0 support. Radim Best regards Soeren 2015-08-26 19:37 GMT+02:00 Radim Blazek radim.bla...@gmail.com: Hi, I have created new issue https://trac.osgeo.org/grass/ticket/2729 requesting to add Vect_new_map_struct, patch is supplied. Radim

[GRASS-dev] Vect_new_map_struct

Hi, I have created new issue https://trac.osgeo.org/grass/ticket/2729 requesting to add Vect_new_map_struct, patch is supplied. Radim ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] QGIS GRASS plugin - modules upgrade

Hi, the GRASS 7 plugin is enabled in QGIS master, but there are many options which changed in GRASS 7 and has to be fixed in .qgm files. Because some people already promised to help with the upgrade of modules' configuration I want to ask them and everybody who is interested, to start the upgrade

[GRASS-dev] Slow insert to GRASS SQLite db from QGIS

Vector import to GRASS in QGIS browser is very slow when using SQLite database, about 6s/1000 features. It takes less than 1s with dbf driver or if v.in.ogr + sqlite is used (even if run from GRASS tools). The chain is: qgis.exe - thread - qgis.v.in.exe - sqlite.exe Could it be some SQLite db

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

On Sun, Jun 21, 2015 at 4:32 AM, Glynn Clements gl...@gclements.plus.com wrote: Helmut Kudrnovsky wrote: Finally I found it, it is similar story like with FILE. The provider (MSVC) calls Vect__open_old with struct Map_info variable allocated in the provider where sizeof(struct Map_info) =

Re: [GRASS-dev] Slow insert to GRASS SQLite db from QGIS

Solved. I forgot db_begin_transaction. Sorry for noise. Radim On Mon, Jun 22, 2015 at 9:18 PM, Radim Blazek radim.bla...@gmail.com wrote: Vector import to GRASS in QGIS browser is very slow when using SQLite database, about 6s/1000 features. It takes less than 1s with dbf driver

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

On Tue, Jun 16, 2015 at 10:48 PM, Vaclav Petras wenzesl...@gmail.com wrote: 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

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

On Fri, Jun 19, 2015 at 9:44 AM, Maris Nartiss maris@gmail.com wrote: 2015-06-19 10:35 GMT+03:00 Radim Blazek radim.bla...@gmail.com: I have somehow managed to compile limited GRASS core libs with MSVC and GRASS Makefiles replacing gcc by cl.exe. The build system does not seem

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

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 have any idea how to debug both QGIS and GRASS code at the same time, preferably

Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

Hi all. The project is funded! Thanks to everybody who contributed or promoted the project. The first two parts are implemented, you can follow the work progress here: http://www.gissula.eu/qgis-grass-plugin-crowdfunding/progress.html browser demo video:

Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

correctly from project file (e.g. project created in GRASS 6, vectors upgraded to GRASS 7 and project reopened in QGIS with GRASS 7). I'll do more detailed announcement after QGIS 2.10 freeze. Radim Best regards Soeren 2015-03-23 19:56 GMT+01:00 Radim Blazek radim.bla...@gmail.com: Hi all

Re: [GRASS-dev] [Qgis-developer] Temporal data (was QGIS GRASS Plugin Upgrade Crowdfunding)

On Mon, Mar 30, 2015 at 11:17 AM, Nyall Dawson nyall.daw...@gmail.com wrote: On 30 March 2015 at 18:47, Radim Blazek radim.bla...@gmail.com wrote: Hi again. I am getting convinced that the temporal data visualization support should be added to QGIS core. A single time navigation toolbar

[GRASS-dev] Temporal data (was QGIS GRASS Plugin Upgrade Crowdfunding)

Hi again. On Tue, Mar 24, 2015 at 10:04 AM, Sören Gebbert soerengebb...@googlemail.com wrote: Are there functions in time series implementation which need to be called directly from the plugin or everything may be done just calling t.rast.* modules? Most of the temporal functionality is

Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

The first package is financed by 29 contributors! Many thanks to everybody who contributed so far. Please keep on contributing. Radim On Mon, Mar 23, 2015 at 7:56 PM, Radim Blazek radim.bla...@gmail.com wrote: Hi all, I have finally launched the crowdfunding campaign to support the GRASS

Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

Special thanks to Andreas Neumann from City of Uster (http://gis.uster.ch/), Switzerland. Thanks to his 1000 euro we quickly got over 2000! Only 234 euro missing to reach the second package. Thanks to all contributors. Radim On Wed, Mar 25, 2015 at 9:33 AM, Radim Blazek radim.bla...@gmail.com

Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

Hi Soeren On Tue, Mar 24, 2015 at 10:04 AM, Sören Gebbert soerengebb...@googlemail.com wrote: 2015-03-24 9:40 GMT+01:00 Radim Blazek radim.bla...@gmail.com: I completely agree that Python would be better, the advantages of Python are obvious and that would be definitely my choice if I had

Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

, selecting feature categories in map canvas and so on. You may be interested in https://github.com/qgis/QGIS/blob/master/src/plugins/grass/qgsgrassmodule.cpp Do you see a possibility how we could join the effort? Radim Best regards Pietro On Mon, Mar 23, 2015 at 7:56 PM, Radim Blazek

Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

/~epebe_01/tgrass.pdf Btw: Otto Dassau and i mentioned your crowd funding idea at the FOSSGIS in Germany two weeks ago. It is on Youtube[2] but only in German. [2] https://www.youtube.com/watch?v=rxmPbh2igmMt=1407 2015-03-23 19:56 GMT+01:00 Radim Blazek radim.bla...@gmail.com: Hi all, I have

[GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

Hi all, I have finally launched the crowdfunding campaign to support the GRASS plugin upgrade. Briefly, it covers upgrade to GRASS 7, browser integration, drag-and-drop import and new vector editing. All the details are available here: http://www.gissula.eu/qgis-grass-plugin-crowdfunding/

Re: [GRASS-dev] [Qgis-developer] QGIS and GRASS 7.0.0

The new GRASS vector editing tool preview screencast: https://www.youtube.com/watch?v=PPno1aLYHFE Radim On Tue, Feb 24, 2015 at 10:08 AM, Paolo Cavallini cavall...@faunalia.it wrote: Hi Radim, thanks a lot for this. Il 24/02/2015 09:28, Radim Blazek ha scritto: - modules GUI - my idea

Re: [GRASS-dev] [GRASS GIS] #1628: segfault in r.walk

Sorry for not responding earlier, I missed somehow this mail. On Sat, May 17, 2014 at 7:33 PM, Glynn Clements gl...@gclements.plus.com wrote: Is there any reason to retain lib/sites as a separate library, rather than simply merging it into v.in.sites? There isn't a ctypes wrapper for it, so

Re: [GRASS-dev] Improving the G_calloc: unable to allocate xx bytes of memory message?

On Thu, Nov 6, 2014 at 8:59 AM, Glynn Clements gl...@gclements.plus.com wrote: Radim Blazek wrote: +++ include/Make/Compile.make (working copy) +ALL_CFLAGS = $(LFS_CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(DEFS) $(EXTRA_INC) $(INC) -DRELDIR=\$(RELDIR)\ +#define G_malloc(n

[GRASS-dev] Get point node

Vect_get_line_nodes() does not work for points in GRASS 7. How can I get node id for a point (by point id)? Radim ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Improving the G_calloc: unable to allocate xx bytes of memory message?

On Sat, Oct 25, 2014 at 12:13 AM, Glynn Clements gl...@gclements.plus.com wrote: +++ include/Make/Compile.make (working copy) +ALL_CFLAGS = $(LFS_CFLAGS) $(EXTRA_CFLAGS) $(NLS_CFLAGS) $(DEFS) $(EXTRA_INC) $(INC) -DRELDIR=\$(RELDIR)\ +#define G_malloc(n) G__malloc(RELDIR / __FILE__,

Re: [GRASS-dev] GRASS QGIS: the future

On Wed, May 28, 2014 at 1:49 AM, Glynn Clements gl...@gclements.plus.com wrote: But I still think that the global error handler is the wrong place for a longjmp(). Its original purpose was to allow the standard notification mechanism (stderr, log file, and/or email) to be replaced with a

Re: [GRASS-dev] GRASS QGIS: the future

On Sat, May 17, 2014 at 7:16 PM, Glynn Clements gl...@gclements.plus.com wrote: Also, currently the global error handler (G_set_error_routine) is called before the non-exclusive handlers (G_add_error_handler), so those will never be called if the global handler lonjmp()s out. The global

Re: [GRASS-dev] GRASS QGIS: the future

On Fri, Apr 18, 2014 at 12:27 PM, Paolo Cavallini cavall...@faunalia.it wrote: Thanks for this. If I understand well, this means: * we can load GRASS7 vectors through QGIS browser * we cannot load GRASS7 rasters Raster provider is also upgraded (bf6effdd). * the qgis-grass-plugin is not

Re: [GRASS-dev] GRASS QGIS: the future

Dne 16.5.2014 18:36 Glynn Clements gl...@gclements.plus.com napsal(a): Radim Blazek wrote: There is a problem in G_fatal_error(): static int busy if (busy) exit(EXIT_FAILURE); busy = 1; second G_fatal_error() call always exits. The busy check

Re: [GRASS-dev] GRASS QGIS: the future

On Sat, Apr 19, 2014 at 12:43 AM, Glynn Clements gl...@gclements.plus.com wrote: 3) use setjmp()/longjmp() That is the sane option. But bear in mind that subsequently calling any GRASS function is entirely at your own risk. A call to G_fatal_error() often means that internal data

Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future

On Wed, Apr 23, 2014 at 4:02 PM, Sören Gebbert Vector lib does not call G_fatal_error(), it was written in parallel with QGIS plugin with vector editing in mind. I hope it is still true. I fear that might be not the case anymore. For example, all memory allocation functions G_calloc(),

Re: [GRASS-dev] Greetings to the sprinters

On Fri, Mar 28, 2014 at 9:37 PM, Markus Neteler nete...@osgeo.org wrote: On Fri, Mar 28, 2014 at 12:12 PM, Nikos Alexandris n...@nikosalexandris.net wrote: Hi Devs (GRASSers and Others as well)! I hope you enjoy and have great fun in Wien. I am so sad that I could not join (various reasons)

Re: [GRASS-dev] GRASS QGIS: the future

On Wed, Apr 23, 2014 at 1:11 AM, Glynn Clements 1) add a requirement that GRASS 7 used with QGIS must be compiled with -fexceptions By itself, this will do nothing. I mean to allow to throw exception from the function set by G_set_error_routine(). Does using a C++ exception have any

Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future

+02:00 Radim Blazek radim.bla...@gmail.com: I have upgraded the vector provider to GRASS 7, layers may be added by drag from browser. The raster and the plugin are disabled. Be careful about multiple versions on the same system (LD_LIBRARY_PATH..., check with ldd if does not work

Re: [GRASS-dev] GRASS QGIS: the future

On Wed, Apr 23, 2014 at 10:09 AM, Paolo Cavallini cavall...@faunalia.it wrote: The Processing plugin may substitute GRASS Tools part of the plugin (i.e. modules GUI), it cannot help with: - mapset creation - vector/raster maps visualization - vector digitizing - region visualization

Re: [GRASS-dev] GRASS QGIS: the future

On Fri, Apr 18, 2014 at 12:27 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 18/04/2014 11:31, Radim Blazek ha scritto: I have upgraded the vector provider to GRASS 7, layers may be added by drag from browser. The raster and the plugin are disabled. Be careful about multiple versions

Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future

imagine endless bug reports about server not running. I am looking for something which will not require permanent assistance. It is not KISS enough for me. Radim 2014-04-18 11:31 GMT+02:00 Radim Blazek radim.bla...@gmail.com: I have upgraded the vector provider to GRASS 7, layers may be added

Re: [GRASS-dev] GRASS QGIS: the future

On Sat, Apr 19, 2014 at 12:43 AM, Glynn Clements gl...@gclements.plus.com wrote: Basically more and more low level functions are calling exit() instead of returning error code if something failed. As I am not willing to implement GRASS module call for each simple function, we have to think

Re: [GRASS-dev] GRASS QGIS: the future

I have upgraded the vector provider to GRASS 7, layers may be added by drag from browser. The raster and the plugin are disabled. Be careful about multiple versions on the same system (LD_LIBRARY_PATH..., check with ldd if does not work). Unfortunately GRASS 7 moved ahead towards its aim to make

Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future

On Tue, Apr 8, 2014 at 2:18 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 28/03/14 15:16, Paolo Cavallini wrote: Il 28/03/2014 15:04, Martin Dobias ha scritto: On Fri, Mar 28, 2014 at 11:48 AM, Paolo Cavallini cavall...@faunalia.it wrote: * to add GRASS browsing capabilities in

Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future

On Tue, Apr 8, 2014 at 3:54 PM, Rainer M Krug rai...@krugs.de wrote: Radim Blazek radim.bla...@gmail.com writes: On Tue, Apr 8, 2014 at 2:18 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 28/03/14 15:16, Paolo Cavallini wrote: Il 28/03/2014 15:04, Martin Dobias ha scritto

Re: [GRASS-dev] Strange import of .asc

On Tue, Jan 15, 2013 at 10:27 AM, Paolo Cavallini cavall...@faunalia.it wrote: Il 14/01/2013 20:17, Helmut Kudrnovsky ha scritto: yes - have you tired displaying it under the vector? yes, the newly imported raster and also your raster delivered with the location are aligned with the vector.

[GRASS-dev] Re: [Qgis-developer] Re: Value tool plugin makes QGIS crash

On Sat, Mar 26, 2011 at 9:29 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: It works pretty good with *non* GRASS rasters, while with GRASS rasters is very slow (on Windows, acceptable on linux) Explanation for GRASS list: he is talking about Value tool which is displaying a raster value

Re: [GRASS-dev] Re: [Qgis-developer] Re: Value tool plugin makes QGIS crash

On Mon, Mar 28, 2011 at 9:38 AM, Hamish hamis...@yahoo.com wrote: Radim wrote: If there are 10 maps open in QGIS, it starts 1 executables in about 1 second. That is probably a bit slow. maybe a little :) I do not suggest this as a correct solution, but fyi r.what can take multiple

[GRASS-dev] Re: [Qgis-developer] Re: Value tool plugin makes QGIS crash

On Mon, Mar 28, 2011 at 10:12 AM, Jürgen E. j...@norbit.de wrote: Hi Radim, On Mon, 28. Mar 2011 at 09:31:24 +0200, Radim Blazek wrote: Can GRASS developers give us any suggestion how to solve this? Wouldn't it be possible to do the request on the cached image of the last draw request

[GRASS-dev] v.kernel - equal split on network

Hi, thanks to financial support from http://mpba.fbk.eu/en/home , I have implemented equal split algorithm on network as described in A kernel density estimation method for networks, its computational method and a GIS-based tool, Okabe et. all, 2009 and new kernel density functions in both 1 and

Re: [GRASS-dev] Re: [GRASS GIS] #224: cache bug in DGLib

The problem was with 6.4.0, current 6.4 svn seems to work OK. Thanks Radim On Sat, Nov 20, 2010 at 2:29 PM, Markus Neteler nete...@osgeo.org wrote: Hi Radim, On Sat, Nov 20, 2010 at 1:48 PM, Radim Blazek radim.bla...@gmail.com wrote: Hi all, what is the current situation with cache bug

Re: [GRASS-dev] Re: [GRASS GIS] #224: cache bug in DGLib

Hi all, what is the current situation with cache bug in dglib? I found that in 6.4.0 it is still buggy but it is enabled in Vlib/net.c, so all the net modules may give wrong results. Definitely if the cache is buggy it should not be enabled. Radim On Thu, Oct 28, 2010 at 1:21 PM, GRASS GIS

[GRASS-dev] Non ASCII in GISBASE, LOCATION, MAPSET, MAP

Hi, can you point me to some place where restrictions for non ASCII characters use in GISBASE, LOCATION, MAPSET and MAP names are described? I have only found this mail http://www.osgeo.org/pipermail/grass-dev/2007-January/028553.html which does not sound very optimistic. Thanks Radim

Re: [GRASS-dev] grass is a monad?

On Mon, Feb 8, 2010 at 11:03 PM, Glynn Clements gl...@gclements.plus.com wrote: Actually, I would suggest QGIS/vdigit isolating actions within a child process, rather than complicating the rest of GRASS for the sake of two programs, one of which isn't part of GRASS and the other was designed

Re: [GRASS-dev] grass is a monad?

On Mon, Jan 18, 2010 at 3:33 AM, Glynn Clements gl...@gclements.plus.com wrote: Everything except vector editing. I don't see any reasonable possibility to do interactive vector editing via a GRASS module. For vector editing, I need immediate response which is visualized on display (e.g. if a

Re: [GRASS-dev] grass is a monad?

On Thu, Jan 14, 2010 at 10:35 PM, Glynn Clements gl...@gclements.plus.com wrote: This too is Not A Bug. Not isolating distinct operations in distinct processes *is* a bug. I can imagine almost everything done via GRASS modules. Yes, it is annoying to run a GRASS module (probably I have to write

Re: [GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

Thanks for the suggestion. The title of http://trac.osgeo.org/qgis/ticket/1878 is however remove setjmp/longjmp in grass pluginprovider and use exceptions instead so the intention was to remove setjmp/longjmp. I don't know exactly if there were problems with setjmp/longjmp or it was just attempt

Re: [GRASS-dev] Re: terminology issues in grass7

I have doubts about many things I did in GRASS but not about the term 'layer'. It was in fact chosen to correspond better to OGR and usual GIS terminology. And GRASS layer realy is OGR layer equivalent. As it was mentioned already, GRASS layer is like shapefile and GRASS vector is like a directory

Re: [GRASS-dev] svn access

On Mon, May 18, 2009 at 9:53 AM, Hamish hamis...@yahoo.com wrote: should the real fix be alloc += GMAPSET_MAX? I dont think so, dynamic allocation is used. ok, right. G_store() calls G_malloc() to hold the actual mapset name using dynamic length. I mean the array of pointers to mapset

Re: [GRASS-dev] svn access

On Fri, May 15, 2009 at 11:40 AM, Hamish hamis...@yahoo.com wrote: Radim wrote: OK, patch attached, fix for QGIS crash. thanks, I know, I should create a new ticket and then make a comment with the patch attached, right? Right, as it's the only sane way to deal with the extreme

[GRASS-dev] svn access

May I get svn write access? My account on osgeo is 'rblazek'. Radim ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn access

OK, patch attached, fix for QGIS crash. I know, I should create a new ticket and then make a comment with the patch attached, right? Well, if anybody cares, here it is. Radim On Thu, May 14, 2009 at 3:31 PM, Hamish hamis...@yahoo.com wrote: Radim wrote: May I get svn write access? My account