
	Solutions to some problems.

	1.q) When I run `make Test' I get the message:

		***complex division inaccuracy, check manually***

	1.a) Some compilers do not generate the best code for complex
	division. Most do. Some will pass or fail the test depending
	upon the level of optimization used. If RLaB fails this test
	do a manual check of complex division to verify that the
	answer is correct to within +/- machine-epsilon. If the answer
	is correct to within +/- machine-epsilon then it is safe to
	use RLaB.

	2.q) I get undefined symbols (like pow_zi) when the Makefile
	tries to link rlab?

	2.a) Undefined symbols like pow_zi are usually from the f2c
	libraries. If the Makefile found libF77.a and libI77.a, and
	these symbols are still undefined, then you probably have a
	Fortran compiler installed on your machine. Some vendors
	Fortran libraries will work OK. But, other vendors have
	gratuitously changed the libraries. 

	Try getting the latest version of the f2c libraries
	(research.att.com, or prep.ai.mit.edu). Or, you could write a
	Fortran interface and mail it to me :-)

	3.q) alloca is undefined?

	3.a) `make ALLOCA=alloca.o'

	4.q) When I run `make Test', it fails immediateley.

	4.a) The problem may be that your system does not declare
	strtod() in its header files. strtod() is used heavily by the
	scanner, and if it is not declared the compiler will think it
	returns int, which is not right at all. Fix: add

		#include <whatever_include_defs_strtod.h>

	5.q) When I run `make Test' RLaB reports an error in round()?

	5.a) Some platforms (HP for instance) have a rint() function
	in the system library, but it does not work. To fix: go into
	config.h and comment out the two lines:

		#define HAVE_RINT 1
		#define HAVE_RINT_DEC 1

	Then RLaB will uses its own rint().
	***NOTE*** configure now checks for broken rint functions, and
	will setup config.h properly.

	6.q) I have compiled RLaB on a Sun, using SunOS-4.1.3 and gcc.
	When I try and run RLaB I get an "out of memory" message, and
	some complaints from flex?

	6.a) This is a strange one, it does not happen on all Suns,
	but someone discovered that compiling and linking to the GNU
	libmalloc.a curred the problem.

	7.q) (borrowed from Plplot FAQ) 3.5 I would like to issue a
	plot command, have the window appear, or be re-painted, and
	allow the user to continue with command line operation of
	RLaB. I would like the user to be able to resize the window at
	any time or cover/un-cover it at any time and have it re-paint
	itself. The way I can get it to work is: the user issues plot
	command, window appears and is resizable, etc... the user must
	use the 3rd mouse button to "release" the window, after that
	control returns to the command line, but the window will no
	longer resize/repaint.

	7.a) This is a feature, not a bug :-).

	When the plotting package is waiting for the user to advance
	the page, it is actually waiting for any X event.  So events
	like refresh and resize get intercepted and processed.

	Also during the normal course of plotting, the X server is
	periodically polled to find out if there are any events that
	need processing, and handles them if so.  I don't do this on
	every graphics instruction because otherwise the overhead is
	too large -- currently on every 20 line draws, every 10
	polyline draws, and on every other call. 

	But once the user signals for the page advance, and control is
	returned to the user program, there is no way for the X driver
	to process any events simply because the control is in your
	program, not in the X driver. The single-headedness of your
	process becomes the culprit here.  You can either sit in an
	event loop, or be doing user code specific things, but not
	both.  There is one improvement that could still be made which
	is to provide a plevents() call so you can explicitly force
	all events to be handled, but that's just a bandaid solution
	so I never put it in. 

	The real solution is to fork off the rendering into a separate
	process, and this is just what I did with the Tcl/TK driver.
	So, if you select the tk driver, your code can go about its
	merry way while the graphics window can be refreshed, resized,
	zoomed, printed, dumped, or whatever.

	It'd also be a worthwhile project to split the X driver up
	similarly, and there has been some interest in doing that (but
	I don't plan to work on it).

	8.q) Trying to run `make install' on a DECstation results in
	make and/or shell errors?

	8.a) The DECstation has a buggy make, and a horribly old
	version of sh. Doing

		gmake SHELL=/bin/sh5 install

	Will yield a clean install. Note: gmake is GNU make.

	9.q) I installed RLaB with Plplot and when I "interrupt"
	(Ctrl-c) RLaB, it kills the Plplot tk window ?

	9.a) Versions of Plplot earlier than (and including) v4p99g
	pass all signals along to the child plserver
	process. Hopefully this will be fixed, or a workaround
	provided in later versions. But, for now you must modify tk.c
	and recompile Plplot. The following patch modifies tk.c so
	that child plserver processes do not get passed SIGINT
	signals. With this patch you can interrupt RLaB without
	killing plserver.

*** tk.c~	Fri May 13 22:43:13 1994
--- tk.c	Sat Jul 16 09:08:24 1994
***************
*** 1052,1057 ****
--- 1052,1066 ----
  	    abort_session(pls, "Unable to fork server process");
  	}
  	else if (pid == 0) {
+ 	    int rs;
+ 	    sigset_t set;
+ 	    sigemptyset (&set);
+ 	    sigaddset (&set, SIGINT);
+ 	    if ((rs = sigprocmask (SIG_BLOCK, &set, 0)) == -1)
+ 	    {
+ 	      fprintf(stderr, "tk.c: sigprocmask troubles\n");
+ 	    }
+ 
  	    fprintf(stderr, "Starting up %s\n", plserver_exec);
  	    if (execv(plserver_exec, argv)) {
  		fprintf(stderr, "Unable to exec server process.\n");

	10.q&a) On HP and DEC-Alpha computers you may need to compile
	everything in the "traditional" mode (not ANSI), with the
	exception of r_plot.c. This may also be true for IBMs AIX.

	11.q) I am having trouble with compiling fpe.c, I gets lots of
	errors I don't understand.

	11.a) Apparently configure did not understand your systems
	method of setting up floating point exceptions. You can
	completely disable the function setup_fpe_handling by running
	configure with the `--disable-fpe' option.

	12.q) Configure cannot find libplplotdtk.a even though I am
	using the --with-PLIBS option?

	12.a) Configure tries to link a test program. The test can
	fail for a number of reasons. One of the most common is that a
	support library cannot be found. In this case it is most
	likely libtcl.a or libtk.a. On some Linux systems, these are
	in strange places. They should be in /lib, /usr/lib, or
	/usr/local/lib. 

	13.q) I am trying to compile rlab on an HP, and I can't get
	the floating point handling to generate infs and NaNs.

	13.a) HP has a confusing, and ever changing method of providing
	floating point support. Last I checked the fpsetmask() type
	functions were defined in math.h, and stored in libm.a, iff
	you have a pa1.1 architecture (don't ask me what that
	means). If you have the pa1.1, the using the +LDA1.1 flag to
	the linker will get the right math library.

	14.q) I ran configure and tried `make' on a (HP | DEC | SGI),
	but all I get is lots of compiler error messages.

	14.a) Some platforms just can't give up on their "sort-of"
	ANSI C compilers. Sometimes the system comes with a default
	K&R C compiler, with a purchase-able add-on of a ANSI C
	compiler. Some platforms come with one compiler that tries to
	be everything to everybody. In either case, there are often
	compiler flags that will turn ANSI behavior on or off.

	You want to compile rlab with the same compiler options that
	were used during when configure was run. Often it is the
	omission of one of these flags that is preventing a clean
	compile from happening. If you have to, add a statement like:

		CC="cc -ansi_behavior_on_please"

	below the `#!/bin/sh' statement.
