> > Author: hamish
> > Date: 2011-12-02 02:38:18 -0800 (Fri, 02 Dec 2011)
> > New Revision: 49486
> >
> > Added:
> > grass-addons/grass6/raster
> > Log:
> > test to see how well trac deals with symlinks. > > should appear in unix as
> > a symlink, on MS
> > Windows as a regular file
Martin:
> I
Martin:
> currently GIRC file is stored on Windows in
>
> $HOME/.grassrc6
hmmm, I thought that already had happened. I guess
not.
> This location seems to be probably quite weird
> for normal Windows user. I would suggest to store
> GISRC in `$APPDATA\GRASS6\rc`.
It seems like a good & natural
>currently GIRC file is stored on Windows in
>
>$HOME/.grassrc6
>
>This location seems to be probably quite weird for normal Windows
>user. I would suggest to store GISRC in `$APPDATA\GRASS6\rc`. This
>change affects only GRASS-Installer and init.bat script.
>
>What do you think about that?
+1
b
Hi all,
I would like to praise Martin for this new layout, it is intuitive and
I think everyone will get used to it quickly.
Thanks,
Anna
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Thu, Dec 1, 2011 at 1:18 PM, Martin Landa wrote:
...
> I hope that the most of bugs related to wxGUI code reorganization
> should be already fixed. Anyway any testing is highly welcomed, most
> of bugs are very easy to fix, they just need to be discovered;-)
>
> Currently we are in the complica
Martin Landa wrote:
> > No. Pure CLI (Konsole). Modules, that fail to start, g.copy, g.rename,
> > g.remove, g.region (others too?). g.mapset, g.filename work fine. Had
> > no time to test all modules. r.* v.* and d.* modules seem to work just
> > fine.
>
> they don't fail to start, the modules
Hi,
currently GIRC file is stored on Windows in
$HOME/.grassrc6
This location seems to be probably quite weird for normal Windows
user. I would suggest to store GISRC in `$APPDATA\GRASS6\rc`. This
change affects only GRASS-Installer and init.bat script.
What do you think about that?
Martin
--
Hi,
2011/12/2 Maris Nartiss :
> No. Pure CLI (Konsole). Modules, that fail to start, g.copy, g.rename,
> g.remove, g.region (others too?). g.mapset, g.filename work fine. Had
> no time to test all modules. r.* v.* and d.* modules seem to work just
> fine.
they don't fail to start, the modules whi
No. Pure CLI (Konsole). Modules, that fail to start, g.copy, g.rename,
g.remove, g.region (others too?). g.mapset, g.filename work fine. Had
no time to test all modules. r.* v.* and d.* modules seem to work just
fine.
When launching from menu or wxgui command prompt, all modules start just fine.
2011/12/2 Martin Landa :
> Hi,
hi all
> I think that it would be better just to move such dirs to `grass6`. It
> would require to update URL in g.extension and GRASS Addons Wiki page.
+1 to move to grass6
> Martin
>
--
cheers
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
__
Hi,
2011/12/2 :
> Author: hamish
> Date: 2011-12-02 02:38:18 -0800 (Fri, 02 Dec 2011)
> New Revision: 49486
>
> Added:
> grass-addons/grass6/raster
> Log:
> test to see how well trac deals with symlinks. should appear in unix as a
> symlink, on MS Windows as a regular file
I think that it wou
Hi,
2011/12/2 Maris Nartiss :
> g.remove doesn't start GUI from CLI but works from wxgui. Nothing with
> WX_/DEBUG=5, exit code 0.
do you mean launch `g.remove` from wxGUI prompt without arguments? It
works for me.
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
___
Hi,
2011/12/2 Maris Nartiss :
> Unfortunately not all bugs are fixed. Tested with trunk r49481
nobody claimed that "all bugs are fixed". True is that it will be never true;-)
> Start v.clean from menu:
> Traceback (most recent call last):
> File "/home/maris/soft/grass_trunk/dist.x86_64-unknown
On Fri, Dec 2, 2011 at 5:36 AM, Dylan Beaudette
wrote:
> On Thu, Dec 1, 2011 at 1:25 AM, Markus Metz
> wrote:
>> Dylan Beaudette wrote:
>>> Just noticed a nasty bug when using v.db.dropcolumn and v.db.join with a
>>> sqlite back-end. This seems to happen whenever a table is modified using the
>>>
Hamish wrote:
> Markus Neteler wrote:
>> how about replacing r.los with r.viewshed?
>
>
> needs fixing:
>
> grass65/dist.i686-pc-linux-gnu/include/grass/iostream/replacementHeapBlock.h:146:
> warning: 'str' may be used uninitialized in this function
>
> (3 times).
Did you ever have a look at the
G. Allegri wrote:
> I resume (first as a repeat to myself) what I've learned from the various
> email on the topic
>
> Vectors can be:
>
> LEVEL 1:
> - no topology -> very limited use
> LEVEL 2:
> - unclean topology -> limited use
> - clean topology -> full support
>
> I previously thought that
16 matches
Mail list logo