Georg Baum wrote:
>> Ok, as promised, here's is a rewrite of the code in ispell.[Ch]. I've
>> written it as a stand-alone app, but it could be slotted straight into
>> the lyx sources.
>
> Nice. I guess you are doing this because you want to make the child
> forking working on win32 by adapting the pstreams class?
Correct. In fact, I've isolated the 'device' part from the 'streambuffer'
part in pstreambuffer already. Jon Wakely is gradually merging my changes
into his code, so in future pstreams will work on Windows as well as on
Unix.
> I don't know how much work this is. In case it is a lot, an alternative
> might be to use the qprocess class on win32 (on cygwin the existing
> stuff works, so win32 means we are using qt anyway).
Thanks for the info. I'll keep going with my way for a while longer. I
think that a portable facility to spawn and communicate with child
processes launched by a parent C++ program is something of general use.
Who knows, it might even be of interest to Boost.
The public interface and unix implementation are pretty well done,
although I've yet to merge in lyx's signal_handler code so that system
resources are cleaned up automatically. One nice thing I have
implemented, albeit in an inefficient manner at the moment, is
"scripting" in C++:
pprocess ls("ls -l", pprocess::pstdout);
pprocess wc("wc -l", pprocess::pstdin | pprocess::pstdout);
ls | wc;
string const wc_data = extract_data(wc, pprocess::pstdout);
cout << "wc: " << wc_data << endl;
I'll post again once I'm happy with the unix implementation. Not for a
while yet as I'm otherwise engaged...
--
Angus
