Bugs in Version 2 Alpha of DsTool
The version of DsTool present on the ftp server cam.cornell.edu is an
alpha version, and was packed before linux machines were readily
accessible in our environment. There are several easy to fix bugs,
as well as more delicate issues which can be addressed in the code.
As mentioned on the web page
DsTool at the Geometry Center, DsTool 2.0 alpha may well be shortly superceded. However if you are
using or considering the use of Version 2.0, the following may be
Thanks to James Heald and John Stimson among others for comments relevant
to some of these issues.
RedHat 6.1 Compatibility
The diff file DsTool Diffs for RedHat 6.1 shows one set of changes from the original distribution that compile
under Redhat 6.1.
Some Easy but Important Bugs to Fix
- Complete Filename Problem
- Especially in the Linux case (e.g Slackware 3+, Redhat 4) the
function filename_completion in complete.c runs into compilation difficulty
because of a reference to a structure anmed "d_namlen".
This can likely be fixed
by adding the line #define HAS_DIRENT_H to the #ifdef LINUX part of
complete.c: In function `filename_completion':
complete.c:109: structure has no member named `d_namlen'
complete.c: In function `file_name_completion_stat':
complete.c:216: structure has no member named `d_namlen'
make: *** [complete.o] Error 1
- Another Approach to the Complete Filename Problem
- The routine complete_filename appears in only four places, and may
be commented out without large loss of functionality.
(File dialogs will no longer recognize abbreviations like tildes for one's
home directory, etc.) The four locations are src/windows/load/load_hnd.c,
src/windows/save/save_hnd.c, src/twoD/print_hnd.c, and src/twoD/complete_name.c.
- Crashes using the Multiple Orbits Panel
- The declaration in the routine mult_data_refresh in the file
src/windows/mult/mult.c should be changed to
- User DsTool Makefile Problem on SGI's
- Because of SGI's aversion to empty macros. This shows up primarily
before one has added any user models of one's own. The Makefile
contains documentation on what to do if one wants to compile a user DsTool
without adding new models.
Alpha Release Aspects
The file README.new_release in the distribution describes the circumstances under which DsTool 2.0 alpha was released.
- The Auto Panel
- was written for an older release of AUTO (and of DsTool) and
does not work.
- The Locbif Panel
- code used what was documented as Sun specific FORTRAN and should
not be expected to work straightforwardly as is on other platforms.
- The Geomview Panel
- writes data in Geomview command file format. So if the data is saved to
filename, it can be viewed by geomview -c filename. DsTool
can also be installed as a geomview module.
- The Tcl Support
- was for Release 7.3 and is unlikely to work unchanged in other releases.
- DSTOOL, OPENWINHOME, and LD_LIBRARY_PATH
- are essential environment variables for successful compilation and
running. (An unset DSTOOL at runtime will usually result in
difficulty finding the color tables for view windows.)
- Installation scripts
- are intended to be run form a csh, not a bash.
- Platforms other than Suns
- require a version of the xview
libraries that works on your platform. Recently, this has been straightforward
for linux and some versions of Irix. Earlier, it seemed to be possible
on some versions of HP, RS-6000, and pre-alpha DEC workstations.
- In the event of Difficulty
- most people will want to say NO to FORTRAN and to tcl.
- DsTool Makefiles
- make essential use of included files from the directory
$DSTOOL/site_specific. For instance a common need is to add a suitable
-L entry to WINLDFLAGS in the file lib_incl.mk there,
so that the X11 libraries will be found at link time.
- Compilation and Installation
- after a problem in the installation script can often be completed by
- but if problems are resistant, a fresh distribution may help.
Feedback on these pages to:
Last Update: May 3, 2000