Bugs in PHYLIP, known or recently fixed

The hemipteran Thasus, a true bug

This page shows only recent bugs, but we make this listing cumulative so that it will have ever more material on it (we never run out of bugs). Not all bugs we find or fix can be shown -- these are only the most dramatic ones.

Known bugs (we're working on them)

Bugs we know how to fix; the fixes will appear in the next release

Bugs we are still intending to work on and haven't yet fixed


Recently fixed bugs

These are listed by the version of the package that fixed them, in reverse chronological order (i.e., latest first). To see what bugs you have in the version of PHYLIP that you have, read down, stopping when you reach your version.

version 3.695 (April, 2013)
version 3.69 (September, 2009)
  • If there are more than about 50 species in the tree, Treedist can fail to compute distances among the trees. This is due to an overflow problem inadvertently introduced in version 3.68. There is no workaround with the 3.68 executable, but if you can recompile you can fix it by replacing line 1179 of treedist.c, which is currently
      maxgrp = pow(2,tip_count);
      maxgrp = 100000;
    This is fixed in version 3.69. Versions prior to 3.68 will not have this problem.
  • In Dnacomp, Pars, and Dollop, if the Shimodaira-Hasegawa test is performed and there are trees perfectly tied with the best tree, the P values were incorrect (being 0 instead of 1).
  • A team from Iowa State University noticed that time was being wasted in calculations in Dnapenny in the bound calculations. This has now been remedied and it should be noticeably faster.
  • In the molecular likelihood programs, ancestral state probabilities were being incorrectly calculated for user trees that had internal multifurcations. This has been corrected.
version 3.68 (August, 2008)
  • We received some reports that Dnaml was freezing on some data sets in the Windows executables. This seems to have been because of incorrect handling of small increases in the log-likelihood, causing the algorithm to fall into loops. It was temporarily cured in version 3.67 by changing the compiler optimization level, downwards from -O3 to -O1. Now the underlying problem of small differences of log-likelihood has been addressed too, so you should use the new Windows executables (3.68) to avoid having these problems on Windows systems.
  • We found that the .DMG (disk image) archive for Mac OS X contained executables for the Intel Mac but not universal binaries that would work on both Intel Mac and PowerPC systems. Oops. We recompiled and reposted the archives (on 23 August 2007). They should work on both kinds of systems now.
  • We were told that on a Linux computer with a 64-bit Intel Itanium chip the bootstrapping program Seqboot creates blatantly wrong bootstrap samples with characters sampled too many times (or none). On a 64-bit AMD processor the program works fine. The problem is in the random number function "randum" in phylip.c. It seems to be a problem with optimization on the GCC compiler. It is cured by dropping the compiler optimization level from -O3 to -O2.
  • In Protdist the program would blow up if it computes a distance greater than 100.0. This is owing to a subscript error in the code that writes out the distances, in line 1874 where
                else if (d[j][k] < 1000.0)
    should have been
                else if (d[i][j-1] < 1000.0)
    If you have this problem and cannot upgrade to version 3.68 or recompile the program with this change, and your data comes from bootstrapping, try omitting just that replicate, or else rerunning the bootstrapping with a different random number seed (which might not happen to drop as many of the sites that caused these two sequences to be so distant).
  • When Dnadist is used and the lower-triangular output format is chosen, the resulting file has headers at the top of columns and is human-readable but is not machine readable. The (temporary) solution is not to use this option for the time being.
  • In Mac OS X, Drawgram produces some alarming lines of text at the top of its terminal window when it first runs. These are just scripting commands that were not erased because we do not clear the screen at the right moment. The workaround is simply to ignore these commands.
version 3.67 (July, 2007)
  • We had our first reports on the behavior of PHYLIP Windows executables on Windows Vista. The programs work fine. The only thing that did not work is the self-extraction program that unpacks the archives. For some reason it did not work on Vista. The work-around was that, after you got an archive file like phylipwx.exe onto your system, you had to change the file extension from "exe" to "zip". Then you had to click on the file. You were presented with options including "Extract all files". If you chose that the archive was unpacked. The programs would then work. Although we provided "zip" archive versions of the package, we have now got a new version of WinZip which is supposed to have a self-extractor that works on Windows Vista, and it was used to produce the self-extracting archive since 27 August 2007.
  • On Mac OS X systems, if our distributed executables are placed in a folder whose path contains a name with an internal blank, such as /Users/ianr/the files/ then the script that causes each of our programs to run when you click on the corresponding icon does not work, and there is an error message. This is a scripting error in our Mac OS X setup, and it was corrected in version 3.67. In the meantime, if you have this problem, the solution is to put PHYLIP in a folder whose path does not have any folder that has a blank in its name. In the above example, all that would be necessary is to rename the folder the files to the_files
  • We are still getting reports of stickiness of the tree, and occasionally of negative branch lengths, in Dnamlk and Promlk which do not do as good a job of searching for best trees as they should. This has turned out to be an issue of nodes getting stuck when they collide in moving them on the "time" scale. Some major changes were in the code in the 3.67 release to eliminate this stickiness and give a good search.
  • An error was made in putting together the matrices for the PAM mutation model in Protdist, Proml, and Promlk. These programs will give PAM calculations inconsistent with earlier (v3.65 and before) versions, and with other programs. The matrices were corrected in version 3.67. This does not affect JTT or PMB models.
  • The W (within-species varation) option of CONTRAST uses somewhat incorrect equations to infer within-species covariances and phylogenetic covariances. These were corrected in version 3.67. Anyone severely impacted by the problem in the meantime should contact me.
  • Protdist sometimes results in distances greater than or equal to 100.000. When this happens, the distance can run together with the previous number in the output file. For example, a distance of 0.31766 followed by one which is 127.43986 might look like this: "0.31766127.43986". This causes trouble in any program that tries to use this distance matrix. One symptom of this may be the program reporting that two distances which are expected to be equal are unequal -- but then printing them both out, and they appear to be equal! In this case it would print out a message warning you that 0.31766 was not equal to 0.31766. It is doing so because one of them is actually seen by it as 0.31766127 and the other 0.31766. In all future versions, there will be a blank printed between the two numbers. For the present, use an editor to find them and insert the blank by hand. If this is difficult, a Sed script (which can be used on Linux or Unix machines) has been written by Doug Scofield, and is available from him at: this link. Many thanks to him for this. As you can see, this problem is the result of us not thinking of what happens when the distances are big, and the fix in the code is trivial -- just ensuring that there is at least one blank between successive distances.
  • Contml, with gene frequencies, has a bug in the transformation to variables that have approximate Brownian motion as their evolutionary process. This can lead to wierd trees. It might be preferable to go back to the 3.5c version if you need to use Contml for this. We believe that this will be correctly fixed in the 3.67 version. If people can recompile the source code, they replace the function transformgfs with this one and recompile (you should be able to save it from your browser using the Save As choice in its File menu.
version 3.66 (August, 2006)
  • Program Treedist was found to compute the Branch Score Distance incorrectly. It will, in most cases, get the branch lengths in terminal branches incorrect and then be likely to find a nonzero distance between trees when they are really identical, and incorrect distances when they are not identical. Alas, there is no workaround to avoid this. All distances done with this option before version 3.66 should be regarded as incorrect unless all terminal branches have the same length, or unless the order of species in the tree is the same as in the first tree in the file. The Symmetric Difference option, which does not use branch lengths, works properly.
  • Program Dnamlk, when run on Linux or Windows systems, sometimes gave negative branch lengths for some branches on the tree. This is bad. Although we at first thought that this was a compiler bug, it seems to be a lack of initialization of some pointers. Program Promlk may have the same problem, as they share code. If you have this problem you can work around it by not using the Global menu option when running Dnamlk (or Promlk). If you need more extensive tree search the J (Jumble) option may be your best bet.
  • On Windows (at least, on Windows xp), our executables for version 3.65 produce output files (outfile) and output tree files (outtree) that have end-of-line characters that result in their being hard to read on the Notepad editor. They appear as one big line. If you use the Wordpad editor, or Microsoft Word itself, the files will be readable. This is and end-of-line compiler setting we got wrong when compiling the programs.
  • Programs Dnaml and Proml sometimes failed to iterate branch lengths in trees enough -- this can result in them failing to find as good a tree as the molecular clock versions Dnamlk and Promlk, a phenomenon that is not supposed to occur. The problem results from the iteration code in function makenewv giving up too easily when branch lengths are very short. The resulting branches get "stuck" at length 0 when they should not. If you can recompile the programs, the problem can be solved by the following changes:
    • In file phylip.h change the value of the constant iterations to 8 instead of 4.
    • In files dnaml.c and proml.c, change function makenewv to replace
         done = fabs(y-yold) < epsilon; 
         done = fabs(y-yold) < 0.1*epsilon; 
    • In dnaml.c, in function makenewv, also replace*
           if (yold < epsilon)
              yold = epsilon;
           if (y < epsilon)
              y = epsilon;
    We think these fix the problem. Some more thorough fixes are implemented in the 3.66 code.
  • The Mac OS X archives (in .dmg form) appeared at first sight not to have any executables directory in the package. This is owing to strange placement of icons once we package the files. The OS X executables are there -- their folder is just way down the window. Use the scroll bar to look for them. You should be able to use the View/Rearrange menus to make the folder icons appear in a more reasonable place. (Or this can be done once all of the contents of the .dmg archive are copied out to another folder).
  • Programs Dnaml and Proml (but not Dnamlk or Promlk), from version 3.64 on, crashed if the Categories (C) option is used, even if all categories are given the same rate of change. This unpleasant behavior does not occur if the menu option for "Speedier but rougher analysis" is changed to "No, not rough". That slows down the run but allows it to succeed.

    The fix turns out to be that all instances in dnaml.c of calls to function copynode (or all instances in proml.c of calls to prot_copynode) that involve an argument lrsaves should have the third argument be rcategs instead of categs.

  • In Seqboot, when menu item J is set to Permute species within characters it is impossible to change menu item W (character weights). This is a glitch in the menuing code. If you can change the source code and recompile, change at line 215 of seqboot.c:
            ((permute || ild || lockhart)
              && (strchr("ACDEFSJPRXNI%1.20",ch) != NULL)) ||
    to be:
            (permute && (strchr("ACDEFSJPRWXNI%1.20",ch) != NULL)) ||
            ((ild || lockhart) && (strchr("ACDEFSJPRXNI%1.20",ch) != NULL)) ||
    If you are stuck with our executables and need this feature, you can also work around it in the following devious way:
    1. Set menu item J to some other setting where menu item W appears in the menu, such as Bootstrap,
    2. Change menu item W
    3. Then change item J to Permute species within characters
    4. Our Makefile for Unix had some problem finding some of the X-windows libraries on Mac OS X systems on Intel Macs. This prevented the compilation of Drawtree and Drawgram. You might have had to use those two programs by using their PowerMac Mac OS X executables. All the other programs did compile and run correctly on Intel Macs.
version 3.65 (August, 2005)
  • Protpars sometimes gave the result "0 trees found" or else simply hung and did not complete its run. This was a bug. The program should always get at least one tree -- if it does not, that is a bug and not a judgement on your data, provided the data file is in our format!
  • Proml and Restml, and maybe some others, seg-faulted when run on enough multiple data sets, as in bootstrapping. If you have a version that has this problem and can recompile the programs, here is a fix for Proml and Restml. In function "inputdata", replace the lines
      if ( firstset ) alloclrsaves();
      else resetlrsaves();
      if ( !firstset ) freelrsaves();
    and you can also eliminate the now-unnecessary function "restlrsaves". (Thanks to Jacques Rougemont for this).
version 3.64 (July, 2005)
  • Treedist had trouble on Windows systems reading trees. This was due to problems with the ftell command on CygWin. It has been fixed by having the files read as binary files.
  • Trees with branch lengths compared using Treedist may have incorrect distances when evaluated as unrooted trees, owing to miscalculation of branch lengths for the bottommost branches.
  • Runs of Seqboot on Mac OS X systems with gene frequencies data have showed incorrect results -- wrong numbers of loci sampled, for example. This is due to bad code generated by the Metrowerks Codewarrior compiler when set to higher levels of optimization (our source code is OK). We will recompile the program at a lower level of optimization in the next bug-fixing release. If you can follow our compiling instructions and have this compiler, you can produce a correctly working executable. Alternatively you can use the gcc compiler and use our Unix Makefile to recompile this program (by typing "make seqboot"). This is quite easy to do and all Mac OS X releases have the gcc compiler in them -- it only needs to be installed.
  • In runs of Proml, Dnaml or Restml with user trees, if one puts in a user tree with an internal multifurcation and asks the program to re-estimate the branch lengths for that tree, the branch lengths in only two of the furcs will be re-estimated if they already have branch lengths. This is due to a bug in the function "initrav" causing it to fail to enter one or more of the subtrees. A workaround until the next release is as follows: Use Retree to remove all branch lengths on the tree. The tree's branch lengths will then all be re-estimated when it is used as a user tree.
  • The example output in the Treedist documentation gives distances computed by version 3.62 or earlier, in which the tree distance is not square-rooted.
version 3.63 (December, 2004)
  • The DNA and protein likelihood programs could have problems with underflow if very large numbers of sequences were analyzed. Underflow protection code was needed to make this much less likely to happen.
  • A number of programs had the problem that when M (multiple data set) runs are done, if the data sets differ in the number of characters from data set to data set, they only allocate enough memory for the first data set, and then can crash on subsequent, larger, data sets. For bootstrap and permutation runs this should not be a problem, but for jackknife runs it might be. One work-around until we fixed this was to move the data set with the most characters to the front, so that enough space is allocated. The programs we think had this problem are: Clique, Dnacomp, Proml, Promlk, Protdist, Dollop, Gendist, Pars, Restml, and Restdist.
  • When the Branch Score distances are computed in program Treedist, the sum of squares of differences between branches was not square-rooted, as the documentation web page says it is.
  • Fitch and Contml may die when asked to do Jumbling, in some cases.
  • Dnaml had inconsistencies in results when branch lengths of a user tree were estimated, and when the same numbers were provided in the user tree.
  • Trees fed into Contrast could cause trouble if they contained unifurcations (forks with only one descendant). The program did not complain about this, as it should have.
  • End-of-line characters in input files in certain cases caused trouble in Mac OS X (for example when the files came over from Windows).
  • When printing a rooted tree out in Kitsch, the root was not placed intermediate between its two decsendants.
  • The variable numtrees was sometimes used when still uninitialized in Pars.
  • Restdist had a site-aliasing bookkeeping bug that could lead to incorrect results.
  • Restml would not allow site lengths greater than 8, because an array was of fixed size when it should have been dynamically allocated.
  • The variable name howmany conflicts with predefined names in some older Sun compilers. It will henceforth be deliberately misspelled to avoid this.
  • With larger data sets being analyzed, Proml, Promlk, Dnaml, and Dnamlk have had to have underflow protection code installed, as likelihoods were getting too small.
  • Treedist was giving wrong answers when asked to compute all distances between trees in two files that had unequal numbers of trees. This was a bookkeeping error.
  • The variable scanned was uninitialized in the Drawtree and Drawgram programs, which could sometimes cause problems.
  • The lack of initialization of a variable, delta in Dnadist meant that different results could be obtained from interactive runs than were obtained in runs under the control of a command file.
  • Dnadist was sometimes stopping when encountering sequences that had an infinite or indeterminate distance (i.e. when the sequences were too different or when they had no sites in common), when it should have printed out "-1" and continued. When it was supposed to print "-1" in some recent versions of PHYLIP it printed "1.0000" instead.
version 3.62 (September, 2004)
  • The ftp link used by our "Get Me PHYLIP" page to fetch the version 3.62 Linux gzip'ed sources and documentation archive was incorrect until recently (I hadn't updated it to fetch version 3.62). If you had trouble fetching this archive in version 3.62, please try one more time. It will work now.
  • A number of people have found, with Fitch and with Contml, that version 3.61 crashes on multiple Jumbling (option J) or on bootstrap runs. This is fairly serious. It does not happen with versions of these programs earlier than 3.6 (such as 3.6a3 or 3.573c). This release fixes these problems.
version 3.61 (August, 2004)
  • In dnaml.c there was some mistaken code doing rate standardization that made the program compute incorrect likelihoods for user-defined trees where the program is using their branch lengths.
  • In dnaml.c some bookkeeping code associated with tree structures caused it to crash after only a few replicates when you do a multiple data sets run (for bootstrapping).
  • The code for the Shimodaira-Hasegawa test has been in error for some time. The effect of this will be to cause the test to fail to find significance in some cases where it should. This affects Shimodaira-Hasegawa tests (ones with more than two user trees) for many of the programs. If you have downloaded version 3.6, I urge you to replace it with 3.61 as soon as you can. If you have done SH (Shimodaira-Hasegawa) tests, I recommend strongly that you rerun those using version 3.61.
version 3.6 (July, 2004)
  • The transform of gene frequencies to Brownian motion in Contml was not very good. It has been replaced by an extension of the 1975 method in Elizabeth Thompson's book Human Evolutionary Trees, using orthogonal coordinates on a plane tangent to the mean of the gene frequencies among species.
  • In Retree, when you delete two adjacent clades, the stem connecting them wasn't marked on the screen as deleted.
  • Numbers in the Contrast output could run into each other if too big.
  • There was no error message for negative branch lengths in Contrast.
  • Dnadist was blowing up if two sequences are identical for some distances.
  • Gendist sometimes made 0.00001 diagonal elements in the distance matrix.
  • Consense generated segmentation-faults on larger cases with more than 1,000 trees.
  • Dnamlk and Promlk could get wrong likelihoods and wrong reconstructions of ancestral states, when there were all of these: gamma-distributed or HMM rates, some autocorrelation among sites, and some sites with weight 0.
version 3.6b (July, 2003)
  • Dnadist versions 3.6a2 and 3.6a3 have a bug that makes it calculate zero values for the similarity between two sequences when the table of fractions of similarity between two sequences is being computed, and when one or both of the sequences has a nucleotide that is ambiguous other then "N", "?", or "-". It affects only similarity values, not any of the distances that Dnadist can compute. To calculate similarity values for those sequences, make a version of your sequence input file that omits those sites. This is necessary only for those sequences -- for all other purposes you should use the values from the full sequences.
  • Proml has a bug that apparently prevents it (in User tree mode) from re-estimating the branch lengths of a tree. This means that if you take a consensus tree and try to re-estimate its branch lengths, it will instead leave them with the branch lengths that Consense gave them. In the meantime, there is no workaround to let you infer branch lengths with the U option, alas.
  • When distances between trees in a file are computed by Treedist, the Windows executables have a segmentation fault on the case where we do distances among all pairs of trees in one file. Users can work around this by duplicating the file and computing instead all distances between trees in one file and trees in the other, which somehow works.
  • Treedist does not give sensible results when the trees in an input tree file do not all have the same list of species. We only intended Treedist to be used with the same list of species in all trees, but there is no error message preventing data of this sort from being analyzed at present.
  • On G3 or G4 Powermacs with MacOS 9.2.1 or earlier, the PHYLIP 3.6a2.1 and 3.6a3 executables for most programs sometimes fail to allow you to give them valid output file names, complaining that they are invalid (when they aren't). This is presumably some interaction between our Metrowerks Codewarrior compiler and those versions of MacOS. If you have this problem you can fix it either by upgrading to MacOS 9.2.2 or by running MacOS 9 under MacOS X. We would be interested in hearing which versions of MacOS our code works in, and with which processors.
  • When two adjacent branches on a tree have zero length, and one plots the tree using Drawtree, the labels are sometimes superimposed on each other and also plotted in the wrong place. A temporary fix until we correct this is to make the branches have nonzero but tiny lengths such as 0.00001.
  • When you use a data set with three species on some of the programs, it will not process them properly because the algorithm assumes that there are at least 4 species.
version 3.6a3.1 A revised version of the Mac executables and sources corrected some bugs that were causing trouble only on that platform:
  • Treedist would not open an output file.
  • Lines in the Macintosh previewing for Drawgram and Drawtree were sometimes too thin to be visible.
  • Drawgram and Drawtree had their default memory size set larger as Drawgram would usually refuse to run.
  • Error messages for being unable to open an output file repeated the word "file" unnecessarily.
  • Pars had the wrong icon, owing to an obscure resource problem.
We have not yet upgraded the non-Mac sources and executables as these problems were Mac-specific.
version 3.6a3 (July, 2002)
  • The JTT protein substitution model calculations in Proml, Promlk, and Protdist in PHYLIP 3.6a2.1 used incorrect matrices. These have since been corrected.
  • Versions 3.6a-3.6a2 of Protdist incorrectly computed the Kimura protein distance. For each pair of species compared, sites having a Serine are omitted from the computation, leading to a distance that may be either bigger or smaller than the correct one. In the C code in line 1737 of file protdist.c replace the line
              if ((long)b1 <= (long)val && (long)b2 <= (long)val) {
              if ((((long)b1 <= (long)val) || ((long)b1 == (long)ser))
               && (((long)b2 <= (long)val) || ((long)b2 == (long)ser))) {
    to fix the bug. If you cannot recompile the program and wish to use the Kimura distance, use the 3.5c version of Protdist which is correct.
  • The program Mix did not handle weights at all. You could use Pars instead (where the weights are specified in a separate file whose default name is weights). Or use Mix from version 3.5c.
version 3.6a2.1
A quick correction of 3.6a2 since:
  • The coefficients of variation of rates among sites (and therefore the alpha shape parameter of the Gamma distribution were set incorrectly after being input by the user.
  • The documentation said Old Style programs read their user-defined trees read from file infile -- this was corrected in the documentation to say file intree.
version 3.6a2 (July, 2001)
These bugs which were present in version 3.6a were corrected
  • Kitsch: couldn't process user trees.
  • Dnacomp, Dnamove, Move, Dolmove, Dollop: couldn't read User with branch lengths successfully
  • Dnamlk: was a tendency for nodes to get stuck together.
  • In Treedist identical trees had nonzero distances if the names of the species were numbers.
  • Dnadist: there was a problem with data sets that had a space after last nucleotide of a segment of sequence.
  • Some of the programs had trouble with jackknife-sampled data sets (produced by Seqboot) which had different numbers of sites (characters) in different replicates.
  • Some of the sequence programs had data-reading problems when there were blanks before a segment of sequences in the interleaved data format.
version 3.6a (July, 2000)
This "alpha release of 3.6 fixed some bugs that had been encountered over the years since version 3.573. Here are some of them:
  • PROTDIST read in weights but did not use them. To get it to use them one can replace the code in line 1446 of protdist.c by:
      lnlike += weight[k]*log(p);
      slope += weight[k]*dp / p;
      curv += weight[k]*(d2p / p - dp * dp / (p * p));
  • The output file generated by PROTDIST contained a section at its front that gives a table of the weights. This would prevent it from working as an input file in the distance matrix program. If this section is edited out, the distance matrix programs will read it properly.
  • The 3.573c Windows95/98/NT executables had trouble running DRAWTREE and DRAWGRAM on many systems. If you see an error saying: DOS/4GW fatal error (1004): syntax is DOS4GW <executable.xxx> you should try various placements for DOS4GW.EXE. If none works you can use an MSDOS window to execute the command
  • When you put a data set that has one or more nucleotides absent (such as having no G's at all), DNAML and DNADIST's Maximum Likelihood option could get upset and divide by zero. A temporary solution was to use the F option to input four base frequencies, none of which are 0.
  • If you used "outfile" as the input file name for most programs, terrible things happened. The program opened "outfile" as a file to put output into (thus erasing its contents) and then tried to read its data from this empty file, causing a psychological crisis. The solution is to rename "outfile" (to "infile" or almost anything else) before using it as an input file for the next program. The 3.6 fix of this problem is to warn the user when about to write output that the file already was in use, and give the user the opportunity to use a different file name.
  • Retree and the user trees options of many programs choked on trees that have comments like "[0.1000]" at the end of the tree, which is the way some of our programs such as Dnapars have of indicating what fraction that tree is of all trees generated by a run. If you want to get versions before 3.6a to accept these trees, you should remove these extra comments at the end of the trees and see if this fixes it. However that error message is also the one you get when you incorrectly try to use a rooted tree in a program that wants an unrooted tree (see our Frequently Asked Questions ).
  • If a data set that has two or more species that have the same name was used to create a set of trees, and these were fed into Consense, one could get groups appearing in the consensus trees that have more than 100% support, and there is no error message about this. This can be avoided by making all species names different before producing the trees.
  • When species names in the data had underscores in them (the "_" character) and a tree file was used, the underscores in the tree file got translated into blanks, and then the program would complain that it can't find that species in the data. Changing the underscores in the species names of the data file to blanks or changing the names in both files to dashes (or anything) will solve this.
version 3.573
  • There were multiple reports of PHYLIP programs not working on MacOS 8.5. We cured this by recompiling it on an 8.5 system with a newer version of the Metrowerks compiler.
  • Our PowerMac executables had been crashing if a row of dots was printed out that reached the right-hand margin of the text window. Some programs would do this on large data sets (unfortunately those windows are too primitive to be resized). To cure this, you spreviously had to turn off the option in the menu that instructed the program to report on the progress of the run. In some cases this meant that you did not know when the run had finished, except that then the File menu once again responded to the mouse. This problem has now been cured by recompiling with a later version of the Metrowerks compiler.
  • Fixed memory allocation bug in Dnapars which caused it to crash on long runs such as multiple bootstraps.
  • Our Windows version has not been a good citizen when running on Windows95 systems. It tended to hog the machine and not let other programs and processes get enough processor time. This has been a result of having only 16 bit (Windows 3.1) style Windows executables. With this version we have now made available 32 bit Windows executables as well. These work on Windows95, Windows98, and WindowsNT, and they should allow other processes and programs to proceed.
version 3.572
  • DnaMLK failed to correctly iterate branch lengths in some user tree cases.
  • SeqBoot generated bootstrap files of sequences that had the number of sequences and the number of sites running into each other, with no blank in between, when there were 10,000 sites of more.
  • Our PCL (Hewlett-Packard Laserjet) drivers in Drawtree and Drawgram generated code that will not print correctly on inkjet printers such as the HP Deskjet series. This was apparently due to the version of the PCL language that we assume being later than the version implemented in those machines.
  • Mix printed out the wrong numbers of steps for user trees after the first user tree. When it is asked to evaluate several users trees it assigns them all the same number of steps, which is the number for the first user tree.
version 3.57
  • The Windows executables were not able to run on Windows 95, so we recompiled them with the Watcom C++ 10.5 compiler, and now they should run well under either Windows 3.1 or Windows 95.
  • Removed the flawed program Coallike (use our other package LAMARC instead).
  • Memory allocation problems in Dnapars prevented some bootstrap runs from finishing.
  • File ownership problems in PICT files produced by our executables of Drawgram and Drawtree in the 680x0 Macintosh and PowerMacintosh versions.
versions 3.56
  • The input for the Categories option in various programs would not read correctly in the Macintosh versions.
  • The Categories and Weights options would not work together properly in DnaML, DnaMLK, and Dnadist, which have both of these options.
  • More species were allowed in Retree (500 instead of 100).
  • PICT files output was being written incorrectly in Drawgram and Drawtree.
  • New icons were drawn for the Macintosh executables. These icons were also set up for the Windows executables.
  • The BinHex (.hqx) file format was added to our ftp area as an alternative method of distributing our 680x0 Macintosh executables.
versions 3.54 and some executables of 3.55
  • The PowerMac executables became available, thanks to Don Gilbert of Indiana University, who first compiled them.
  • Problems reading options in our Macintosh code.
  • Incorrect algorithm for generating permutations in SeqBoot (thanks to James Brown of AFRC in England for detecting this and suggesting the fix).
  • Some problems with the DnaMLK categories (C) and jumble (J) options.
  • Executables for 386 Windows and for 386 DOS were recompiled to allow more adequate stack size.
  • 386 Windows executables had math coprocessor emulation set up incorrectly and would give strange results (fortunately, easily noticeable strange results) on 386 or 486 systems that did not have math coprocessors (such and 486sx processors). This was fixed by using the WEMU387.386 emulation library.

[Phylip icon here] ... to the PHYLIP home page