Arity mismatch

Hi all,

I have an item file (produced the same way as all the others we’re using this quarter in 567) that gives this error whenever we process it with [incr tsdb()]

read_tuple(): arity mismatch (16 vs. 15) for ‘item’ (300)

Does anyone have any advice on how to chase this down? Also, is (300) an error code, or an i-id or something else?


The sort of surprising thing is that this isn’t a fatal error — processing the profile works anyway…

My just throwing stuff out there guess is that there’s a line with an extra a delimiter (at sign?), so that line is just ignoring a value.

I don’t know how to do this in emacs, but you should be able to do it with grep with something like:

grep -nE “^(@[^@]*){16}$”

Which should give you a line number

Thanks TJ – that’s not returning anything (and it still doesn’t if I replace 16 with 15).

1 Like

I’ve looked at the source code for the tsdb program, and it looks to me as though the text in parentheses – 300 in this case – is taken from the item file and is where the program thinks the problem is.

Thank you! Indeed, item 300 is using @ as part of the orthography of one word…

1 Like

But the symbol should be escaped somehow? How to avoid this problem?

This may now be moot, but for posterity’s sake…

The regular expression expects an empty first field (i.e., the line starts with @), which is not true of item files because the first field is the required i-id. Also, as Emily hinted at, since the @ delimits fields, there would be 15 when the line seems to have 16 fields. This might work better:

grep -nE "[^@]*(@[^@]*){15}$" item

You can also use awk to print the line numbers of records without the expected number of fields:

awk -F'@' '{ if(NF != 15) print NR }' item

See the sections about formatting/escaping in the ItsdbReference wiki or the delphin.tsdb module documentation. E.g., from the latter:

The characters and their escape sequences are:

@          ->  \s
(newline)  ->  \n
\          ->  \\

Every literal @ in TSDB files needs to be escaped. Sometimes they sneak in when files are manually edited or created using tools unaware of the formatting conventions. Woodley’s mkprof, PyDelphin’s delphin mkprof, and of course [incr tsdb()] will escape things correctly.


Thank you, Michael!

I suspect this error was coming in in the AGG processing pipeline (taking IGT from e.g. Toolbox, making Xigt, and then item files.) I’ll make a note on our end.