> Glynn Clements <[EMAIL PROTECTED]> writes:
In my opinion, strncpy () should generally be preferred over
strcpy ().
>>> Using strncpy() isn't much of an improvement, as the copy won't be
>>> NUL-terminated if it's truncated. And simplyy NUL-terminating the
>>> string risks rea
Eric:
> Are there any instances where the dbf driver can do some
> functionality that the sqlite driver cannot? I use the sqlite driver
> all the time for my work with no problems.
DBF works "out of the box" on all platforms and is as well tested and
implimented as these things get. Its problems a
Hi gang,
Could anyone here be so kind as to provide a gentoo package for the most
recent 6.3.0RC4 release?
--Wolf
--
<:3 ) Wolf Bergenheim ( 8:>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/g
Hi,
you are right, thanks for pointing it out...
Fixed in svn-trunk
http://trac.osgeo.org/grass/changeset/29672
Martin
2008/1/11, Glynn Clements <[EMAIL PROTECTED]>:
>
> Markus Neteler wrote:
>
> > it appears that Martin has solved it. Still have to test.
>
> > Modified:
> >grass/trunk/lib
> Carlos:
> > I just compiled grass 6.3 from SVN. Everything seems to be OK, but
> > if I try to run wxgrass:
> >
> > GRASS 6.3.svn (amsul_wgs84):~ > wxgrass
> > GRASS 6.3.svn (amsul_wgs84):~ > Traceback (most recent call last):
> > File "/usr/local/grass-6.3.svn/etc/wx/wxgui.py", line 42, in
>
Martin Landa wrote:
> Hi devs,
>
> I would like to ask you for your opinion... to use sqlite as default
> db driver for grass64 (instead of dbf). What do you think?
For consistency I would suggest changing it for GRASS 7 but not GRASS
6.x.
Hamish
_
On Jan 11, 2008, at 1:23 PM, [EMAIL PROTECTED] wrote:
Message: 7
Date: Sat, 12 Jan 2008 02:23:16 +0600
From: Ivan Shmakov <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] sqlite and grass64
To: grass-dev@lists.osgeo.org
Cc: Ivan Shmakov <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Ty
Benjamin Ducke wrote:
> However, I'd like to add the ability to read field names
> from the ascii input file to v.in.ascii.
that would be nice.
> Should I add a flag to interpret the first line as
> field labels?
It appears the scanning step may be interesting as a separate little
program, or a
Michael Barton wrote:
> I don't know why I didn't see this before.
>
> It turned out to be simple to fix the problem with the Help > About
> System module. Someone had added a line ...
>
> source $env(GISBASE)/etc/gm/gm.tcl
>
> This line launched the GIS Manager every time About System was r
#15: Grass63 -wx gui menu item referes to incorrect function
-+--
Reporter: brian | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major | Milestone:
On Jan 11, 2008 10:31 PM, Glynn Clements <[EMAIL PROTECTED]> wrote:
>
> Markus Neteler wrote:
>
> > > > PS. Shouldn't G__open () use GPATH_MAX as well?
> > >
> > > Yes. And GNAME_MAX and GMAPSET_MAX.
> > >
> > > And it shouldn't be freeing the mapset either.
> >
> > Here are a couple of candidates
Markus Neteler wrote:
> it appears that Martin has solved it. Still have to test.
> Modified:
>grass/trunk/lib/gis/get_ellipse.c
> Log:
> Fixing memory leak in G_get_ellipsoid_parameters(), ticket #14
FWIW, I would consider moving the body of G_get_ellipsoid_parameters()
into a separate fun
#17: Grass63 -wx gui function v.in.ogr form not consistent with other wx gui
forms.
--+-
Reporter: brian | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
#16: Grass63 -wx gui function r.in.xyz form not consistent with other wx gui
forms.
---+
Reporter: brian | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Markus Neteler wrote:
> > > PS. Shouldn't G__open () use GPATH_MAX as well?
> >
> > Yes. And GNAME_MAX and GMAPSET_MAX.
> >
> > And it shouldn't be freeing the mapset either.
>
> Here are a couple of candidates:
>
> cd lib/gis/
> grep path *.c | grep char | grep -v GPATH_MAX | grep '\['
> clos
#15: Grass63 -wx gui menu item referes to incorrect function
-+--
Reporter: brian | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor | Milestone:
Hi,
2008/1/11, Carlos Guâno Grohmann <[EMAIL PROTECTED]>:
> I just compiled grass 6.3 from SVN. Everything seems to be OK, but if
> I try to run wxgrass:
>
> GRASS 6.3.svn (amsul_wgs84):~ > wxgrass
> GRASS 6.3.svn (amsul_wgs84):~ > Traceback (most recent call last):
> File "/usr/local/grass-6.3.
> Michael Barton <[EMAIL PROTECTED]> writes:
[...]
> AFAICT, SQLite has considerably more functionality than our current
> dbf driver. I like it for a lot of reasons. A couple issues to
> consider, however.
> dbf is a widely recognized file format that can be read or imported
> by very
I just compiled grass 6.3 from SVN. Everything seems to be OK, but if
I try to run wxgrass:
GRASS 6.3.svn (amsul_wgs84):~ > wxgrass
GRASS 6.3.svn (amsul_wgs84):~ > Traceback (most recent call last):
File "/usr/local/grass-6.3.svn/etc/wx/wxgui.py", line 42, in
import wx.aui
ImportError: No m
I think that one of the problems with the dbf driver is its limited
functionality. Mathematical operators, for instance, are not
implemented.
I think that SQlite as default would be nice, as long as a conversion
to dbf can be done, so the vectors could be exported as shapefiles
without any problem.
#15: Grass63 -wx gui menu item referes to incorrect function
--+-
Reporter: brian | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: minor
It seems impossible to doubt that everything in
the universe can be represented by numbers [...]
-- N. I. Lobachevsky
Reading ``Time series in GRASS'' page [1], as well as [2, 3],
made me wonder, is tim
On Jan 11, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:
Date: Fri, 11 Jan 2008 15:20:37 +0100
From: "Markus Neteler" <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] sqlite and grass64
To: "Martin Landa" <[EMAIL PROTECTED]>
Cc: GRASS developers list <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PR
Does it matter whether or not the html tags in the description.html files are
upper
or lower case? I've read that The W3C recommends lowercase tags in their HTML 4
recommendation,
and XHTML (the next generation HTML) demands lowercase tags. And if we're
trying to
standardize the docs anyway, i
Hi all,
sorry for cross-posting, from grass-web ML...
Martin
-- Forwarded message --
From: Wolf Bergenheim <[EMAIL PROTECTED]>
Date: 10-gen-2008 23.33
Subject: [GRASS-web] GRASS website migration - content types
To: GRASS-web <[EMAIL PROTECTED]>
Hi!
On Saturday I have schedule
>> I would like to ask you for your opinion... to use sqlite as default
>> db driver for grass64 (instead of dbf). What do you think?
>Yes, that would be very good. AFAIK:
>
>Functionality
>- it does all the DBF driver does and way more
>
>Portability
>- works on all common operating systems
>
>In
On Jan 11, 2008 2:26 PM, Martin Landa <[EMAIL PROTECTED]> wrote:
> Hi devs,
>
> I would like to ask you for your opinion... to use sqlite as default
> db driver for grass64 (instead of dbf). What do you think?
Yes, that would be very good. AFAIK:
Functionality
- it does all the DBF driver does an
Patch applied to SVN-HEAD.
Thanks, Ivan.
Markus
On Jan 7, 2008 10:27 AM, Ivan Shmakov <[EMAIL PROTECTED]> wrote:
> > Glynn Clements <[EMAIL PROTECTED]> writes:
>
> >> exec `g.region rast="$RAST"`
>
> > This is bogus on two counts. First, g.region doesn't output a shell
> > command, so the
>I would like to ask you for your opinion... to use sqlite as default
>db driver for grass64 (instead of dbf). What do you think?
>Martin
Are there any instances where the dbf driver can do some functionality
that the sqlite driver cannot? I use the sqlite driver all the time for
my work with no
Hi devs,
I would like to ask you for your opinion... to use sqlite as default
db driver for grass64 (instead of dbf). What do you think?
Martin
--
Martin Landa <[EMAIL PROTECTED]> * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev
On 11/01/08 09:51, Benjamin Ducke wrote:
Yes, it was meant for svn-trunk.
I just re-generated it and it works without fuzz on
my fresh SVN checkout (09:45 am CET).
Try the attached version if you like.
I will put work on this feature on hold until there is some
clarification whether these chang
Yes, it was meant for svn-trunk.
I just re-generated it and it works without fuzz on
my fresh SVN checkout (09:45 am CET).
Try the attached version if you like.
I will put work on this feature on hold until there is some
clarification whether these changes are actually wanted ...
However, I'd li
32 matches
Mail list logo
