Gerald Nelson wrote:
> ... speaking of canned binaries for windows, are there any new ones
> that include wxgrass or whatever we are calling the new gui?
I suspect that once 6.3.0 is released there will be. But there are/were
some instances of UNIXisms in the new GUI, which early adopters will
ha
> > I am not sure of what the logic is supposed to be if the current
> > GRASS_GUI setting was "text" or unset? Why bother with that at all?
> > The type= answer has to be one of the GUIs.
> > Note that strcmp() returns 0 if the strings are the same.
>
> The initial idea was to set type->answer to
Hi,
strange, I just tried out under Linux, works fine :-/ The vector map you
want to produce seems to be created anyway.
Maybe adding
G_percent(nelements, nelements, 1);
at the end of the module would help?
Jachym
Sampson, David píše v Út 12. 02. 2008 v 15:57 -0500:
> Hey folks.
>
> I want
On Tuesday 12 February 2008, Glynn Clements wrote:
> Dylan Beaudette wrote:
> > However-- this is starting to get into the realm of feature bloat...
> > As neat as it would be to have R routines which could work directly on
> > GRASS data structures, it might be overkill considering the possible
>
#33: config.in: cairo and ffmpeg checks
--+-
Reporter: hamish | Owner: glynn
Type: task | Status: closed
Priority: minor| Milestone: 6.4.0
Component: default | Version:
#37: r.in.xyz increase region based on input data
--+-
Reporter: marisn | Owner: hamish
Type: enhancement | Status: closed
Priority: minor| Milestone: 6.4.0
Component
On Feb 12, 2008 9:25 PM, Glynn Clements <[EMAIL PROTECTED]> wrote:
>
> Michael Barton wrote:
>
> > I just ran into a couple modules that choke on [EMAIL PROTECTED]:
> >
> > v.rast.stats
>
> # does map exist in CURRENT mapset?
> eval `g.findfile element=vector file="$VECTOR" mapset="
To make this work better with the GUI parser and not generate an
error, the script should just strip off the @mapset portion of the name.
Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Ch
@mapset just helps specify which mapset a map is in. That is, if you
have a map named elevation in mapset PERMANENT and another one named
elevation in mapset 'newmaps', specifying [EMAIL PROTECTED] and
[EMAIL PROTECTED] will differentiate between the two.
In the case of the error for v.rast
Dylan Beaudette wrote:
> However-- this is starting to get into the realm of feature bloat...
> As neat as it would be to have R routines which could work directly on
> GRASS data structures, it might be overkill considering the possible
> amount of work. I'll keep checking around and post back o
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Feb 12, 2008, at 12:17 PM, [EMAIL PROTECTED] wrote:
Date: Tue, 12 Feb 2008 18:20:21 +0100
From: Jarek Jasiewicz <[EMAIL PROTECTED]>
Subject: [GRASS-user] v.rast.stats error
To: [EMAIL PROTECTED]
Message-ID: <[EM
Michael Barton wrote:
> I just ran into a couple modules that choke on [EMAIL PROTECTED]:
>
> v.rast.stats
# does map exist in CURRENT mapset?
eval `g.findfile element=vector file="$VECTOR" mapset="$MAPSET"`
if [ ! "$file" ] ; then
g.message -e "Vector map <$V
> GRASS GIS <[EMAIL PROTECTED]> writes:
> Comment (by glynn):
Thanks for a quick response!
> Replying to [comment:1 1gray]:
>> Shouldn't therefore {{{r.rast}}} be replaced by a (supposedly
>> simpler) Shell script?
> No. For a start, v.what.rast only accepts a single raster m
Hamish wrote:
> Also that calls G_store() before G_parser(), and G_store() calls
> G_malloc() which can call G_fatal_error(), which must not be called
> before G_parser() has been called.
Note that G_define_option() also calls G_malloc(), and
G_define_option() only makes sense *before* calling G
#32: r.what: shouldn't use static buffers for the inputs
--+-
Reporter: 1gray| Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor| Milestone:
On Tuesday 12 February 2008, Dylan Beaudette wrote:
> On Feb 11, 2008 7:30 PM, Hamish <[EMAIL PROTECTED]> wrote:
> > Dylan wrote:
> > > However, an hour spent tinkering around with the R shared lib
> > > examples left me mostly frustrated
> >
> > From the everything looks like a nail dept:
> >
#31: NVIZ in GRASS6.2.3 (some problems)
--+-
Reporter: clerici | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
On Feb 11, 2008 7:30 PM, Hamish <[EMAIL PROTECTED]> wrote:
> Dylan wrote:
> > However, an hour spent tinkering around with the R shared lib
> > examples left me mostly frustrated
>
> From the everything looks like a nail dept:
> Does R offer SWIG bindings into the lib that we could use with pyt
I just ran into a couple modules that choke on [EMAIL PROTECTED]:
v.rast.stats
v.db.addtable
Perhaps there are others. Can these be updated to accept the
[EMAIL PROTECTED] form?
Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate St
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Feb 12, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:
Date: Tue, 12 Feb 2008 14:28:55 +0100
From: Nikos Alexandris <[EMAIL PROTECTED]>
Subject: Re: [GRASS-user] wxgui issue ( No module named wx)
To: Carlos "Gu?no"
... speaking of canned binaries for windows, are there any new ones that
include wxgrass or whatever we are calling the new gui?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Frank Warmerdam
Sent: Tuesday, February 12, 2008 9:59 AM
To: [EMAIL PROTECTED]
Hi,
2008/2/12, Hamish <[EMAIL PROTECTED]>:
> Martin Landa wrote:
> > 4. write g.gui module (draft)
> >
> > g.gui now in trunk (not compiled by default)
> I made a few changes; e.g. added a flag to skip resetting the default.
> It's a good start.
Thanks for enhancements...
> I am not sure of wh
[EMAIL PROTECTED] wrote:
Hi,
mybe these are boring questions for you, but I need to have a clear view
before to proceed (the following intended for Win32 under MinGW).
1) I tried to build latest PROJ (4.6) but, for ibscure reasons, it
doesn't create libraries. There are essential reasons to
Hi,
mybe these are boring questions for you, but I need to have a clear view before
to proceed (the following intended for Win32 under MinGW).
1) I tried to build latest PROJ (4.6) but, for ibscure reasons, it doesn't
create libraries. There are essential reasons to move to 4.6 or can I quiet
On Feb 11, 2008, at 11:41 PM, [EMAIL PROTECTED] wrote:
Date: Mon, 11 Feb 2008 18:53:13 -0800 (PST)
From: Hamish <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] Re: include wxgrass or not in 6.3.0
To: Paul Kelly <[EMAIL PROTECTED]>
Cc: grass-dev@lists.osgeo.org
Message-ID: <[EMAIL PROTECTED]>
Conte
Hi,
2008/2/11, Glynn Clements <[EMAIL PROTECTED]>:
> Martin Landa wrote:
> > > In any case, that's why we need to allow e.g.
> > > --with-python=python2.4-config
> > >
> > > > I will upgrade configure to check also for python${PYVERSION}-config.
> > >
> > > Where are you going to get ${PYVERSION}
Hi,
I'm updating GRASS required Win32 libraries, downloading them from
SourceForge.net when possible; for libpng, for example, I have the following
packages available:
- libpng-1.2.24-bin.zip
- libpng-1.2.24-dep.zip
- libpng-1.2.24-lib.zip
which stands for, in order, binaries, dependencies
#32: r.what: shouldn't use static buffers for the inputs
--+-
Reporter: 1gray| Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor| Milestone:
#49: NVIZ displays points (sites) allways as thematic
--+-
Reporter: marisn| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.
The use of `cat' is unnecessary in `Doxygen.make' (see, e. g.,
[1].) Please consider the following patch.
[1] http://sial.org/howto/shell/useless-cat/
diff --git a/include/Make/Doxygen.make b/include/Make/Doxygen.make
index 4a6a228..9f912c0 100644
--- a/include/Make/Doxygen.make
#31: NVIZ in GRASS6.2.3 (some problems)
--+-
Reporter: clerici | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
Hi,
2008/2/12, Hamish <[EMAIL PROTECTED]>:
> Paul Kelly wrote:
> > Yes, and don't all the new features include many usability
> > improvements and feature enhancements to the Tcl/TK GUI parts
> > since the last stable release? I would worry that with all the talk
> > about wxgui these are going to
Martin Landa wrote:
> 4. write g.gui module (draft)
>
> g.gui now in trunk (not compiled by default)
Hi,
I made a few changes; e.g. added a flag to skip resetting the default.
It's a good start.
some comments:
I am not sure of what the logic is supposed to be if the current
GRASS_GUI settin
On Mon, 11 Feb 2008, Michael Barton wrote:
We've just had some instances where people made new location from
georeferenced file or from running r.in.gdal and the PROJ_INFO and PROJ_UNIT
files weren't made--although the location was created with no problems. I
just tried this with an SRTM geoti
Currently, the most of the macro definitions in `aclocal.m4'
have the macro name unquoted. This coding style is error-prone;
consider, e. g.:
$ cat foo.m4
define(foo, `bar')dnl
define(foo, `baz')dnl
`foo' => foo
`bar' => bar
$ m4 foo.m4
foo => baz
bar => baz
$
#48: r.sim.*: use G_command_history()
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: task | Status: new
Priority: minor| Milestone: 6.4.0
36 matches
Mail list logo
