confor tonex not producing correct Nexus file

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run confor tonex
2. nexdata doesn't open in Mesquite because #NEXUS is missing from first line, 
even though it is in the TONEX file, and the filename doesn't end in .nex. 
3. once the file is edited to correct these problems and the file is opened in 
Mesquite, character descriptions are truncated. 

What is the expected output? What do you see instead?

The file should be a valid #NEXUS file, so the programs like PAUP or Mesquite 
will open it. But see work-around below. 

What version of the product are you using? On what operating system?

DELTA Editor 1.0 (2022)
date: 2013-02-21 14:16:25 Eastern Summer Time (New South Wales)
free memory: 388 MB 
total memory: 501 MB 
max memory: 1790 MB
java.version: 1.6.0_24
java.vendor: Sun Microsystems Inc.
os.name: Linux
os.arch: amd64
os.version: 3.2.0-37-generic
user.language: en
user.region: null
user.dir: /home/buz

Please provide any additional information below.

The ad hoc workaround for this is to edit the tonex file to put in #NEXUS 
twice, and to add .nex to the output file name (this was a necessary change in 
the original DELTA, too). 

The truncation of the character descriptions is also a carryover from the 
original DELTA confor tonex, as it had a limitation on the number of characters 
in a variable (see Dalwitz post on this subject on DELTA-L from several years 
ago). I think this could be easily fixed by making the character variables be 
an arbitrarily large number, or making its size dynamic. 

Original issue reported on code.google.com by [email protected] on 21 Feb 2013 at 3:29

[GoogleCodeExporter]

Thanks for the report Buzz.
I have fixed the missing #NEXUS problem.  

A build containing the fix will be available at ftp://ftp.csiro.au/Open-DELTA/ 
tomorrow.

The truncation one is interesting - without knowing anything about the programs 
that read nexus formatted data I decided it was safer to match the output of 
CONFOR as closely as possible.

One different I am aware of is documented in: 
http://code.google.com/p/open-delta/issues/detail?id=66  - I would be 
interested in your take on this issue as there are quite a few values in the 
matrix generated for your dataset where Open DELTA is producing a ? where the 
original would produce a - and vice versa.  I haven't looked closely into this 
but I am presuming at least some of those differences are due to Issue 66.

Original comment by [email protected] on 21 Feb 2013 at 6:24