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 startin
#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
Ivan Shmakov wrote:
> $ nl -ba include/gis.h
> ...
>336typedef struct
>337{
>338unsigned char r, g, b, a; /* red, green, blue, and alpha
> */
>339} RGBA_Color ;
>340
>341typedef RGBA_Color RGB_Color;
> ...
> $
>
>
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
wxPython
> 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
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 use
On Thu, 31 Jan 2008, Paolo Cavallini wrote:
Ivan Shmakov ha scritto:
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
On Jan 31, 2008, at 4:30 AM, Glynn Clements wrote:
I support using some Python plotting library to draw axes. We could
write
up a grid template using d.graph, but I'd rather be in the
business of
gluing together high quality components rather than reinventing
yet-another x-y plotting packag
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 s
> Hamish <[EMAIL PROTECTED]> writes:
[...]
> RGBA_Color was recently added (as was RGB support for modules' CLI
> options) so 1) it could be used to pass RGB arround without having to
> call the display library and 2) we could handle a color value of
> 'none' without needing to pass a se
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
This is an old Mac "Classic" (that is, pre-OSX) Tcl header. From the
"Mac" r
> Hamish <[EMAIL PROTECTED]> writes:
[...]
> Glynn:
>>> The problem is that we have both color_rgb (colors.h) and
>>> RGBA_Color (gis.h) structures, and we should deprecate one of them
>>> (probably color_rgb).
> Ivan:
>> Although I know no details, having two similar facilities usu
#34: ps.map documentation lists incorrect values for vlines "type" option
-+--
Reporter: tvrusso | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: trivial |
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
compilati
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
> 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, o
> Glynn Clements <[EMAIL PROTECTED]> writes:
>>> 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 er
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
Michael Barton wrote:
> >> Now I see why the letters are all squished together. This happens if
> >> the region is roughly square or especially if it is taller than it is
> >> wide. If the region is considerably wider than it is tall (e.g. 3:2)
> >> the letters look OK. It looks like it is using
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)
> >
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 repo
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:
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, th
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
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
25 matches
Mail list logo
