Bug in TTree::ReadFile

ROOT
1

Hi, I am using TNtuple::ReadFile (inherited from TTree) and I noticed an inconsistent treatment of #comment and blank lines in the .csv file that I am trying to read.

I am reading the csv file (in CINT) with:

TNtuple tn("tn","tn","x:y:z");
tn.ReadFile("testreadfile.csv","",',');

If testreadfile.csv contains the following:

1, 100, 300
2, 200, 300

#6, 299, 284
5, 388, 294

(including the blank line), then ReadFile only reads the first two entries. If instead testreadfile.csv contains:

1, 100, 300
2, 200, 300
#6, 299, 284

5, 388, 294

then all three entries are read. According to the docs, blank lines are supposed to be skipped along with lines starting with ‘#’. It seems to be getting confused about something. With only the blank line or only the comment line, all three entries are read.

By the way, how hard would it be to allow more than one type of character to be specified for the delimiter? The signature would be different (using a string instead of a char literal), so it would be just a new overload of ReadFile. How hard would it be to also allow the user to specify the comment character?

Jean-François

2

[quote=“jfcaron”]Hi, I am using TNtuple::ReadFile (inherited from TTree) and I noticed an inconsistent treatment of #comment and blank lines in the .csv file that I am trying to read.

I am reading the csv file (in CINT) with:

TNtuple tn("tn","tn","x:y:z");
tn.ReadFile("testreadfile.csv","",',');

If testreadfile.csv contains the following:

1, 100, 300
2, 200, 300

#6, 299, 284
5, 388, 294

(including the blank line), then ReadFile only reads the first two entries. If instead testreadfile.csv contains:

1, 100, 300
2, 200, 300
#6, 299, 284

5, 388, 294

then all three entries are read. According to the docs, blank lines are supposed to be skipped along with lines starting with ‘#’. It seems to be getting confused about something. With only the blank line or only the comment line, all three entries are read.

By the way, how hard would it be to allow more than one type of character to be specified for the delimiter? The signature would be different (using a string instead of a char literal), so it would be just a new overload of ReadFile. How hard would it be to also allow the user to specify the comment character?

Jean-François[/quote]

This problem is fixed (I hope so) in the trunk and v5-34-00-patches. Give it a try.