Michael Barton wrote:
The issue isn't one of C versus Python. It's one of being able to run
a command to generate a PNG/PS/PDF/etc file on a server versus only
being able to generate graphics on a desktop system which is capable
of running a GUI.
It should be possible to use GRASS in a
Markus Neteler wrote:
You can fix that by adding the missing headers to
visualization/nviz/src/
...
The togl.c contains a set of 'if' + 'elif' to reflect the various
version numbers, so update that, too. It's pretty straightforward...
Apparently I am wrong here.
It seems that
Ivan Shmakov wrote:
As lib fns, the one G_fatal_error() would need to change to
G_warning(). Or is it better to be silent and rely on the module
programmer to check the fn's return code?
If it's conceivable that the module will continue in the event of an
error, the function
Ivan Shmakov wrote:
if (color = 0) return 0;
BTW, is it a GRASS convention to use 0 to indicate failure?
Standard C library functions tend to use -1 for failure, while using
non-negative values to indicate success.
The SUBMITTING file in the source code says:
8. Exit
Ivan Shmakov wrote:
AFAIK, GRASS itself never sets errno.
But, IIUC, it doesn't prevent `errno' from being set by the
standard library functions it calls?
Setting `errno' would make sense should there be a demand to use
the standard C means of error reporting
Hamish wrote:
Is a new D_number_to_RGB(int color, unsigned char r,g,b) fn
needed in lib/display/tran_colr.c?
Glynn:
Yes. E.g.:
int D_color_number_to_RGB(int color, int *r, int *g, int *b)
{
const struct color_rgb *c;
if (color = 0)
return 0;
if
On Jan 31, 2008 10:40 AM, Glynn Clements [EMAIL PROTECTED] wrote:
Markus Neteler wrote:
Apparently I am wrong here.
It seems that Glynn's update to togl.c 1.7 make it unnecessary to
include the headers.
I don't think that any of the tkInt* stuff is needed any more.
Headers now removed:
Glynn Clements [EMAIL PROTECTED] writes:
[...]
If it's likely that the module is just going to call
G_fatal_error() anyhow, the library function may as well call it
itself, thereby providing a infallible interface (i.e. the
function never fails; it either succeeds, or the process is no
Sorry for raising this issue once again, but are there any plans
to switch to more recent versions of Autoconf?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Ivan Shmakov ha scritto:
Sorry for raising this issue once again, but are there any plans
to switch to more recent versions of Autoconf?
BTW: I followed the switch of qgis, from automake to cmake, and I think
it was a good success (*much* less bloody than I expected). Now
On Jan 31, 2008, at 3:40 AM, Glynn Clements wrote:
It still needs some internal files on Windows and MacOSX,
specifically:
MacOSX:
These don't appear to be in the GRASS source any more.
#include tclMacCommonPch.h
This is an old Mac Classic (that is, pre-OSX) Tcl header. From
Recently at work we also switched to cmake from autotools, and life is
much simpler now. I would gladly help if we do decide to switch.
A few benefits of cmake include generating native visual studio project
and build files. Trivial way of generating dll libraries and linking in
general. The
Paul Kelly [EMAIL PROTECTED] writes:
Sorry for raising this issue once again, but are there any plans to
switch to more recent versions of Autoconf?
I didn't think so - we've found autoconf 2.13 to work well for us.
Would you be able to give a brief summary of the benefits of
On Jan 31, 2008, at 12:00 PM, Paul Kelly wrote:
BTW: I followed the switch of qgis, from automake to cmake, and I
think
it was a good success (*much* less bloody than I expected). Now
compilation is way smoother and faster.
Would it be reasonable to do the same for GRASS?
?
GRASS doesn't
Michael,
no system change at all (it is an older Mandriva 2007.0 box).
I have installed:
rpm -qa | grep wx
wxPython-common-gtk2-unicode-2.8.3.0-1_py2.4
libwxgtku2.6-2.6.3-7mdv2007.0
libwxgtkglu2.7-2.7.0-2mdv2007.0
libwxPythonGTK2.6-2.6.3.3-2.1mdv2007.0
libwxgtku2.7-devel-2.7.0-2mdv2007.0
#34: ps.map documentation lists incorrect values for vlines type option
--+-
Reporter: tvrusso | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: trivial
Hi,
we should finish adding Cairo support by building it into the ./configure
script.
the attached patch also adds an extra test needed for ffmpeg.
I do not know much about autoconf and ./configure scripts so I don't claim
that the attached patch will work, but it should be a good
17 matches
Mail list logo
