F
Federico Ceccatto
Hello,
For the past year I've been building an XP Python/wxPython shell of
sorts for several dozen command line FORTRAN tools developed for
various material science problems. Given how the methods and how-to's
have been lost to everyone but the original creators for these 80's to
90's pieces of code and the fact I am no physicist, I've relied on the
subprocess module in order to feed info according to their output.
I/O in general has worked wonders up to a handful of applications that
act in the strangest of ways. I strongly believe it's a bug in the
original programs/compiler, but that gets me nowhere. There's also the
fact the error shows up in two tools compiled with different FORTRAN
versions and made by different authors. I'll probably go cry for help
in a FORTRAN forum too.
Can't quite paste code due to its size and threaded nature, but
basically I have the output PIPE rigged to a class that parses text
into a tidy list (for easier analyzing), and a function that returns
input characters to the stdin method of the subprocess object
according to wether there has been any new data from stdout and
certain conditions (specific to the executable) are met.
I've got prints and repr()s everywhere to check nothing is ignored,
written multiple times or the child process is reporting errors. As I
mentioned, it works wonders for several other executables. None of the
obvious errors seem to be the case. As far as I can tell, the
input/output is ideal until the misbehaviour described below rears its
ugly head.
This is the kind of 'bugs' i've run into, perhaps someone could shed
some light onto them?
- Sometimes execution of child process (in this case, NTVDM.exe and
its children) stops and the object is destroyed for no reason
whatsoever. Very silent, no errors.
- Sometimes '\x03' as input is ignored, working simply as a '\n' of
sorts, while most of the time it simply kills the program as expected.
- Sometimes specific points in the code where the user is asked for
input and execution should be temporarily halted are ignored, as if
somehow it got a newline character.
None of these bugs are reproducible by running the same child
processess via NTVDM.exe through say, cmd.exe and such.
This has been driving me nuts for the last three weeks...
Thanks for your time.
- F.
For the past year I've been building an XP Python/wxPython shell of
sorts for several dozen command line FORTRAN tools developed for
various material science problems. Given how the methods and how-to's
have been lost to everyone but the original creators for these 80's to
90's pieces of code and the fact I am no physicist, I've relied on the
subprocess module in order to feed info according to their output.
I/O in general has worked wonders up to a handful of applications that
act in the strangest of ways. I strongly believe it's a bug in the
original programs/compiler, but that gets me nowhere. There's also the
fact the error shows up in two tools compiled with different FORTRAN
versions and made by different authors. I'll probably go cry for help
in a FORTRAN forum too.
Can't quite paste code due to its size and threaded nature, but
basically I have the output PIPE rigged to a class that parses text
into a tidy list (for easier analyzing), and a function that returns
input characters to the stdin method of the subprocess object
according to wether there has been any new data from stdout and
certain conditions (specific to the executable) are met.
I've got prints and repr()s everywhere to check nothing is ignored,
written multiple times or the child process is reporting errors. As I
mentioned, it works wonders for several other executables. None of the
obvious errors seem to be the case. As far as I can tell, the
input/output is ideal until the misbehaviour described below rears its
ugly head.
This is the kind of 'bugs' i've run into, perhaps someone could shed
some light onto them?
- Sometimes execution of child process (in this case, NTVDM.exe and
its children) stops and the object is destroyed for no reason
whatsoever. Very silent, no errors.
- Sometimes '\x03' as input is ignored, working simply as a '\n' of
sorts, while most of the time it simply kills the program as expected.
- Sometimes specific points in the code where the user is asked for
input and execution should be temporarily halted are ignored, as if
somehow it got a newline character.
None of these bugs are reproducible by running the same child
processess via NTVDM.exe through say, cmd.exe and such.
This has been driving me nuts for the last three weeks...
Thanks for your time.
- F.