Add print_record() Fix function.

[blackwinter]

Allows to print the current record during transformation (even at different stages). In Limetrans we implemented it (in a simplified form) as a custom Fix function (cf. #105), but maybe it's useful generally.

Tests are still missing as I'm unsure how to go about it. Any suggestions?

@TobiasNx: Do you also want to do a functional review?

[TobiasNx]

Suggested change

	Prints the current record either to standard output or to a file.
	Prints the current record at the position of the function either to standard output or to a file. It can help to debug the fix-transformation.

[TobiasNx]

This seems to be a nice feature.
Had a look at the documentation but did not try it yet.
I think I could try it in context of ALMA-FIX. I then could try it in the transformation

+1 for merging.

[fsteeg]

Looks good and useful! Two things I noticed:

• I think I'd prefer print_record as the name, since that's what it actually does, while debugging is basically what we use the printed output for. I think that would make clearer what the function does.
• Considering the fact that JSON output is off by default, we add a lot of code for that. Maybe it would make sense to have that on by default?

About the testing issue you mentioned, couldn't we print to a temp file (File.createTempFile) and compare that with some expected result (from a string variable in the unit test)?

[blackwinter]

I think I'd prefer print_record as the name, since that's what it actually does, while debugging is basically what we use the printed output for. I think that would make clearer what the function does.

Yes, I was emphasizing the intended purpose, so it's clearer what you'd use it for. But I'm fine either way. I'll change the name.

Considering the fact that JSON output is off by default, we add a lot of code for that. Maybe it would make sense to have that on by default?

As you maybe noticed, I only added the JSON output here, we didn't have that before in Limetrans. Actually, I'd be fine with having it as the sole output format (the default output is only really useful for display purposes anyway, you can't really do anything with it).

(Regardless of that decision, the JSON encoding will be reused for the to_json() function which I'm working on at the moment; mostly because it comes in a pair with from_json() which we might have a need for.)

About the testing issue you mentioned, couldn't we print to a temp file (File.createTempFile) and compare that with some expected result (from a string variable in the unit test)?

Yes, I'll come up with something for to_json() and then apply it here as well. In the worst (simplest) case it'll just be a plain string comparison, no diff or anything sophisticated.

[blackwinter]

Also, I think I'd like to change prefix to a format string just like destination. So you can choose to have the ID included or not.

[fsteeg]

Actually, I'd be fine with having it [JSON] as the sole output format

+1

Also, I think I'd like to change prefix to a format string just like destination

+1

[blackwinter]

I've added the output of the internal representation back (be32875) as it's the only way to see the record without interference from the encoding process (e.g. in the context of investigating this error).