20.3: Archive of messages sent to the gri newsgroup
20.3.1. Anyone using Emacs gri-mode?
On Fri, 10 Jul 1998 09:35:17 -0400, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> wrote ...
If anyone is using gri-mode, please know that I am about to change to way
it hunts for the gri.cmd file.
It currently accepts a file layout like
1- Original gri setup
/usr/local/bin/gri
/usr/local/bin/gri.cmd
2- More recent gri setup (the /opt tree):
/opt/gri/bin/gri -> /opt/gri/2.017/bin/gri
/opt/gri/lib/gri.cmd -> /opt/gri/2.017/lib/gri.cmd
/opt/gri/2.017/bin/gri
/opt/gri/2.017/lib/gri.cmd
I am about to change to layout for something like:
3-
/usr/bin/gri-2.1.17
/usr/bin/gri -> gri-2.1.17
/usr/lib/gri/2.1.17/gri.cmd
--
I'd like to remove suuport for layout (1) above. Layout (2) will still be
possible, and layout (3) preferred.
If this hurts you, please let me know me now.
If you are comments, go for it.
As far as I know, there are only a handful of gri-mode users out there
anyway... By far my emacs package with the fewest users.
--
Peter Galbraith, research scientist <GalbraithP@dfo-mpo.gc.ca>
Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada
P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546
6623'rd Linux user at the Linux Counter -- http://counter.li.org/
20.3.2. Building gri 2.1.17 with gcc 2.8.1
On Fri, 17 Jul 1998 12:12:31 -0300 (ADT), George White <gwhite@bodnext.bio.dfo.ca> wrote ...
I'm posting this to the list in the hope that a) someone knows a
solution, or b) the additional data may help determine if the problem is
with gri or the compiler.
Having recently upgrade to Irix 6.2, I'd like to install gri using gcc
2.8.1 (or egcs 1.0.2?)? A few months ago I tried a "gri-source-beta" with
pgcc (egcs 1.0.2) on OS/2, and just now I tried 2.1.17 on SGI Irix 6.2
using gcc 2.8.1. Both compilers report the same problem compiling
delete.cc:
c++ -c -g -O -Wall -fno-implicit-templates -I/usr/local/include
-DVERSION=\"`grep gri_number version.cc | sed -e "s/[^.0-9]//g"`\"
-DDEFAULT_GRI_DIR=\"/usr/local/share/gri/`grep gri_number version.cc \
|sed -e "s/[^.0-9]//g"`/lib\"
-DAWK=\"gawk\" -DIS_SGI=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1
-DHAVE_POSIX_TIMES=1 -DHAVE_ISNAN=1 -DHAVE_ACOSH=1 -DHAVE_GETENV=1
-DHAVE_POPEN=1 -DHAVE_DRAND48=1
-DHAVE_TMPNAM=1 -DHAVE_GETHOSTNAME=1 -I. delete.cc
/usr/local/include/g++/stl_vector.h:113: no type named `iterator_category'
in `int'
/usr/local/include/g++/stl_vector.h:113: no type named `value_type' in
`int'
/usr/local/include/g++/stl_vector.h:113: no type named `difference_type'
in `int'
/usr/local/include/g++/stl_vector.h:113: no type named `pointer' in `int'
/usr/local/include/g++/stl_vector.h:113: no type named `reference' in
`int'
/usr/local/include/g++/stl_iterator.h: In function `{error}
iterator_category<int>(const int &)':
/usr/local/include/g++/stl_iterator.h:126: return-type `{error}' is an
incomplete type
/usr/local/include/g++/stl_iterator.h:126: confused by earlier errors,
bailing out
make: *** [delete.o] Error 1
The header </usr/local/include/g++/stl_vector.h> is pulled in via
#include <vector.h>
which appears in gri's extern.hh. This header is also used by
5 of the size files that compiled cleanly before make reached
delete.cc. Has anyone else seen this? Is there a way past it?
--
George White <aa056@chebucto.ns.ca> tel: 902.426.8509
Bedford Inst. of Oceanography, Nova Scotia, Canada.
20.3.3. Re: Building gri 2.1.17 with gcc 2.8.1
On Fri, 17 Jul 1998 12:46:15 -0300 (ADT), "Dan E. Kelley" <kelley@phys.ocean.dal.ca> wrote ...
Hi George. I just got a linux-based PC, and have egcs on it. I shall
port gri to it soon. The problem is, simply, that egcs cannot compile the
STL library. I've heard that it could, though, and that compiling STL was
in fact one of the great new things about egcs, compared to the GNU
compiler. More later. Dan.
On Fri, 17 Jul 1998, George White wrote:
> I'm posting this to the list in the hope that a) someone knows a
> solution, or b) the additional data may help determine if the problem is
> with gri or the compiler.
>
> Having recently upgrade to Irix 6.2, I'd like to install gri using gcc
> 2.8.1 (or egcs 1.0.2?)? A few months ago I tried a "gri-source-beta" with
> pgcc (egcs 1.0.2) on OS/2, and just now I tried 2.1.17 on SGI Irix 6.2
> using gcc 2.8.1. Both compilers report the same problem compiling
> delete.cc:
>
> c++ -c -g -O -Wall -fno-implicit-templates -I/usr/local/include
> -DVERSION=\"`grep gri_number version.cc | sed -e "s/[^.0-9]//g"`\"
> -DDEFAULT_GRI_DIR=\"/usr/local/share/gri/`grep gri_number version.cc \
> |sed -e "s/[^.0-9]//g"`/lib\"
> -DAWK=\"gawk\" -DIS_SGI=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1
> -DHAVE_POSIX_TIMES=1 -DHAVE_ISNAN=1 -DHAVE_ACOSH=1 -DHAVE_GETENV=1
> -DHAVE_POPEN=1 -DHAVE_DRAND48=1
> -DHAVE_TMPNAM=1 -DHAVE_GETHOSTNAME=1 -I. delete.cc
> /usr/local/include/g++/stl_vector.h:113: no type named `iterator_category'
> in `int'
> /usr/local/include/g++/stl_vector.h:113: no type named `value_type' in
> `int'
> /usr/local/include/g++/stl_vector.h:113: no type named `difference_type'
> in `int'
> /usr/local/include/g++/stl_vector.h:113: no type named `pointer' in `int'
> /usr/local/include/g++/stl_vector.h:113: no type named `reference' in
> `int'
> /usr/local/include/g++/stl_iterator.h: In function `{error}
> iterator_category<int>(const int &)':
> /usr/local/include/g++/stl_iterator.h:126: return-type `{error}' is an
> incomplete type
> /usr/local/include/g++/stl_iterator.h:126: confused by earlier errors,
> bailing out
> make: *** [delete.o] Error 1
>
> The header </usr/local/include/g++/stl_vector.h> is pulled in via
> #include <vector.h>
> which appears in gri's extern.hh. This header is also used by
> 5 of the size files that compiled cleanly before make reached
> delete.cc. Has anyone else seen this? Is there a way past it?
>
> --
> George White <aa056@chebucto.ns.ca> tel: 902.426.8509
> Bedford Inst. of Oceanography, Nova Scotia, Canada.
>
Dan E. Kelley internet: mailto:Dan.Kelley@Dal.CA
Oceanography Department phone: (902)494-1694
Dalhousie University fax: (902)494-2885
Halifax, NS, CANADA, B3H 4J1 http://www.phys.ocean.dal.ca/~kelley
20.3.4. Re: Building gri 2.1.17 with gcc 2.8.1
On Fri, 17 Jul 1998 14:12:13 -0300 (ADT), George White <gwhite@bodnext.bio.dfo.ca> wrote ...
I'm very impressed with egcs (1.0.2) on my 486DX2/66 running OS/2. The
compiler is significantly faster than gcc 2.7.x, and my programs are
generally 10--25% faster. I have built a few very simple apps that use
STL, but mostly I've been using if for C and fortran, so I'm sure there
are lots of bugs I haven't seen. These days, hardware becomes obsolete
faster than people can write good compilers.
SGI has new and much better compilers (using Cray technology) for Irix
6.x, which means they can afford to provide the tools people need to run
gcc in the base OS. We're still using EPC's C++ as a better C, I haven't
had time to install STL (it is supposed to work with ObjectSpace's STL
as well as SGI's free implementation).
--
George White <aa056@chebucto.ns.ca> tel: 902.426.8509
Bedford Inst. of Oceanography, Nova Scotia, Canada.
On Fri, 17 Jul 1998, Dan E. Kelley wrote:
> Hi George. I just got a linux-based PC, and have egcs on it. I shall
> port gri to it soon. The problem is, simply, that egcs cannot compile the
> STL library. I've heard that it could, though, and that compiling STL was
> in fact one of the great new things about egcs, compared to the GNU
> compiler. More later. Dan.
>
> Dan E. Kelley internet: mailto:Dan.Kelley@Dal.CA
> Oceanography Department phone: (902)494-1694
> Dalhousie University fax: (902)494-2885
> Halifax, NS, CANADA, B3H 4J1 http://www.phys.ocean.dal.ca/~kelley
>
>
20.3.5. Hatched regions in Gri
On Fri, 14 Aug 1998 15:58:19 -0700, David Oxilia <oxilia@OCE.ORST.EDU> wrote ...
Hi all,
I was wondering if someone knows how to make hatched regions in gri?
I have some sections with areas I'd like hatched and/or stippled. I
imagine that this might require masking the regions of the image some
way or other and then plotting within the masked region data that
creates the stipples or hatches. However, this sound like a bit of
a computing chore for something that might be easily done by a
draftsperson (or am I wrong?).
Anyone have a nifty perl function to do this?
thanks, David.
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
David Oxilia Tel: (541) 737-2368
COAS:Oregon State University Fax: (541) 737-2064
Ocean Admin. Bldg. 104 WWW: http://www.oce.orst.edu/po
Corvallis, OR 97331-5503 Email: oxilia@kundun.oce.orst.edu
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
20.3.6. Re: Hatched regions in Gri
On Wed, 26 Aug 1998 10:44:45 -0300 (ADT), "Dan E. Kelley" <kelley@phys.ocean.dal.ca> wrote ...
Hi David. Sorry for the delay in forwarding your msg to 'gri' group. I
was out of town. It's a pain, having to wait, but on the other hand, now
that I have a 'moderated' group, you shouldn't get any junk mail from gri.
As to your question, I don't know of an easy and general method for doing
this. It would be pretty easy if gri allowed clipping to
non-rectangular regions -- you'd just read in the curve, set the clipping
path to that curve, then use a loop to draw diagonal lines through a
region that was bigger than the curve (e.g. through the axis region).
Unfortunately, gri does not allow nonrectangular clipping paths. I plan
to allow that in 'gre', and I also plan to allow full support for
hatching, so that one could say something like 'draw curve hatched'.
On Fri, 14 Aug 1998, David Oxilia wrote:
> Hi all,
>
> I was wondering if someone knows how to make hatched regions in gri?
> I have some sections with areas I'd like hatched and/or stippled. I
> imagine that this might require masking the regions of the image some
> way or other and then plotting within the masked region data that
> creates the stipples or hatches. However, this sound like a bit of
> a computing chore for something that might be easily done by a
> draftsperson (or am I wrong?).
>
> Anyone have a nifty perl function to do this?
>
> thanks, David.
>
> *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
> David Oxilia Tel: (541) 737-2368
> COAS:Oregon State University Fax: (541) 737-2064
> Ocean Admin. Bldg. 104 WWW: http://www.oce.orst.edu/po
> Corvallis, OR 97331-5503 Email: oxilia@kundun.oce.orst.edu
> *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
>
Dan E. Kelley internet: mailto:Dan.Kelley@Dal.CA
Oceanography Department phone: (902)494-1694
Dalhousie University fax: (902)494-2885
Halifax, NS, CANADA, B3H 4J1 http://www.phys.ocean.dal.ca/~kelley
20.3.7. GIF images
On Wed, 26 Aug 1998 14:07:09 -0700 (PDT), Peter Franks <franks@poto.ucsd.edu> wrote ...
Hi all;
I have some gif format satellite images that I would like to
modify by adding contours, coastlines, etc. I can convert them
into any other format necessary, but I don't know how to
read them with gri. Right now I'm converting the gif to a postscript
file, and then modifying the files themselves - it's a pain.
Any suggestions?
Cheers, Peter
20.3.8. Re: GIF images
On Wed, 26 Aug 1998 18:43:44 -0300 (ADT), "Dan E. Kelley" <kelley@phys.ocean.dal.ca> wrote ...
Gri presently does not support 'gif' image files, but it does support
other file types, such as the 'pgm' type.
On our machines there is a command called 'convert' which permits
conversion from one image type to another. I think it's part of the
ImageMagic software package. Alternatively, you can use 'xv' to convert
from one file format to another.
Once it's in pgm format, you'd do something like
read image pgm ...
convert image to grid
draw contour
or whatever. Hope this helps. Note: I won't be avail to help more until
next week, but other users might have some advice.
PS: The gif format is quite complicated, and I didn't want to take the
time to support it in gri. Also, presently, quite a lot of free software
is moving away from the gif format, since it is proprietary. Therefore
it's unlikely that I'll add gif support later.
On Wed, 26 Aug 1998, Peter Franks wrote:
>
> Hi all;
>
> I have some gif format satellite images that I would like to
> modify by adding contours, coastlines, etc. I can convert them
> into any other format necessary, but I don't know how to
> read them with gri. Right now I'm converting the gif to a postscript
> file, and then modifying the files themselves - it's a pain.
> Any suggestions?
>
> Cheers, Peter
>
Dan E. Kelley internet: mailto:Dan.Kelley@Dal.CA
Oceanography Department phone: (902)494-1694
Dalhousie University fax: (902)494-2885
Halifax, NS, CANADA, B3H 4J1 http://www.phys.ocean.dal.ca/~kelley
20.3.9. Re: Gri polar question (fwd)
On Fri, 18 Dec 1998 13:21:22 -0400 (AST), "Dan E. Kelley" <kelley@Phys.Ocean.Dal.Ca> wrote ...
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--Message-Boundary-15705
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.GSO.3.96.981218132113.6329C@Skye>
Content-Description: Mail message body
Dan E. Kelley internet: mailto:Dan.Kelley@Dal.CA
Oceanography Department phone: (902)494-1694
Dalhousie University fax: (902)494-2885
Halifax, NS, CANADA, B3H 4J1 http://www.phys.ocean.dal.ca/~kelley
---------- Forwarded message ----------
Date: Fri, 18 Dec 1998 12:21:14 -0500
From: Carl Osterwisch <osterwischc@asme.org>
To: "Dan E. Kelley" <kelley@phys.ocean.dal.ca>
Subject: Re: Gri polar question
Hi Dan,
I had a little free time so I made some patches to fix a few problems
with polar coordinates in Gri 2.1.19. Also, does the mailing list still
exist? I would have directed this message there but I can't find it
anymore.
> Hi. I think the majordomo is still supposed to work, but anyway, I've
> added you to the gri list, manually. I have your address as:
>
> osterwischc@asme.org (Carl Osterwisch)
>
> which I hope is all right. If, later, the majordomo refuses to let you
> unsubscribe, just ask me and I'll manually remove your name.
>
> As to your question on polar plots, I have to admit that gri does NOT do
> polar plots correctly. I started coding it in for some of my own work,
> and then decided to use another approach. For one thing, adding polar
> axes means that I'd have to make all sorts of choices as to the aesthetics
> of the drawing -- e.g., should I put rings around the center, where should
> I put labels, etc?
>
> In the rare instances where I've needed this sort of thing, I've normally
> just drawn some circles with 'draw circle' and drawn radial lines with
> 'draw line', etc.
>
> Basically, I've not often wanted r-theta graphs in my work, and since gri
> development is driven by the needs of my own research lab, and my
> colleagues within oceanography, r-theta isn't likely to come soon. Sorry.
>
> I hope this helps, but I realize that, really, it probably won't help you
> much.
>
> On Fri, 13 Nov 1998, Carl Osterwisch wrote:
>
> > Hello,
> >
> > I seem to be having some difficulty joining the GRI mailing list (maybe it
> > no longer exists?) so I thought I would mail you directly.
> >
> > I'm still pretty new to Gri and I can't figure out how to generate a polar
> > plot of my data (r - theta). I have "set axes style polar" but "draw axes"
> > always draws rectangular axes. Also, "convert columns from polar to
> > rectangular" does not generate a y column which I assume is required
> > prior to a "draw curve" command.
> >
> > Anyway, how do I plot my r-theta data on a graph with "axes style
> > polar"?
> >
> > Thanks for the help. This looks like a very powerful program so please
> > keep up the good work.
Carl Osterwisch osterwischc@asme.org
Mechanical Design Engineer Phone 734-995-1755
STM Corporation Fax 734-995-0610
--Message-Boundary-15705
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.GSO.3.96.981218132113.6329D@Skye>
Content-Description: Text from file 'polar_patch.txt'
The following patch fixes the "convert columns from polar to rectangular"
command. The original code does not generate y data if the y column doesn't
already exist.
diff -C 2 ./convert.cc ../orig/gri-2.1.19/convert.cc
*** ./convert.cc Fri Nov 13 11:55:03 1998
--- ../orig/gri-2.1.19/convert.cc Sat Oct 24 08:14:38 1998
***************
*** 97,103 ****
double *thetap = _colTHETA.begin();
double theta;
! _colX.setDepth(_colR.size());
! _colY.setDepth(_colR.size());
! for (unsigned int i = 0; i < _colR.size(); i++, rp++, thetap++) {
theta = *thetap / DEG_PER_RAD;
_colX[i] = (*rp) * cos(theta);
--- 97,101 ----
double *thetap = _colTHETA.begin();
double theta;
! for (unsigned int i = 0; i < _colX.size(); i++, rp++, thetap++) {
theta = *thetap / DEG_PER_RAD;
_colX[i] = (*rp) * cos(theta);
The next two patches give an informative error message when trying to draw
polar axes. The original code will draw rectangular axes at the left and
bottom with a simple frame (type 1).
diff -C 2 ./draw.cc ../orig/gri-2.1.19/draw.cc
*** ./draw.cc Fri Dec 18 09:34:27 1998
--- ../orig/gri-2.1.19/draw.cc Sat Oct 24 08:14:38 1998
***************
*** 1114,1126 ****
_top_of_plot = y_cm;
}
- case AXES_POLAR: // polar axis
- {
- err("Polar axes not yet supported");
- return false;
- }
break;
default:
err("unknown axis type");
- return false;
}
gr_setfontsize_pt(oldFontsize_pt);
--- 1114,1120 ----
diff -C 2 ./extern.hh ../orig/gri-2.1.19/extern.hh
*** ./extern.hh Fri Dec 18 08:21:14 1998
--- ../orig/gri-2.1.19/extern.hh Sat Oct 24 08:14:39 1998
***************
*** 17,21 ****
#include "macro.hh"
#define AXES_RECTANGULAR 0 // normal axes style (rect)
! #define AXES_POLAR 50 // polar axes
extern GriState _griState; // <-> gri.cc
--- 17,21 ----
#include "macro.hh"
#define AXES_RECTANGULAR 0 // normal axes style (rect)
! #define AXES_POLAR 1 // polar axes
extern GriState _griState; // <-> gri.cc
--Message-Boundary-15705--
20.3.10. gri 2.1.20 release
On Fri, 18 Dec 1998 15:09:46 -0400 (AST), Dan E Kelley <kelley@Phys.Ocean.Dal.CA> wrote ...
Earlier today, Carl Osterwisch posted here about a patch to gri, to
let it handle the two commands
convert columns from rectangular to polar
convert columns from polar to rectangular
Gri version 2.1.20 has incorporated Osterwisch's suggestions, plus a
tweak to 'show columns'. Please note that full support is not
provided to polar plots. In particular, Gri has no fancy
spoke-and-ring axis style. An example of usage of these commands is
below my sigline. The example is a trivial one; I don't use this sort
of graph in my work and have nothing fancier to offer as a
demonstration.
Gri version 2.1.20 is available at the usual place, in source form at
ftp://ftp.phys.ocean.dal.ca/users/kelley/gri/gri-2.1.20.tgz
and in precompiled (redhat) linux form at
ftp://ftp.phys.ocean.dal.ca/users/kelley/gri/gri-2.1.20-1.rpm
... to post to this (moderated) group, email to gri@phys.ocean.dal.ca.
Dan E. Kelley internet: mailto:Dan.Kelley@Dal.CA
Oceanography Department phone: (902)494-1694
Dalhousie University fax: (902)494-2885
Halifax, NS, CANADA, B3H 4J1 http://www.phys.ocean.dal.ca/~kelley
EXAMPLE GRI COMMANDFILE:
open "awk 'BEGIN{for(r=0;r<=6.2833;r+=0.62832){print cos(r), sin(r);}}'|"
read columns x y
close
show columns
convert columns from rectangular to polar
show columns
convert columns from polar to rectangular
show columns
OUTPUT PRODUCED:
.
.
.
x y
1 0
0.809016 0.587786
0.309014 0.951057
-0.309021 0.951055
-0.80902 0.58778
-1 -7.34641e-06
-0.809012 -0.587792
-0.309007 -0.95106
0.309028 -0.951053
0.809025 -0.587775
1 1.46928e-05
.
.
.
r theta
1 0
1 36.0001
1 72.0002
1 108
0.999999 144
1 -180
1 -144
1 -107.999
1 -71.9993
1 -35.9993
1 0.000841835
.
.
.
x y
1 0
0.809016 0.587786
0.309014 0.951057
-0.309021 0.951055
-0.80902 0.58778
-1 -7.34641e-06
-0.809012 -0.587792
-0.309007 -0.95106
0.309028 -0.951053
0.809025 -0.587775
1 1.46928e-05
20.3.11. Polar patches
On Fri, 18 Dec 1998 14:15:29 -0500, "Carl Osterwisch" <osterwischc@asme.org> wrote ...
--Message-Boundary-19171
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
It doesn't look like the patches got forwarded in that last message.
They should be attached to this message.
Carl Osterwisch osterwischc@asme.org
Mechanical Design Engineer Phone 734-995-1755
STM Corporation Fax 734-995-0610
--Message-Boundary-19171
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Text from file 'polar_patch.txt'
The following patch fixes the "convert columns from polar to rectangular"
command. The original code does not generate y data if the y column doesn't
already exist.
diff -C 2 ./convert.cc ../orig/gri-2.1.19/convert.cc
*** ./convert.cc Fri Nov 13 11:55:03 1998
--- ../orig/gri-2.1.19/convert.cc Sat Oct 24 08:14:38 1998
***************
*** 97,103 ****
double *thetap = _colTHETA.begin();
double theta;
! _colX.setDepth(_colR.size());
! _colY.setDepth(_colR.size());
! for (unsigned int i = 0; i < _colR.size(); i++, rp++, thetap++) {
theta = *thetap / DEG_PER_RAD;
_colX[i] = (*rp) * cos(theta);
--- 97,101 ----
double *thetap = _colTHETA.begin();
double theta;
! for (unsigned int i = 0; i < _colX.size(); i++, rp++, thetap++) {
theta = *thetap / DEG_PER_RAD;
_colX[i] = (*rp) * cos(theta);
The next two patches give an informative error message when trying to draw
polar axes. The original code will draw rectangular axes at the left and
bottom with a simple frame (type 1).
diff -C 2 ./draw.cc ../orig/gri-2.1.19/draw.cc
*** ./draw.cc Fri Dec 18 09:34:27 1998
--- ../orig/gri-2.1.19/draw.cc Sat Oct 24 08:14:38 1998
***************
*** 1114,1126 ****
_top_of_plot = y_cm;
}
- case AXES_POLAR: // polar axis
- {
- err("Polar axes not yet supported");
- return false;
- }
break;
default:
err("unknown axis type");
- return false;
}
gr_setfontsize_pt(oldFontsize_pt);
--- 1114,1120 ----
diff -C 2 ./extern.hh ../orig/gri-2.1.19/extern.hh
*** ./extern.hh Fri Dec 18 08:21:14 1998
--- ../orig/gri-2.1.19/extern.hh Sat Oct 24 08:14:39 1998
***************
*** 17,21 ****
#include "macro.hh"
#define AXES_RECTANGULAR 0 // normal axes style (rect)
! #define AXES_POLAR 50 // polar axes
extern GriState _griState; // <-> gri.cc
--- 17,21 ----
#include "macro.hh"
#define AXES_RECTANGULAR 0 // normal axes style (rect)
! #define AXES_POLAR 1 // polar axes
extern GriState _griState; // <-> gri.cc
--Message-Boundary-19171--
20.3.12. join
On Wed, 06 Jan 1999 07:07:07 -0800, Gadiel Alarcon <gadiel@profc.udec.CL> wrote ...
--------------378490E72A7D99019C425C7E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi Gri users,
First, I have a question....I'm working with a x vs y plot, every plot
is in a different distance from coast and I would like to use a
different symbol to the data, for example: circles for 5 nm from the
coast data, triangles for 10 nm from .......and so on. Furthermore, I'm
using a linear regression for x y plot.
Second, What I have to do to join to the gri news group..
Thanks in advance
Best regards
------Gadiel
--------------378490E72A7D99019C425C7E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
Hi Gri users,
<P>First, I have a question....I'm working with a x vs y plot, every
plot is in a different distance from coast and I would like to use
a different symbol to the data, for example: circles for 5 nm from the
coast data, triangles for 10 nm from .......and so on. Furthermore, I'm
using a linear regression for x y plot.
<P>Second, What I have to do to join to the gri news group..
<P>Thanks in advance
<BR>Best regards
<P>
------Gadiel
<PRE></PRE>
</HTML>
--------------378490E72A7D99019C425C7E--
20.3.13. gri-mode comment lines
On Fri, 08 Jan 1999 12:20:05 -0500, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> wrote ...
I had always thought that Gri did C-style comments like:
// A comment line
and
/*
A bunch
of comment
lines
*/
I recently discovered that Gri also accept:
# A comment.
Since # is much nicer to use than //, I tried to add it to
gri-mode's syntax table (An emacs syntax table defines stuff like
what is a comment line). The problem was supporting all three
methods. I have it almost working with Emacs-20.3 in gri-mode
V2.03, but Toru Suzuki has reported the code is broken for
Emacs-19.34.
What should I do?
Should gri-mode only support the # character? I could add a
function to gri-mode to make the conversion for users.
This would affect fontification with font-lock and perhaps
indentation.
Or should I let the user choose between
A- Using // and /* */
B- Using only #
in their ~/.emacs file.
Perhaps I could try to support both // and # as comment
characters, but I know _I_ will be changing to only # in my gri
files.
If I don't get any feedback on this from the user community, I'll
assume noone cares and do whatever I want (probably remove
support for // and # entirely) since that is less work for me.
--
Peter Galbraith, research scientist <GalbraithP@dfo-mpo.gc.ca>
Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada
P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546
6623'rd GNU/Linux user at the Counter - http://counter.li.org/
20.3.14. Re: gri-mode comment lines
On Fri, 8 Jan 1999 13:51:13 -0400 (AST), "Dan E. Kelley" <kelley@Phys.Ocean.Dal.Ca> wrote ...
On Fri, 8 Jan 1999, Peter S Galbraith wrote:
>...
> Should gri-mode only support the # character? I could add a
> function to gri-mode to make the conversion for users.
I think the mode should only support #, especially given difficulties in
supporting multiple styles. The # syntax is more familiar to users of
the c-shell, perl, awk, etc. Also, the commercial gri (now called
'gre') uses '#' for comments.
PS: even I, the gri author, didn't know that /* comment */ worked!
Dan E. Kelley internet: mailto:Dan.Kelley@Dal.CA
Oceanography Department phone: (902)494-1694
Dalhousie University fax: (902)494-2885
Halifax, NS, CANADA, B3H 4J1 http://www.phys.ocean.dal.ca/~kelley