On Sat, 10 May 2003 17:50:55 +0900, Brian Candler wrote:

> I don't use Windows either, but Windows does support processes with pipes
> between them, based on what I've seen posted here. It works as well as you
> can expect any O.S. feature in Windows to work :-)

In rubys source for "io.c" there is a bunch of WIN32 checks 
> grep WIN32 io.c
#if defined(MSDOS) || defined(__BOW__) || defined(__CYGWIN__) || defined(_WIN32) || defined(__human68k__) || defined(__EMX__) || defined(__BEOS__)
#if defined(MSDOS) || defined(__CYGWIN__) || defined(_WIN32)
#if !defined(DJGPP) && !defined(_WIN32) && !defined(__human68k__)
#if defined(HAVE_FCNTL_H) || defined(_WIN32)
#if defined(_WIN32) || defined(DJGPP) || defined(__CYGWIN__) || defined(__human68k__) || defined(__EMX__)
#if defined (_WIN32) || defined(DJGPP) || defined(__CYGWIN__) || defined(__human68k__) || defined(__VMS)
#if defined (_WIN32) || defined(DJGPP) || defined(__CYGWIN__) || defined(__human68k__) || defined(__VMS)
#if !defined (__CYGWIN__) && !defined(_WIN32)
#ifdef _WIN32
#ifdef _WIN32
#if defined (_WIN32) || defined(DJGPP) || defined(__CYGWIN__) || defined(__human68k__)
>
The first 4 of them seems OK.. the rest of them is where I see 
that windows requirs special attention. Windows is wierd.

 
>> ruby-in-a-sandbox: Im working on editor project where I "think" I need
>> this feature (my knowledge about unix-TTYs is minimal).
> 
> And you need it because you want the vim-like feature: "run this program and
> capture its output into the editor buffer"?

No. My rationale for using ruby-sandbox is that many applications gets
started from the desktop (not the console). Thus thier output is hidden.
I have to get comfortable with this feature, before I can tell if its
a good or a bad feature. 

Further more I want to be able to run my favorite ruby-scripts unmodified.
Example: rubyunit outputs to stdout/stderr. I don't want to make changes
to their source. 

Because its a feature I need myself, then I assume that many people would 
have interest in this. Im just following my very bad intuition :-)

 
> My argument is that the capturing belongs at the point where you run the
> external program, just as if you were writing your code in C++ directly, not
> in some framework where you have to jump through hoops with pipes and
> threads (which are dangerous here)

I want to give people this choise, between the blue or the red pill :-)

 
> How about adding a FAQ to your tutorial? Here's one I contribute.

Thanks.. This is a good Q&A, I will add it.
 
>   A. If you don't mind mixing the child's stdout and stderr, you might just
>      get away with using shell redirection:
>            string = `someprog args 2>&1`

This is the answer I have bumped into most-frequently on google.
BTW: isn't this kind of redirection shell-specific (tcsh, zsh, ksh).

I just saw your RCR.. nice
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/71107

[snip a short working example]
[snip the reverse parallel]

Great contribution.. I will certainly add it :-)

 
> If you were writing your editor entirely in C++, or entirely in Ruby for
> that matter, you'd have the same issue. So this isn't really anything
> specific to embedding Ruby.

Yes, this is not specific to ruby. 
 

> On a different point, I hope that catching exceptions is an area you have
> covered or will cover in the tutorial?

I have a section about this: It covers how
* catching ruby exceptions and translating them into c++ exceptions
  (with full backtrace).
* catching c++ exceptions and translating them into ruby exceptions
  (no backtrace).

Look at the "Exception Handling" section and tell me what you think:
http://metaeditor.sf.net/embed/


--
Simon Strandgaard