octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Redirectable octave?


From: John W. Eaton
Subject: Re: Redirectable octave?
Date: Tue, 16 Oct 2007 15:24:34 -0400

On 16-Oct-2007, Michael Goffioul wrote:

| In practice, what I'd like to do is the following:
| 1) create 2 pipes: parentIn/childOut, parentOut/childIn
| 2) start a new thread
| [in the thread function]
| 3) dlopen octinterp shared lib and get octave_main symbol
| 4) tell somehow to octave to use childIn/childOut as its "standard" IO
| 5) run octave_main
| 
| The problem is point 4) above: octave uses direct references to standard
| input/output at various places (in the form of stdin/stdout or
| std::cin/std::cout).
| I see 2 cases to achieve point 4):
| 1) redefine stdin/stdout (and dup2 STDIN_FILENO/STDOUT_FILENO);
| however I'd like to avoid that, because this will affect the complete app, 
while
| I just want to affect the octave thread (moreover this seems to be a problem
| on Win32 platform)
| 2) modify octave code such that what octave think is "standard IO" is
| configurable. For instance octave_main could have the signature
| int octave_main(int argc, char **argv, int embedded, FILE* in, FILE
| *out, FILE *err)

Since Octave uses std::cin, std::cout, and std::cerr instead of stdin,
stdout, and stderr, I think it would be best if these were istream and
ostream objects instead of FILE objects, but then that means the
octave_main function has to be a C++ function and you probably have to
deal with name mangling issues when looking it up in your DLL.

| and octave would automagically use the given file descriptors for all its IO.
| The regular octave executable would just have to call octave_main with stdin,
| stdout and stderr.
| 
| Is this imaginable? Am I just dreaming?

It would be possible for us to use our own named references to
std::cin, std::cout, and std::cerr inside of Octave, but that won't
prevent people from writing directly to them in their own .oct files,
so I don't see this as a complete solution to your problem.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]