Known bugs as of 28-August-1994:
None of the bugs in GFFT itself at this time are serious, and ALL
can be worked around or ignored. But it may decrease your
enjoyment of this program if you are unaware of how to work around
them. So, if something doesn't seem to be working correctly, check
here.
(1) Just after GFFT creates a shell to run GNUPLOT, my machine GURUS!
Background: The modified version of GNUPLOT provided with
WinGnuPlot may have this problem if you do not follow the
INSTALLATION instructions. (Apparently, if it hasn't been given
the "set terminal amigascreen" command in .gfft-WinGnuPlot, this
version of GNUPLOT can GURU, particularly if no CompuGraphic font
has been installed.)
Workaround: As the INSTALLATION file says, "If your GNUPLOT is from
a WinGnuPlot distribution, rename .gfft-WinGnuPlot to .gfft (THIS
IS VERY IMPORTANT!)."
Plans: I have been and will keep on trying to get the standard
GNUPLOT distribution(s) restored to Aminet. I haven't even been
able to get a copy of them myself (since version 3.4). I will also
try to get the author of WinGnuPlot to fix the problem with the
modified GNUPLOT included with WinGnuPlot.
(2) Getting help for selected string gadgets in the GFFT Dialog Window
doesn't work for string gadgets which are already selected.
Background: Normally, to get help for any gadget in the string
gadget window, all you need do is hold down the Ctrl key and click
on it. But this will not work for string gadgets which have
already been selected. The help request for them will be ignored.
Workaround: Deselect the string gadget first by clicking anywhere
else on the screen. Then obtain help normally by holding down
Ctrl while clicking on the string gadget.
Plans: I do not plan to fix this problem unless someone can tell me
how to do so easily. It appears that in order to fix this I would
have to make the handling of string gadgets in the program
considerably more complex by handling the editing of string gadgets
myself (e.g. by adding edit hooks).
(3) Why do I get the error "No Screen" when GNUPLOT is attempting to plot
my spectrum?
Background: One of the last things GNUPLOT does is to allocate the
hires custom screen to display your spectrum. At that point, if
there is not enough memory available, GNUPLOT will abort leaving
the "No Screen" message. This is not necessarily a lack of chip
memory per se; it is more likely to result from a shortage of total
memory (fast + chip). I've run GFFT successfully with up to 8,000
bins while running other programs using custom screens on an Amiga
with 2 Mb fast and only 512K chip.
Workaround: Try using fewer bins. If that doesn't help, try
the suggestions in the 'Low On Memory' section of the INSTALLATION
file.
Plans: I tried to intercept the 'No Screen' error to give the
user a more useful message, but this was incompatible with
AmigaDOS 1.3. Future versions of GFFT are likely to require
2.0+ and even more memory.
(4) Why do I get the error "Unable to open spectrum file for output!" when
trying to do a second FFT analysis while leaving the plot for the first
analysis in a background screen?
Background: Although GFFT will now (1.33+) allow you to display
more than one plot screen at the same time (but see alternatives
below), during the time when GNUPLOT is reading the data from the
spectrum file, a spectrum file having the same name cannot be
re-opened for output.
Workaround: Wait for GNUPLOT to finish plotting one spectrum before
beginning to compute the next. Note that each GNUPLOT session will
soak up another 400K or more of memory, so consider the options
below.
If you want to display several spectra at the same time, you should
be aware of the "CombinePlots" feature (which is activated by the
'&' button immediately to the left of the 'Plot' button in the GFFT
Dialog Window. This will let you combine any number of spectrum
plots on the same plot screen where they can be readily compared.
Or, if you really want to switch between several different plot
display screens, you can use a screen dump program to save each one
to a file and then display it with an IFF display program. That
will save a lot of memory, and you will have saved each display for
later use as well (I like to do this).
Plans: I might "fix" this in a future release, but it won't be a
high priority unless I hear users with lots of memory to burn
asking for it. I will also want to make the CombinePlots feature
more obvious first (because that is usually the best approach for
displaying several spectra at once). I will also probably make
the error message less cryptic in a future release by testing for
the specific condition discussed here which usually causes it.
(5) - (6) relate to problems when displaying HELP messages or launching
GNUPLOT from GFFT:
(7) Aliases for MORE in S:Shell-Startup are ignored.
(8) MORE in directories other than <current directory>, C:, or
sys:utilities is not found.
(9) GNUPLOT not found unless in <current directory> or C:.
Background: Bugs 5-9 are related and due to the the technique used
by GFFT to create new processes.
Workaround: Follow instructions in INSTALLATION. For example, if
you use a text reader other than MORE, and if you have AmigaDOS 2.0
or greater, create a link named MORE in your C: directory, or (if
you only have 1.3) make a copy of it named MORE either in C: or (if
you run GFFT only from the Workbench) in the same directory as GFFT
itself.
Plans: I do not plan to fix these 'problems' (which you will not
experience if you following the INSTALLATION directions) unless
someone can tell me how to do easily. Unfortunately, launching
other processes is not a very clean area of AmigaDOS, especially
for programs like GFFT which may be started either from a Shell or
from the Workbench. Other techniques I have tried do other bad
things, such as losing track of the <current directory>. Those
other techniques also typically require the creation and use of
BCPL pointers (@#$%^&*!). Currently, I use the 'system()' function
supplied by SAS which is very clean EXCEPT for the fact that it
causes these problems which could therefore considered to be
limitations of that function.
Rather than fixing these current problems, I may add support for
TOOLTYPES or environmental variables in a future release.
(10) GNUPLOT not found when in same directory as GFFT under AmigaDOS 1.3.
Background: Under AmigaDOS 1.3, the current directory for the shell
GFFT creates to run GNUPLOT is SYS:, rather than the directory from
which GFFT is started. Under 2.0 and greater, the current
directory is the one from which GFFT is started (which is where the
.info file is found if GFFT is started from the Workbench).
Workaround: Follow the directions in INSTALLATION, which
specifically advise that you put GNUPLOT in your C: directory,
where it can always be found.
If you have no harddrive, and only one floppy drive, you may have
to make a special boot disk with GNUPLOT (and GFFT, if possible) on
it. Be careful about deleting commands (GFFT uses several), and be
sure to keep sys:utilities/more. In this case, both GFFT and
GNUPLOT can be in the root directory of the disk, which will become
SYS: after booting. This can be done (I have done it). See
discussion of the commands GFFT uses in the INSTALLATION file.
Plans: Future releases will probably not support 1.3.
(11) GNUPLOT terminates when I try LogX with Time3D.
Although this is a GNUPLOT bug (to be fixed in release GNUPLOT
release 3.6), it is also worked around automatically by GFFT
starting with GFFT release 1.15.
Background: Apparently there is a bug in GNUPLOT such that in 3D
display modes it finds a zero X value to complain about even when
there is none.