date:20100317

Re: [GRASS-dev] color tables (legal aspects)

2010-03-17 Thread Hamish

Jarosław wrote:
> I created for my personal use some color tables almost
> identical to that of ESRI
> 
> I wonder about legal aspect of publish it as add-on. It is
> possible that these color schemes are not restricted, but
> there are lots of doubt.
> what you think about?

If it is a derivative of a creative work under copyright, then you are
bound by the terms of that copyright.

... which raises the question of is a color table a creative work?

For something simply like "byr" I find it hard to imagine that it is.
For something more complex like "rainbow" or "wave" it could start to be.
For something which is derived from a simple linear path through color-
space it would be hard to argue that the math is either a creative work
or original. (as long as you just followed the mathematical eqn.)

I would look at it likes notes of music. Three notes strung together
can hardly be called an original creative work. Once you have added
enough complexity to pull out a discernible melody though, it becomes a
different situation.

hope it helps,
Hamish

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

[GRASS-dev] Fwd: [GRASS-user] How to embed a grass script (for example v.db.addcol) into a Pythonscript on windows?

2010-03-17 Thread Michael Barton

Glynn,

A couple of students are trying to run python in wingrass now, following your 
directions below. They installed python, but we're not sure where to put #4 in 
your steps.

>> 4. PYTHONPATH needs to be set to %WINGISBASE%\etc\python

It seems like it ought to go into the "grass64svn" initialization file

That file has the following lines...

PYTHONPATH="$GISBASE/etc/python:$GISBASE/Python25:$PYTHONPATH"
export PYTHONPATH
PYTHONHOME="C:\Program Files\GRASS-64-SVN\Python25"

Does it go there? With quotes? What about changing PYTHONHOME?

Is this the wrong place?

When we've changed the PYTHONPATH line in grass64svn and tried to run python 
from the msys prompt in GRASS, nothing happens. That is, the prompt goes away 
and returns a blank line. You can type on that line, but nothing returns.

What are we missing?

Thanks
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-727-9746 (CSDC)
fax:  480-965-7671 SHESC),  480-727-0709 (CSDC)
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Begin forwarded message:

>> From: Glynn Clements 
>> Date: March 4, 2010 2:48:49 PM MST
>> To: Michael Barton 
>> Cc: grass-user grass-user , GRASS developers 
>> list 
>> Subject: Re: [GRASS-user] How to embed a grass script (for example 
>> v.db.addcol) into a Pythonscript on windows?
>> 
>> 
>> Michael Barton wrote:
>> 
>>> This implies that it is now possible to create python scripts that run in 
>>> GRASS under windows??? 
>>> 
>>> That would be great news. Is there anything special that is needed for this 
>>> to work?
>> 
>> 1. The Python interpreter (python.exe) needs to be in the PATH
>> 2. Python needs to be associated with the .py extension
>> 3. PATHEXT needs to include .py if you want to be able to omit the extension
>> 4. PYTHONPATH needs to be set to %WINGISBASE%\etc\python
>> 
>> 1-3 should be taken care of by the Python installer. 4 needs to be
>> done by the startup (currently, this doesn't appear to be the case on
>> Windows).
>> 
>> -- 
>> Glynn Clements 
> 

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

[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to create temp file on Windows when launched from wxgui

2010-03-17 Thread GRASS GIS

#1006: r.terraflow fails to create temp file on Windows when launched from wxgui
--+-
  Reporter:  marisn   |   Owner:  grass-dev@lists.osgeo.org 
  Type:  defect   |  Status:  new   
  Priority:  normal   |   Milestone:  6.4.0 
 Component:  Raster   | Version:  svn-releasebranch64   
Resolution:   |Keywords:  wxgui, wingrass, terraflow
  Platform:  MSWindows Vista  | Cpu:  x86-32
--+-
Comment (by hellik):

 Replying to [comment:3 hamish]:
 > what does "r.terraflow --help" say ?

 {{{
 GRASS 6.4> r.terraflow --help

 Beschreibung:
  Flow computation for massive grids (Float version).

 Schlüsselwörter:
  Raster

 Benutzung:
  r.terraflow [-sq] elevation=name filled=name direction=name
swatershed=name accumulation=name tci=name [d8cut=value]
[memory=value] [STREAM_DIR=string] [stats=string] [--overwrite]
[--verbose] [--quiet]

 Flags:
   -s   SFD (D8) flow (default is MFD)
   -q   schweigsam
  --o   Ausgabedateien dürfen bereits existierende Dateien überschreiben.
  --v   Detaillierter Ausgabemodus
  --q   Schweigsame Modulausgabe

 Parameter:
  elevation   Name der Höhenkarte.
 filled   Output filled (flooded) elevation raster map
  direction   Output flow direction raster map
 swatershed   Output sink-watershed raster map
   accumulation   Output flow accumulation raster map
tci   Output topographic convergence index (tci) raster map
  d8cut   If flow accumulation is larger than this value it is
 routed using SFD (D8) direction
  (meaningfull only  for MFD flow)
   Standard: infinity
 memory   Maximum runtime memory size (in MB)
   Standard: 300
 STREAM_DIR   Directory to hold temporary files (they can be large)
   Standard: C:/Users/syringia/AppData/Local/Temp
  stats   Name of file containing runtime statistics
   Standard: stats.out
 }}}


 >
 > (specifically the STREAM_DIR section)
 >
 >
 > {{{
 >   /* temporary STREAM path */
 >   struct Option *streamdir;
 >   streamdir = G_define_option() ;
 >   streamdir->key= "STREAM_DIR";
 >   streamdir->type   = TYPE_STRING;
 >   streamdir->required   = NO;
 > #ifdef __MINGW32__
 >   streamdir->answer =
 G_convert_dirseps_from_host(G_store(getenv("TEMP")));
 > #else
 >   streamdir->answer = G_store("/var/tmp/");
 > #endif
 >   streamdir->description=
 >  _("Directory to hold temporary files (they can be large)");
 > }}}
 >
 >
 > Maris:
 > > Aaah - just noticed - could this be related to #520?
 >
 > probably not as that should be already fixed. (just not ideal)
 >
 >
 > can you try on a small (file size) raster like elevation.dem @
 Spearfish? (existing 300mb doesn't seem so bad though)

 nc-data set:

 {{{
 g.region -p -a rast=el_d782...@permanent
 projection: 99 (Lambert Conformal Conic)
 zone:   0
 datum:  nad83
 ellipsoid:  a=6378137 es=0.006694380022900787
 north:  222504.44509601
 south:  219456.439
 west:   633985.268
 east:   637033.27409601
 nsres:  6.09601219
 ewres:  6.09601219
 rows:   500
 cols:   500
 cells:  25
 }}}

 >
 >
 > can you try with --verbose so percent done is shown for nrows and we get
 more details?
 >
 >
 > Hamish

 {{{
 g.gisenv set=DEBUG=3
 }}}

 {{{
 r.terraflow --verbose elevation=el_d782...@permanent filled=floodeda
 direction=dirr swatershed=swat accumulation=accr tci=topgr
 D2/3: G__read_Cell_head
 D2/3: G__read_Cell_head_array
 D3/3: region item: proj:   99
 D3/3: region item: zone:   0
 D3/3: region item: north:  222504.44509601
 D3/3: region item: south:  219456.439
 D3/3: region item: east:   637033.27409601
 D3/3: region item: west:   633985.268
 D3/3: region item: cols:   500
 D3/3: region item: rows:   500
 D3/3: region item: e-w resol:  6.09601219
 D3/3: region item: n-s resol:  6.09601219
 D3/3: region item: top:1
 D3/3: region item: bottom: 0
 D3/3: region item: cols3:  500
 D3/3: region item: rows3:  500
 D3/3: region item: depths: 1
 D3/3: region item: e-w resol3: 6.09601219
 D3/3: region item: n-s resol3: 6.09601219
 D3/3: region item: t-b resol:  1
 D2/3: G__read_Cell_head
 D2/3: G__read_Cell_head_array
 D3/3: region item: proj:   99
 D3/3: region item: zone:   0
 D3/3: region item: north:  222504.44509601
 D3/3: region item: south:  219456.439
 D3/3: region item: east:   637033.27409601
 D3/3: region item: west:   633985.268
 D3/3: region item: cols:   500
 D3/3: region item: rows:   500
 D3/3: region item: e-w resol:  6.09601219
 D3/3: region item: n-s resol:  6.09601219
 D3/3: region item: format: -1
 D3/3: region item: c

Re: [GRASS-dev] Exploit.DEM in conftest.exe

2010-03-17 Thread Jan Tosovsky

Hi Glynn,

> > after some time I've updated my local 'grss6_devel' branch and during
> > building (in the initial configuration step) I am getting warning
> from my
> > antivirus app (AVG 9) that in
> OSGeo4W\usr\src\grass6_devel\conftest.exe
> > there is potentially harmfull program Exploit.DEM.
> >
> > I've tried to find the file in this path on my disk but without any
> success
> > (it is not present also in a 'safe-deposit'). Can I ignore this
> message?
> 
> "conftest.exe" is the default name of any test programs created by the
> configure script (on Windows; on other platforms, it's just called
> "conftest").
> 
> Most of the test programs aren't even executed; configure simply
> attempts to compile and link a test program in order to check that the
> compilation and linking switches are correct. The programs are deleted
> once the test is complete.
> 
> If the program isn't being run (only a handful are), the test will
> succeed so long as the linker doesn't return an error status. I
> suspect that AVG probably won't scan the file until it's complete, so
> the test should succeed even if AVG deletes or quarantines the file.

Ok, I'll ignore it. It is listed 3 times in a total. I've just found there
is additional info for each item - there is written this file was detected
2x for process sh.exe and once for rm.exe. 

My build has failed later on so I thought it is consequence of this issue.
I'll describe my problem in a separate thread.

Thanks,
Jan

PS: Please don't generate exploits during configuration anymore ;-) 

PS2: This message was mistakenly sent directly to Glynn. Sorry.

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

RE: [GRASS-dev] Unable to locate Tcl library

2010-03-17 Thread Jan Tosovsky

Thanks for this exhaustive explanation! This clarified what was going on.

Seeing the result:
configure:759: checking host system type
configure:782: checking for gcc
configure:886: checking whether the C compiler (gcc  ) works
configure:902: gcc -o conftestconftest.c  1>&5
configure:928: checking whether the C compiler (gcc  ) is a cross-compiler
configure:933: checking whether we are using GNU C

one can register launching conftest file. 

Yes, this is the consequence of a problem described in the another thread:
Exploit.DEM in conftest.exe

My antivirus is blocking this file so the configuration script fails to
evaluate cross-compiling settings properly.

I've added affected path into the list of exceptions and now it seems to be
Ok.

Thanks,
Jan

> -Original Message-
> From: Glynn Clements [mailto:gl...@gclements.plus.com]
> Sent: Wednesday, March 17, 2010 11:04 AM
> To: Jan Tosovsky
> Cc: grass-dev@lists.osgeo.org
> Subject: Re: [GRASS-dev] Unable to locate Tcl library
> 
> 
> Jan Tosovsky wrote:
> 
> > the last month everything was Ok when I was building Grass from
> sources
> > (according to [1]) on my Win7 64bit. Now the build fails in a
> configuring
> > phase and an error message "Unable to locate Tcl library." appears.
> To tell
> > the truth, I cannot confirm if the final build was Tcl ready as I use
> > wxPython GUI by default.
> >
> > I've found several Tcl libraries on my PC (version 8.5.2) so it is
> weird.
> > Was there any refactoring in the meantime? Is it any kind of
> regression or
> > am I missing something?
> >
> > Here is the snippet of a console output:
> 
> > checking Tcl version... unknown (cross-compiling)
> > checking Tk version... unknown (cross-compiling)
> 
> Are you actually cross-compiling?
> 
> configure decides if you're cross-compiling by compiling and executing
> the program:
> 
>   #include "confdefs.h"
>   main(){return(0);}
> 
> If it fails to compile, you get "C compiler cannot create executables".
> If it compiles but cannot be executed, configure assumes that you're
> cross-compiling.
> 
> > checking for location of Tcl/Tk library...
> > checking for Tcl_Init in -ltcl... no
> > checking for Tcl_Init in -ltcl... no
> > checking for Tcl_Init in -ltclUNKNOWN... no
> > checking for Tcl_Init in -ltclUNKNOWN... no
> > checking for Tcl_Init in -ltclUNKNOWN... no
> > checking for Tcl_Init in -ltclUNKNOWN... no
> > configure: error: *** Unable to locate Tcl library.
> 
> The configure script checks for the Tcl/Tk version by compiling and
> executing a test program which does:
> 
>   FILE *fp = fopen("conftestdata","w");
>   fputs(TCL_VERSION, fp);
> 
> If you're cross-compiling, it can't run the executables which the
> compiler generates, so it can't detect the version. If the library name
> contains the version number (e.g. libtcl85.a), you lose. You can get
> around this by making a copy of the library with the correct name.
> 
> However, I'm guessing that you're not actually cross-compiling, and the
> problem is that configure thinks that you are.
> 
> Look at the top of the config.log file; the first few lines should look
> something like:
> 
>   This file contains any messages produced by compilers while
>   running configure, to aid debugging if configure makes a mistake.
> 
>   configure:754: checking host system type
>   configure:777: checking for gcc
>   configure:881: checking whether the C compiler (gcc -g -O2) works
>   configure:897: gcc -o conftest -g -O2 conftest.c  1>&5
>   configure:894: warning: return type defaults to 'int'
>   configure:923: checking whether the C compiler (gcc -g -O2) is a
> cross-compiler
>   configure:928: checking whether we are using GNU C
> 
> If there are any errors there, please post the beginning of the file
> (everything up to "checking whether we are using GNU C").
> 
> --
> Glynn Clements 

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

Re: [GRASS-dev] color tables (legal aspects)

2010-03-17 Thread Jarosław Jasiewicz


Hi

I created for my personal use some color tables almost identical to that 
of ESRI


I wonder about legal aspect of publish it as add-on. It is possible that 
these color schemes are not restricted, but there are lots of doubt.

what you think about?

regards
Jarek




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

[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to create temp file on Windows when launched from wxgui

2010-03-17 Thread GRASS GIS

#1006: r.terraflow fails to create temp file on Windows when launched from wxgui
--+-
  Reporter:  marisn   |   Owner:  grass-dev@lists.osgeo.org 
  Type:  defect   |  Status:  new   
  Priority:  normal   |   Milestone:  6.4.0 
 Component:  Raster   | Version:  svn-releasebranch64   
Resolution:   |Keywords:  wxgui, wingrass, terraflow
  Platform:  MSWindows Vista  | Cpu:  x86-32
--+-
Comment (by hamish):

 what does "r.terraflow --help" say ?

 (specifically the STREAM_DIR section)


 {{{
   /* temporary STREAM path */
   struct Option *streamdir;
   streamdir = G_define_option() ;
   streamdir->key= "STREAM_DIR";
   streamdir->type   = TYPE_STRING;
   streamdir->required   = NO;
 #ifdef __MINGW32__
   streamdir->answer =
 G_convert_dirseps_from_host(G_store(getenv("TEMP")));
 #else
   streamdir->answer = G_store("/var/tmp/");
 #endif
   streamdir->description=
  _("Directory to hold temporary files (they can be large)");
 }}}


 Maris:
 > Aaah - just noticed - could this be related to #520?

 probably not as that should be already fixed. (just not ideal)


 can you try on a small (file size) raster like elevation.dem @ Spearfish?
 (existing 300mb doesn't seem so bad though)


 can you try with --verbose so percent done is shown for nrows and we get
 more details?


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #962: wxGUI crash when moving an undocked map display toolbox

2010-03-17 Thread GRASS GIS

#962: wxGUI crash when moving an undocked map display toolbox
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-releasebranch64  
Resolution:|Keywords:   
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by martinl):

 Unable to reproduce it. Undocking works.

 6.4 branch, r41467, Debian unstable 32bit, python 2.5.5, wx 2.8.10.1 (
 gtk2-unicode)

 Please try to upgrade your wx libs.

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

Re: [GRASS-dev] color tables

2010-03-17 Thread Glynn Clements


Hamish wrote:

> > I am just going through some old emails and I am wondering whether there 
> > was a reason why the images illustrating the pre-defined color tables 
> > generated by Hamish and available on wiki 
> > 
> > http://grass.osgeo.org/wiki/Raster_color_tables
> > 
> > could not be included directly into the man page
> > http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
> > or is this just an unfinished thread.
> 
> done by Glynn for GRASS 7:
>   http://grass.osgeo.org/grass70/manuals/html70_user/r.colors.html
> 
> (I notice dynamic ones are broken [random, grey.log, grey.eq])

Fixed in r41464.

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

[GRASS-dev] [GRASS GIS] #1014: wxgui: display labels doesn't work

2010-03-17 Thread GRASS GIS

#1014: wxgui: display labels doesn't work
--+-
 Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
 Type:  defect|  Status:  new  
 Priority:  major |   Milestone:  6.4.0
Component:  wxGUI | Version:  svn-develbranch6 
 Keywords:  d.labels  |Platform:  Linux
  Cpu:  x86-32|  
--+-
 as reported on grass-user:

 {{{
 > I find the label layer I generated with v.label.
 > Here I get this error message:
 >
 > --%<--
 > Error
 > Map <> not found.
 > --%<--
 }}}


 spearfish example:

 add grid or labels overlay button -> add labels -> name of label file ->
 rush.lbl -> [ok]

 then you get the error shown above.



 see `OnAddLabels()` in wxgui.py and gui_modules/wxgui_utils.py


 Hamish

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

Re: [GRASS-dev] Unable to locate Tcl library

2010-03-17 Thread Glynn Clements

Jan Tosovsky wrote:

> the last month everything was Ok when I was building Grass from sources
> (according to [1]) on my Win7 64bit. Now the build fails in a configuring
> phase and an error message "Unable to locate Tcl library." appears. To tell
> the truth, I cannot confirm if the final build was Tcl ready as I use
> wxPython GUI by default.
> 
> I've found several Tcl libraries on my PC (version 8.5.2) so it is weird.
> Was there any refactoring in the meantime? Is it any kind of regression or
> am I missing something?
> 
> Here is the snippet of a console output:

> checking Tcl version... unknown (cross-compiling)
> checking Tk version... unknown (cross-compiling)

Are you actually cross-compiling?

configure decides if you're cross-compiling by compiling and executing
the program:

#include "confdefs.h"
main(){return(0);}

If it fails to compile, you get "C compiler cannot create executables". 
If it compiles but cannot be executed, configure assumes that you're
cross-compiling.

> checking for location of Tcl/Tk library... 
> checking for Tcl_Init in -ltcl... no
> checking for Tcl_Init in -ltcl... no
> checking for Tcl_Init in -ltclUNKNOWN... no
> checking for Tcl_Init in -ltclUNKNOWN... no
> checking for Tcl_Init in -ltclUNKNOWN... no
> checking for Tcl_Init in -ltclUNKNOWN... no
> configure: error: *** Unable to locate Tcl library.

The configure script checks for the Tcl/Tk version by compiling and
executing a test program which does:

FILE *fp = fopen("conftestdata","w");
fputs(TCL_VERSION, fp);

If you're cross-compiling, it can't run the executables which the
compiler generates, so it can't detect the version. If the library name
contains the version number (e.g. libtcl85.a), you lose. You can get
around this by making a copy of the library with the correct name.

However, I'm guessing that you're not actually cross-compiling, and the
problem is that configure thinks that you are.

Look at the top of the config.log file; the first few lines should look
something like:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:754: checking host system type
configure:777: checking for gcc
configure:881: checking whether the C compiler (gcc -g -O2) works
configure:897: gcc -o conftest -g -O2 conftest.c  1>&5
configure:894: warning: return type defaults to 'int'
configure:923: checking whether the C compiler (gcc -g -O2) is a 
cross-compiler
configure:928: checking whether we are using GNU C

If there are any errors there, please post the beginning of the file
(everything up to "checking whether we are using GNU C").

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

[GRASS-dev] Re: [GRASS GIS] #1008: WinGrass7 - disable LFS

2010-03-17 Thread GRASS GIS

#1008: WinGrass7 - disable LFS
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Compiling| Version:  svn-trunk
Resolution:   |Keywords:  wingrass 
  Platform:  MSWindows Vista  | Cpu:  x86-32   
--+-
Comment (by glynn):

 Replying to [comment:10 hellik]:

 > embedding the manifests in the executables works quite well, no
 compiling errors for v.patch, r.patch r.li.patchdensity,r.li.patchnum etc.
 and no working/executing errors for v.patch, r.patch.

 > so maybe the embedded manifests would be also an option for grass64?  I
 see that with the embedded manifests the v.patch/r.patch-executables are
 no longer marked with a mswindows-symbol like the executables without any
 manifests/with external manifests. so maybe the approach embedding the
 manifest would be better way?

 It would probably be the better approach, but I don't know how easy it
 would be. The build system has been cleaned up a lot in 7.0; there were
 only a handful of executables which required special treatment, the rest
 being handled automatically by changes to Compile.make. The 6.x Makefiles
 have far more special cases.

 A large part of the problem is that 6.x tries to support older versions of
 GNU make, while 7.0 requires version 3.81. That might not seem like much
 of a constraint, given that 3.81 has been out for nearly four years, but
 both MacOSX and MSys were using 3.79 (nearly ten years old) until fairly
 recently.

 If someone wants to try back-porting the changes to 6.x: for normal
 modules, you would just need to modify the linking rule for
 $(BIN)/$(PGM)$(EXE) in Module.make. But you'll find dozens of programs
 with their own linking commands in their Makefiles (grep for LDFLAGS). You
 can check whether an executable has an embedded manifest by running
 "objdump -h" on it and looking for a ".rsrc" section.

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

Re: [GRASS-dev] Unable to locate Tcl library

2010-03-17 Thread Markus Neteler

Jan,

On Wed, Mar 17, 2010 at 12:12 AM, Jan Tosovsky  wrote:
...
> PS: When I was looking for the remedy of my problem, I found a strange
> target URL [2] on the list of mailing lists [3].
...
> [2] http://www.nabble.com/ BAD GRASS-f1200.html

Yes, the old nabble forum was flooded, the correct address is

http://n2.nabble.com/GRASS-f1837859.html

> [3] http://grass.osgeo.org/searchgrass.php

Ah, thanks for pointing out, updated.

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

Re: [GRASS-dev] grass 6.4.0rc6

2010-03-17 Thread Martin Landa

Hi,

2010/3/16 Markus Neteler :
> after an interim datum detection desaster which has been fixed, I wonder
> if we could get out RC6 NOW :)
>
> ok?

seems to be OK for me.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables (legal aspects)

[GRASS-dev] Fwd: [GRASS-user] How to embed a grass script (for example v.db.addcol) into a Pythonscript on windows?

[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to create temp file on Windows when launched from wxgui

Re: [GRASS-dev] Exploit.DEM in conftest.exe

RE: [GRASS-dev] Unable to locate Tcl library

Re: [GRASS-dev] color tables (legal aspects)

[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to create temp file on Windows when launched from wxgui

[GRASS-dev] Re: [GRASS GIS] #962: wxGUI crash when moving an undocked map display toolbox

Re: [GRASS-dev] color tables

[GRASS-dev] [GRASS GIS] #1014: wxgui: display labels doesn't work

Re: [GRASS-dev] Unable to locate Tcl library

[GRASS-dev] Re: [GRASS GIS] #1008: WinGrass7 - disable LFS

Re: [GRASS-dev] Unable to locate Tcl library

Re: [GRASS-dev] grass 6.4.0rc6

14 matches

Site Navigation

Mail list logo

Footer information