Brad ReDacted wrote:
> Can someone tell me what spec the (enhanced) postscript driver
> (lib/psdriver) adheres to? I am having difficulty looking up one of the
> parameters (box erase, in particular - erase.c).
>
> I found references to PostScript levels, but no mention of EPS, which is
>
Vaclav Petras wrote:
> To be sure removing it completely is a good step, I wanted to check the
> original motivation. Any ideas? The commit message doesn't mention the
> motivation and I'm not getting anything from Internet searches.
Dependencies. GDAL has lots of them. If libraster is linked
Nicklas Larsson via grass-dev wrote:
> I personally never had the need for the use of GRASS in this way, so forgive
> my ignorance in this regard.
> However, one thing stands out very clear from my newly gained experience:
> there is a lack of documentation on this use of GRASS_NOTIFY. For
Nicklas Larsson via grass-dev wrote:
> Is there anyone out there who know about usage of the environment
> variable GRASS_NOTIFY, historically and in the present?
It's an external interface; it isn't used internally.
The intention is described in the email you cited: to allow a program
d doesn't actually support the use of weights.
--
Glynn Clements
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
oup.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
me, you can use "ulimit -n " to
increase the soft limit up to the hard limit (on my system, the soft
limit is 1024, the hard limit is 4096).
If you're at the hard limit, you can ask your sysadmin to increase it,
typically via /etc/security/limits.conf.
Increasing the limit won't have th
ted interfaces still exist and still matter,
and will do so for the foreseeable future.
Python's solution is to accelerate standardisation on Unicode by
making the alternatives as painful as possible. Yet legacy encodings
remain widespread
--
Glynn Clements <gl...@gclements.plus.com>
sed by the "C" locale, so even if LC_NUMERIC
gets set (and it shouldn't), that shouldn't affect it.
Is this issue a wxGUI thing?
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
s computationally expensive.and rarely necessary.
I'm just suggesting that it might be useful if there was some way to
get that information, other than by creating maps containing latitude
and longitude values, projecting those with r.proj, then using
r.mapcalc to calculate the area (or other prope
issue is an appropriate choice of delta. Too large a value
means that you're calculating an average over a non-negligible
distance, too small a value means that you lose accuracy due to
subtracting numerically-close values.
--
Glynn Clements <gl...@gclements
IW, the "My Documents" location can be obtained by querying the
registry key
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell
Folders\Personal
then expanding the result; the default value is "%USERPROFILE\Documents".
--
Glynn Clements <gl...@g
as a fallback on Windows) and it's
used for G_rc_path() on Windows (for some reason, the Unix version
uses getpwuid(), which is probably incorrect in this context).
It may also be used implicitly by library functions or external
programs looking for configuration files.
--
G
y uses them. The check is just a
heuristic; a directory containing a PERMANENT/DEFAULT_WIND file is
probably a GRASS location, while a directory lacking it probably
isn't. I'm not sure whether X-Y locations would even have a PROJ_INFO
file.
--
Glynn Clements <gl...@gclements.plus.com>
It may be that we need separate LINK_FLAGS variables for C and C++
programs.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
e time if you set it
> to the exactly same value (`hue = -1;`),
There's no "probably" about it. If you execute "hue = -1;", a
subsequent "if (hue == -1)" comparison *will* succeed.
Rounding error only occurs when the correct result isn't exactly
representable, wh
C_PATH_XTRA may have some hardwired defaults,
some of the other tests use pkgconf by default.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
n the
absence of any additional transformations, I believe that this means
pixels).
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
187, in _create_ld_so_cache
> for path in glob.glob("%s/*.s[ol]*" % dir):
> TypeError: __init__() takes exactly 4 arguments (2 given)
This seems to suggest that it's picking up some other "glob" module,
rather than the one in the standard library.
Does running the s
, compression needs to be a conscious decision.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
hat you'll need to add $(INTLINC) to ... something. probably
Either INC (in Grass.make) or NLS_CFLAGS (in Compile.make). Adding it
to individual Makefiles isn't feasible because is included
from , which is included by practically everythi
th better
precision than FCELL (32 bits rather than 24) and less space than
DCELL. It's quite rare for physical measurements to be sufficiently
accurate that 32 bits isn't enough.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing
detach() method returns the underlying byte stream *after*
detaching it from the TextIOWrapper, to avoid any issues arising from
attempting to use both.]
Anything using the script module should be using byte strings
throughout (in spite of how awkward Python 3 tries to make this).
--
Glynn Clements &l
two streams will be separated should provide
some clues as to which is appropriate for any given case.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Pietro wrote:
> Perhaps we could decorate the function with contextmanager:
That's an option, but it complicates matters in the (probably more
common) case where you just want to use a single temporary region for
the entire script.
--
Glynn Clements <gl...@gclements.pl
ame, overwrite=True)
os.environ['WIND_OVERRIDE'] = name
atexit.register(lambda: run_command("g.remove", flags='f', quiet=True,
type='region', name=name))
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
", which calls
G_important_message(), which writes to stderr.
In general, scripts should use the g.message wrappers rather than
Python's "print" statement or os.write(), as that will honour any
configuration options (GRASS_VERBOSE, GRASS_MESSAGE_FORMAT,
--quiet/--verbose,
really applicable for the normal code.
Unless 'b' is added to the mode, on Windows '\n' will be converted to '\r\n' on
output and '\r\n' to '\n' on input.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-
y
system libraries, perform a full re-compile of GRASS (after "make
clean") and ensure that GRASS isn't built against a "private" version
of any system library used by GDAL.
--
Glynn Clements <gl...@gclements.plus.com>
__
ed
Use of "with" ensures that clean-up happens in the event of an
exception or other forms of early exit (e.g. return, break, continue).
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
.3 vector changes to fix the issue, rather than
expecting everyone else to work around it.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
puts, only for the case where one of the outputs matches the input.
The error arises because, in r.mapcalc, using a name on the left-hand
side of an assignment causes the name to be interpreted as a variable
rather than as a map, and the r#/g#/b# modifiers can only be applied
to maps, not v
rts to become more common, then I'd suggest adding a
INSTALL_PYTHON variable to the build system which can be used
similarly to $(INSTALL) or $(INSTALL_DATA), which would replace the
shebang as part of the copying process.
--
Glynn Clements <gl...@gclements.plus.com>
_
will enlarge the binaries with debug information, but
"make strip" or "make install-strip" will remove it.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ncoding.
Bear in mind that the C portion of GRASS (i.e. most of it) doesn't pay
any attention to encodings unless it has to. It just passes bytes
around. It doesn't care whether the bytes are in any particular
encoding, and certainly won't attempt to ensure that data written to
stdout or to fi
for line in rstats.stdout]
I don't think that you'll do much better than that in Python. If it's
still too slow, try using numpy.loadtxt() (pre-processing the data
with sed if that function can't read it directly).
--
Glynn Clements <gl...@gclements.plus.com>
_
ake files, and the "update-po" target in
locale/Makefile. None of these are part of the actual build process.
(I just removed the one in simlib; Rules.make already has a pattern
rule for installing headers).
FWIW, the "portable" s
e useful if you need to be able to dynamically manipulate
the structure of the expression rather than just parameters.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler wrote:
> >> compiling relbranch70 (likely the same on trunk), I got
> >
> > Try r67518.
>
> Issue gone, thanks.
>
> I spotted another single one:
>
> lib/db/sqlp/sqlp.tab.c
r67559
--
G
Markus Neteler wrote:
> compiling relbranch70 (likely the same on trunk), I got
Try r67518.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
r closing the output maps, r.mapcalc will
sometimes copy some of the metadata (cats, colors, history) from the
input map. Currently, it only does this if the entire expression is
just a map with optional modifiers, but it may get more "intelli
emoved by "make clean". They
typically won't be explicitly listed as build targets or dependencies
either, but their mere presence may still affect compilation.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
obably why I
failed to notice this before committing) and may work for parallel
builds.
r66817 moves dbstubs.h to lib/db/dbmi_base, which is an explicit
pre-requisite of both dbmi_driver and stubs.
--
Glynn Clements <gl...@gclements.plus.com>
_
_copy() would have to generate a "log" of failures so
that the caller can report them.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
aps?
G_ls2() doesn't call closedir() when it has finished reading the
directory.
Fixed in trunk with r66719.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
etter since this question came up a few times.
Done in r66731.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
brary needs to
set the close-on-exec flag on p1[WRITE], as it's important that this
descriptor doesn't get duplicated.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to be inherited.
The fact that descriptors are always inherited across fork() and
preserved across execve() by default is generally considered to be a
mistake in the POSIX API, but we're now stuck with it.
--
Glynn Clements <gl...@gclements.plus.com>
___
parent after the child has
been spawned, so they won't be inherited by subsequent child
processes.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
gt; specifically sets WORKERS=0 because lib/raster3d isn't thread-safe).
>
> OK. Does setting "WORKERS=0" do anything when GRASS is compiled
> without pthreads?
No.
If you're experiencing these problems with WORKERS=0 or with GRASS
compiled without pthread support, then the problem is something else
entirely.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
unctions, and r3.mapcalc
specifically sets WORKERS=0 because lib/raster3d isn't thread-safe).
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
doesn't have any code to read or write GRASS vectors, either.
v.mapcalc appears to be a work-in-progress which hasn't actually made
noticeable progress since it was added.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing
h as a separate header would conveniently hide the compilation
> issue on that Debian server.
>
> So, should I remove la.h from gmath.h?
I think so.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.os
Widgets configure checks).
The latter may have an impact upon macosx/app/Makefile, which
references MACOSX_ARCHS_WXPYTHON (which no longer exists).
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://li
ove it (and the wxWidgets configure
checks as well).
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ilable. E.g.
G_matrix_product() and G_vector_norm_euclid() should be
straightforward.
AFAICT, G_matrix_LU_solve() is the only function that's moderately
complex.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lis
ed.
Additionally, requiring individual modules to include
explicitly would make it clear when code depends upon BLAS/LAPACK.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
is
ignored.
Not only does it not call G_parser(), it doesn't call G_gisinit()
either. The only GRASS functions which it calls are:
G_calloc
G_malloc
G_realloc
G_fatal_error
G_free
G_gettext
G_message
G_warning
I suspect that it's probably a long way from being functional at
present.
-
.h
+$(OBJDIR)/yylex.o: v.mapcalc.tab.h
The header is a dependency of the object file; the source file doesn't
have dependencies (it's a source file, not generated).
Committed in r66392.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
user does own, or create one, and use
G_switch_env() to select a different location and mapset temporarily.
Be sure to switch it back before performing any operation which may
write to the "current" mapset (modifying WIND/VAR, creating maps, or
creating te
t by design;
changes to cellhd files end up being atomic purely by virtue of the
fact that cellhd files are typically smaller than the stdio buffer).
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
st people trying to share
directories by making them group-writeable without fully understanding
the implications.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
isting
code.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
mately, the only place where the actual off_t size is "known" is
in compiled code. It might be worth adding this information to the
output of g.version.
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-de
col(east, _w) - 0.5) + 4;
src_w.south -= src_w.ns_res * (r1 - src_w.rows);
src_w.north += src_w.ns_res * (-r0);
--
Glynn Clements <gl...@gclements.plus.com>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
be included in
error messages.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
is not '':
table = '%s.%s' (schema, table)
where schema is set by:
kv = grass.db_connection()
database = kv['database']
driver = kv['driver']
schema = kv['schema']
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
:
https://trac.osgeo.org/grass/changeset/56701/grass/trunk/scripts/v.db.addtable/v.db.addtable.py
It's unrelated to the Python3 conversion.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
against a GDAL library which has since
been removed. In which case, you need to either restore that library
or re-build libLAS to use and existing version of GDAL (or without
GDAL; the dependency is optional).
--
Glynn Clements gl...@gclements.plus.com
.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
is the logical place for it to go.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Moritz Lennert wrote:
Ok. In any case, this probably a candidate for backporting to
grass70release before the upcoming release. Can it be backported as such ?
Yes.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev
threads only provides a gain if it results in using cores which would
otherwise be idle.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
.
And if the no-data value isn't NaN, you have the issue of comparing
floating-point values for equality. Well, that will probably work so
long as the chosen no-data value is an integer.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass
into the
base raster input code in lib/raster/get_row.c (undesirable) or at
least adding a mechanism to allow r.mapcalc to hook into it to provide
the mutex.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
Moritz Lennert wrote:
So, for me, the best solution at this stage is to just set WORKERS to 0 ?
That should work. Also, the issue should be fixed by r65591.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev
Moritz Lennert wrote:
I don't know how to debug this...
Can you identify a repeatable test case?
If I could make it happen, I could debug it.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
is a wrapper around G_find_file2(), which is what C code would use for
that purpose).
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
if a spawned
command fails, whereas shell scripts normally ignore the status of any
spanwed commands.
In both cases the error is not associated with the
given option while in case of overwrite it is (which is nice).
Correct.
--
Glynn Clements gl...@gclements.plus.com
?
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
map exists, it would just get silently overwritten if it
wasn't for the checks performed by G_parser().
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
windows are initialised from the libgis window at startup, but
won't change thereafter unless changed via the libraster functions.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
are being read/written by user code. But it would
be preferable if FILE* could be passed around.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
from a file, using
e.g. input=@filename. But that may just cause similar issues with
--interface-description, G_recreate_command(), etc.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
requirement is that some function
continues to provide the previous behaviour
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
with the vector or DBMI libraries.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
and the default is
the standard and safe way. This was discussed in [GRASS-dev] r65348
(GRASS_TMPDIR_MAPSET).
There is no justification for the current behaviour. The temporary
cell/fcell and null files should always be created in the mapset's
temporary directory.
--
Glynn Clements gl
Martin Landa wrote:
2015-06-04 16:08 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
The the temporary files used by lib/raster need to be on the same
filesystem as the mapset regardless of any environment settings.
please could you write us why?
So that they can be rename()d
for it.
this is controlled by GRASS_TMPDIR_MAPSET variable, if not set the
default is the long-standing behaviour.
The the temporary files used by lib/raster need to be on the same
filesystem as the mapset regardless of any environment settings.
--
Glynn Clements gl...@gclements.plus.com
name for what lib/raster needs is probably less
work.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
limits are usually set below the hard limits to prevent a
misbehaving process from rendering the system unusable. On a
multi-user system, hard limits may be set to prevent a single user
from monopolising resource; there isn't much reason to set hard limits
on a single-user system.
--
Glynn Clements gl
code) were using it.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
where the script aborts if any command fails.
There were two main reasons why GRASS 7 abandoned the monitor
concept, and one of them is that its statefulness made it
next-to-impossible to write *robust* scripts involving display
commands.
--
Glynn Clements gl...@gclements.plus.com
is probably forgotten, and
it's unclear if it's still valid (probably not, if the startup script
is removing the entire directory at the end of the session and no-one
has complained).
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
documenting
the variables themselves is more general than documenting a specific
mechanism used to set them. And if you don't need the convenience of
the d.mon interface, setting the variables directly removes some
complexity from the process.
--
Glynn Clements gl...@gclements.plus.com
Maris Nartiss wrote:
As it is used by GRASS internally only, a simple sed (+ documentation
change) should be enough. The only question remains - change to what?
n_()?
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev
as a
macro) would be a safe bet for that.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
that there are
almost certainly far more significant issues with Python 3
compatibility (such as its insistence on coercing everything to
Unicode).
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
requires C99.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
significantly, G_message() etc use an internal buffer of 2000
bytes. A message longer than that probably won't work and may well
cause the g.message to crash.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
1 - 100 of 2359 matches
Mail list logo
