Just a guess... people are sometimes confused about warnings showing immediately (STDERR) while print statements are buffered (STDOUT).
This can give the impression of differing execution order.
see also Suffering from Buffering
| [reply] |
Sorry for the vagary. I don't have specifics.
But yes, lines of code, not line of data from a file.
I haven't seen the code (yet). I don't think it'll be due to iterating through a hash. He's too good not to consider that.
The STDERR vs STDOUT sound like a real possibility, one that I'll keep in mind.
I saw something like this years ago when working with Perl/Tk. Correct if wrong, but that would be multi-threaded, interrupt driven thing where synching may not be as simple as observing what lines of code come before others.
Good ideas, thanks for the input. Will add to this if/when I get code. Reducing the script down to the bare bones that still demos the behavior is a good idea. Done that sort of thing before, good strategy.
| [reply] |
Unfortunately, with your lack of details, it will take a much stronger mind-reader hat than mine is to give you a reasonable guess -- but there might be a monk with better ESP skills than I have.
- I am assuming by "executes lines", you mean executing lines of source code, not parsing lines of a data file. But that is just an assumption
- Perl executes code in the order defined by the logic of the code; unless there is a difference in the logic (or the inputs that control the logic), it should execute in proper order
- Are there a lot of random variables (either created by rand, or because of not-determined-by-the-program inputs? That could explain change in order
- Is the code iterating through a %hash or $hashref? The order of keys and each are not guaranteed to be the same from run-to-run or from machine-to-machine. This is my best guess.
- Is it possible to provide clues in the form of a SSCCE? It doesn't have to be the same data or the same code, as long as it shows the same issue -- replace real data with facts about disney characters or automobiles or fruit or something; strip out all the irrelevant code until you have the shortest possible example which still shows things being executed "out of order". Include copious print statements, to show the state of input or state-control variables. If possible, grab output from your SSCCE run on different machines (or different runs) that show this change in the execution order.
- pre-create update: I just saw the Anonymous Monk post, and STDOUT vs STDERR is another excellent idea to check.
| [reply]
[d/l]
[select] |
Could it be writing to both STDOUT and STDERR? Otherwise, have you reduced the code down to the minimum needed to reproduce? SSCCE | [reply] |
