Yup, I like that idea too though it seems like it should be done by
routing through the connection interface. It would be interesting to
see how much the current stdout relies on information that wouldn't
necessarily be available in an event stream. Of course, if you're
going to go this rou
On 10/18/2005 8:51 AM, Thomas Friedrichsmeier wrote:
>> I'll volunteer to do your testing on Windows, provided nobody suggests a
>> way to do what you want without your patches. That is, if there's a way
>> for a custom front-end to separate the streams of text coming to
>> ptr_R_WriteConsole thro
> I'll volunteer to do your testing on Windows, provided nobody suggests a
> way to do what you want without your patches. That is, if there's a way
> for a custom front-end to separate the streams of text coming to
> ptr_R_WriteConsole through REvprintf from that coming through Rvprintf,
> then y
I fully support Duncan M (though it's painless for me).
What I wanted to do, and explored, when I was visiting Peter D in
Copenhagen nearly 2 years ago, was to XML-ize the output stream, so
that I could mark it up. From that, it would be reasonably simple to
parse output (provided you marked it u
I'll volunteer to do your testing on Windows, provided nobody suggests a
way to do what you want without your patches. That is, if there's a way
for a custom front-end to separate the streams of text coming to
ptr_R_WriteConsole through REvprintf from that coming through Rvprintf,
then your ch
> I second the point about not having made a case, and also that (from the
> part deleted below) about needing to understand the internals before
> proposing changes.
I'll try to make the case below point d). I fully accept rejection of the more
daring part of my proposal, but the part about ptr_
