http://qs321.pair.com?node_id=1134851


in reply to Re: Missing \t in print output
in thread Missing \t in print output

Hi,

Thanks for your question. You are correct, I've cropped the output to only show where the problem appears.

So the ($chrInterval,$startInterval,$endInterval,$block,$order,$warning) elements don't appear, and they do not change within the NORMALBLOCK loop.

However, for each iteration of the SP loop, the elements ($newSp,$chr,$start,$end,$strand,$size,$comment) do change. The problem only happens when I print those elements separated by \t.

The whole line is 251 elements and would be unreadable on here, and won't fit in either apparently and unfortunately the problem only arises when I use a large number of species, ie. a large array.

Also note that this happened without any join step as well, when I was just printing the elements as they were defined.

Please let me know if I can make things clearer.

Replies are listed 'Best First'.
Re^3: Missing \t in print output
by 1nickt (Canon) on Jul 15, 2015 at 11:57 UTC

    Hi Sophienz,

    Please let me know if I can make things clearer.

    Post a complete, working test script that shows your problem. Fine if it needs a 251-element array, just make one:
    push @long_list, $_ for (1001..1251);

    Cut out all the code that doesn't affect your problem. Start a new test script with just the loop that is giving you trouble.

    Isolate the problem. Make it happen when you don't have your data in the script. That will prove whether or not the data are to blame.

    The monks don't need to see all your code, but neither do they need to see an arbitrary subsection of it. They do not need your variable names (unless that is the problem) and they do not need your specific data (unless that is the problem). When the problem is programming, your logic, or, Mysteriously Unidentified, the monks need a small, self-contained, working test script that demonstrates the problem.

    The benefit for you is that while you are making the test script, you will usually discover the problem and see how to fix it. And if not, you'll present the monks with something with which they can help you.

    The way forward always starts with a minimal test.
[reply]
[d/l]
[select]
      Thank you for your suggestion, I will make a simple test script that hopefully reproduces the problem. And my apologies for not understanding the correct format, as this is my first post.
[reply]
Re^3: Missing \t in print output
by Anonymous Monk on Jul 15, 2015 at 11:56 UTC
    I see. You're saying the example output shows only middle parts of lines. Well...

    Thinking logically, there are four possibilities:

    1. Bug in your program
    2. Bug in your tool that you use to view the output file
    3. Bug in Perl
    4. User error
    So,
    1. I don't see any apparent bugs in the snippet you provided. Although some things are strange, for example, if ($nbGABlocks == 0) {... doesn't seem to have any effect, since @arrayToPrint is emptied before appending more elements anyway (in the NORMALBLOCK loop). Bugs are not impossible, but they must be somewhere else...
    2. How are you viewing the file?
    3. That kind of bug in Perl seems unlikely... What is the Perl version?
    4. Yeah, how are you viewing the file? For example, you're opening the file for appending, are you making sure you're viewing the new part and not the old one?
    There is a number of 'paste your code here' sites on the Internet, e.g. hastebin.com. Would it be possible to paste the output of Data::Dumper and of your program using it or a similar site? And more of your script, too (ideally something that we could actually run).
[reply]
[d/l]
[select]

      I will test it further but I think number 2. (and 4.!) in your list may have been the problem.

      I was viewing the output in two ways, both through the terminal. Either I was printing to STDOUT and looking at the output directly, or printing it to a file (after removing it) and calling the Unix head method on it. Both gave me the missing \t problem.

      I've now tried to copy the file locally and open it with TextWrangler and TextEdit, and that seems to give the required output. Thank you for your suggestion.

      I was using Perl 5.14.

[reply]
      Come to think of it, there is also a possibility of 'hardware failure'... If all else fails, that might also be worth investigating.
[reply]

In Section Seekers of Perl Wisdom