General Modularity Example Module Projects & Files Commands & Scripting Windows Menus Charts Tables Buttons & tools Trees and Taxa Characters & Models Documentation General Utilities Table of Contents Overview To Do: issues and problems Home page of user's manual User's introduction to how Mesquite works Classes and Interfaces (javadoc output)

To Do: issues, problems and bugs

(updated August 2005)

(This list is not entirely written for public consumption)

General

• Threading, synchronization & locking -- Mesquite is not designed around multiple threads and reentrancy in its analytical routines. This may not be a big concern, given that the threads on which commands are executed are queued, so that only one thing can occur at a time (with the exception of painting). Painting is intended to use isolated routines (i.e. not involving substantive results).
• CommandRecord -- currently this is passed around to many routines. Better to avoid this and simply ensure a CommandRecord is attached to any thread. A single static method could then check if execution is under scripting.
• Exception handling and throwing -- currently, Mesquite does not have its own exceptions. If a calculation fails, it returns instead "unassigned" values and may display an alert dialog or output a warning to the console. This may be the best behavior in many cases, since it will be common enough that calculations are incompatible with some situation (e.g. polytomies) that throwing exceptions may become burdensome. On the other hand, for other purposes exception handling could be important. (see modules that crash or hang)
• Modules that crash or hang -- There is not yet a graceful way to supervise (via a supevisory thread?) execution threads that crash.
• Messages and errors to user are under the MesquiteMessage class, or via the alert method of modules, or via System.out.println directly. Need to formulate consistent rules when each message/warning is used (as some present dialog boxes, others just to console)
• Preferences/Settings: -- would be nice if (1) preferences were automatically savable without separate handling vial store & loadPreferences and if (2) the preference handling used the doCommand. That is, an integration of snapshots into the preference system would be desirable

Strings & parsing

• Strings: there are some places where Strings are used too much. use StringBuffer where possible
• XML handling!!! Also alternative to NEXUS
• Parse utilities started as all static, but now that there is a Parser, should more of the old use of static methods (which force more String instantiations) be changed to the new Parser:?

Logging, stamping & Documentation

• Fill in helpStrings for dialogs
• better notes for users of particular systems

Numbers

• MesquiteNumber etc add, multiply, --protect for overflow
• Numbers, NumberArrays should perhaps have explanation strings built in to get rid of need for MesquiteStrings passed into calculateNumber routines????