Hi,
would it be difficult to remove the hardcoded limit of input files
of the r.patch module?
thanks
Markus
Markus Neteler wrote:
would it be difficult to remove the hardcoded limit of input files
of the r.patch module?
What limit? It was removed in 7.0 over two years ago:
http://trac.osgeo.org/grass/changeset/23499
and appears to have been backported.
The only limit should be any OS-imposed limit on the number of open files.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, Jul 23, 2009 at 4:48 AM, Glynn Clements<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
would it be difficult to remove the hardcoded limit of input files
of the r.patch module?What limit? It was removed in 7.0 over two years ago:
http://trac.osgeo.org/grass/changeset/23499
and appears to have been backported.
The only limit should be any OS-imposed limit on the number of open files.
Good.
But apparently it wasn't backported to 6.4.svn:
[neteler@localhost r.patch]$ pwd
/home/neteler/grass64_release/raster/r.patch
[neteler@localhost r.patch]$ grep MAXFILES *
nfiles.h: * Must be smaller than MAXFILES as defined in lib/gis/G.h which
nfiles.h:#define MAXFILES 200
Any objections to backport it? I want to avoid last minute breaks
but since it has been tested for 2 years...
Markus
On Thu, Jul 23, 2009 at 6:51 PM, Markus Neteler<neteler@osgeo.org> wrote:
On Thu, Jul 23, 2009 at 4:48 AM, Glynn Clements<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
would it be difficult to remove the hardcoded limit of input files
of the r.patch module?What limit? It was removed in 7.0 over two years ago:
http://trac.osgeo.org/grass/changeset/23499
and appears to have been backported.
The only limit should be any OS-imposed limit on the number of open files.
Good.
But apparently it wasn't backported to 6.4.svn:
Indeed it was.
I have now removed the cruft from the directory which essentially
confused me. All fine now.
Markus