From djberg96 at gmail.com  Sat Feb  2 12:29:45 2008
From: djberg96 at gmail.com (Daniel Berger)
Date: Sat, 02 Feb 2008 10:29:45 -0700
Subject: [Win32utils-devel] Ruby++ FFI (theoretical)
Message-ID: <47A4A889.4070800@gmail.com>

Hi all,

How does this look as a potential FFI for our theoretical Ruby++ ?

I'm not sure how to do mixins, though. Some sort of special directive? 
Or just add it to inheritance chain?

Anyway, this is just a rough prototype. No attempt at an actual 
implementation yet.

Regards,

Dan

// foo.h - Function prototypes
#define _FOO_H_
using namespace ruby;

// Subclass Object
class Foo : public RubyObject {
    public:

       // Constructor and Destructor
       Foo();  // constructor
       ~Foo(); // destructor

       // Instance Methods
       VALUE method_a();
       VALUE method_b(VALUE);

       // Singleton Methods
       static VALUE method_c(VALUE);
};

// foo.cpp - Implementation
#include <iostream>
#include <foo.h>
using namespace ruby;

/* Constructor */
Foo::Foo(){
    cout << "Hello Worldn";
}

/* Or maybe we setup some sort of default Object destructor instead
  * of making people do it explicitly, unless they have special 
requirements.
  */
Foo::~Foo(){
    delete this;
}

VALUE Foo::method_a(){
    return ruby_int(27);
}

VALUE Foo::method_b(VALUE av_name){
    return "hello, " << ruby_name;
}

static VALUE(VALUE av_age){
    return av_age + ruby_int(42);
}

From phasis at gmail.com  Sat Feb  2 20:24:22 2008
From: phasis at gmail.com (Heesob Park)
Date: Sun, 3 Feb 2008 10:24:22 +0900
Subject: [Win32utils-devel] Ruby++ FFI (theoretical)
In-Reply-To: <47A4A889.4070800@gmail.com>
References: <47A4A889.4070800@gmail.com>
Message-ID: <aea95bc50802021724x19f57c93i7af8cd31c438c1ae@mail.gmail.com>

Hi,

2008/2/3, Daniel Berger <djberg96 at gmail.com>:
>
> Hi all,
>
> How does this look as a potential FFI for our theoretical Ruby++ ?
>
> I'm not sure how to do mixins, though. Some sort of special directive?
> Or just add it to inheritance chain?


I don't know anything about mixin programming with C++.
But some googling will help you like this.
Mixin-Based Programming in C++(http://www.ddj.com/cpp/184404445)

Anyway, this is just a rough prototype. No attempt at an actual
> implementation yet.
>
> Regards,
>
> Dan
>
> // foo.h - Function prototypes
> #define _FOO_H_
> using namespace ruby;
>
> // Subclass Object
> class Foo : public RubyObject {
>    public:
>
>       // Constructor and Destructor
>       Foo();  // constructor
>       ~Foo(); // destructor
>
>       // Instance Methods
>       VALUE method_a();
>       VALUE method_b(VALUE);
>
>       // Singleton Methods
>       static VALUE method_c(VALUE);
> };
>
> // foo.cpp - Implementation
> #include <iostream>
> #include <foo.h>
> using namespace ruby;
>
> /* Constructor */
> Foo::Foo(){
>    cout << "Hello Worldn";
> }
>
> /* Or maybe we setup some sort of default Object destructor instead
> * of making people do it explicitly, unless they have special
> requirements.
> */
> Foo::~Foo(){
>    delete this;
> }
>
> VALUE Foo::method_a(){
>    return ruby_int(27);
> }
>
> VALUE Foo::method_b(VALUE av_name){
>    return "hello, " << ruby_name;
> }
>
> static VALUE(VALUE av_age){
>    return av_age + ruby_int(42);
> }


It looks good up to now.


Regards,

Park Heesob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/win32utils-devel/attachments/20080203/e7f6c812/attachment.html 

From Daniel.Berger at qwest.com  Mon Feb  4 18:19:18 2008
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Mon, 4 Feb 2008 17:19:18 -0600
Subject: [Win32utils-devel] Possible windows-api enhancement - literal data
	types
Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D2F68@ITOMAE2KM01.AD.QINTRA.COM>

Hi all,

This is something I was thinking of adding to the windows-api library
(the win32-api wrapper). Instead of passing just 'P', 'L', 'I', 'B' or
'K' for the prototype or return type, you could pass a stringified
Windows data type, e.g. 'DWORD', 'BOOL', etc, and it would convert it
automatically for you.

For example:

require 'windows/api'
include Windows

GetCurrentDirectory = API.new('GetCurrentDirectory', ['DWORD',
'LPTSTR'], 'DWORD', 'kernel32')

That would be converted to ['L', 'P'] and 'L', respectively, behind the
scenes.

My secret motivation for this is for JRuby, where I don't think a
generic 'P' will work for all pointers, since I need to know the data
type up front in some cases.

Seem reasonable?

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From djberg96 at gmail.com  Sun Feb 17 23:06:31 2008
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 17 Feb 2008 21:06:31 -0700
Subject: [Win32utils-devel] More on cross thread violation on Windows
Message-ID: <47B90447.3030700@gmail.com>

Hi all,

Just investigating the source of errors for the test script at the 
bottom of this email. Here's the relevant code from eval.c:

#ifdef HAVE_NATIVETHREAD
     if (!is_ruby_native_thread()) {
	rb_bug("cross-thread violation on rb_thread_schedule()");
     }
#endif

...

#ifdef HAVE_NATIVETHREAD
static rb_nativethread_t ruby_thid;

int is_ruby_native_thread() {
     return NATIVETHREAD_EQUAL(ruby_thid, NATIVETHREAD_CURRENT());
}

And in ruby.h:

#elif defined(_WIN32) || defined(_WIN32_WCE)
typedef DWORD rb_nativethread_t;
# define NATIVETHREAD_CURRENT() GetCurrentThreadId()
# define NATIVETHREAD_EQUAL(t1,t2) ((t1) == (t2))
# define HAVE_NATIVETHREAD
#endif

So, somehow Ruby's thread ID is no longer the same as what it originally 
started at? How can that be?

Regards,

Dan

# test.rb
require 'windows/console'
require 'windows/sound'
include Windows::Console
include Windows::Sound

CtrlHandler = Win32::API::Callback.new('L', 'I'){ |ctrl_type|
     case ctrl_type
        when CTRL_C_EVENT
           puts "Ctrl-C event"
           Beep(750, 300)
           return true
        when CTRL_CLOSE_EVENT
           Beep(600, 200)
           puts "Ctrl-Close event"
           return true
        when CTRL_BREAK_EVENT
           Beep(900, 200)
           puts "Ctrl-Break event"
           return false
        when CTRL_LOGOFF_EVENT
           Beep(1000, 200)
           puts "Ctrl-Logoff event"
           return false
        when CTRL_SHUTDOWN_EVENT
           Beep(750, 500)
           puts("Ctrl-Shutdown event")
           return false
        else
           return false
     end
}

if SetConsoleCtrlHandler(CtrlHandler, TRUE)
     printf( "\nThe Control Handler is installed.\n" )
     printf( "\n -- Now try pressing Ctrl+C or Ctrl+Break, or" )
     printf( "\n    try logging off or closing the console...\n" )
     printf( "\n(...waiting in a loop for events...)\n\n" )

     while true
     end
else
     printf( "\nERROR: Could not set control handler")
end

From waynev at gmail.com  Mon Feb 18 02:36:27 2008
From: waynev at gmail.com (Wayne Vucenic)
Date: Sun, 17 Feb 2008 23:36:27 -0800
Subject: [Win32utils-devel] More on cross thread violation on Windows
In-Reply-To: <47B90447.3030700@gmail.com>
References: <47B90447.3030700@gmail.com>
Message-ID: <88c9ce410802172336t50bd3c44kf49f08d71b7632e0@mail.gmail.com>

Hi Dan,

"HandlerRoutine Callback Function:
An application-defined function used with the SetConsoleCtrlHandler
function. A console process uses this function to handle control
signals received by the process. When the signal is received, the
system creates a new thread in the process to execute the function."
http://msdn2.microsoft.com/en-us/library/ms683242(VS.85).aspx

Often Win32 creates a new thread to use to call a callback function.
That seems to be what's happening here.

Best regards,

Wayne

On Feb 17, 2008 8:06 PM, Daniel Berger <djberg96 at gmail.com> wrote:
> Hi all,
>
> Just investigating the source of errors for the test script at the
> bottom of this email. Here's the relevant code from eval.c:
>
> #ifdef HAVE_NATIVETHREAD
>      if (!is_ruby_native_thread()) {
>         rb_bug("cross-thread violation on rb_thread_schedule()");
>      }
> #endif
>
> ...
>
> #ifdef HAVE_NATIVETHREAD
> static rb_nativethread_t ruby_thid;
>
> int is_ruby_native_thread() {
>      return NATIVETHREAD_EQUAL(ruby_thid, NATIVETHREAD_CURRENT());
> }
>
> And in ruby.h:
>
> #elif defined(_WIN32) || defined(_WIN32_WCE)
> typedef DWORD rb_nativethread_t;
> # define NATIVETHREAD_CURRENT() GetCurrentThreadId()
> # define NATIVETHREAD_EQUAL(t1,t2) ((t1) == (t2))
> # define HAVE_NATIVETHREAD
> #endif
>
> So, somehow Ruby's thread ID is no longer the same as what it originally
> started at? How can that be?
>
> Regards,
>
> Dan
>
> # test.rb
> require 'windows/console'
> require 'windows/sound'
> include Windows::Console
> include Windows::Sound
>
> CtrlHandler = Win32::API::Callback.new('L', 'I'){ |ctrl_type|
>      case ctrl_type
>         when CTRL_C_EVENT
>            puts "Ctrl-C event"
>            Beep(750, 300)
>            return true
>         when CTRL_CLOSE_EVENT
>            Beep(600, 200)
>            puts "Ctrl-Close event"
>            return true
>         when CTRL_BREAK_EVENT
>            Beep(900, 200)
>            puts "Ctrl-Break event"
>            return false
>         when CTRL_LOGOFF_EVENT
>            Beep(1000, 200)
>            puts "Ctrl-Logoff event"
>            return false
>         when CTRL_SHUTDOWN_EVENT
>            Beep(750, 500)
>            puts("Ctrl-Shutdown event")
>            return false
>         else
>            return false
>      end
> }
>
> if SetConsoleCtrlHandler(CtrlHandler, TRUE)
>      printf( "\nThe Control Handler is installed.\n" )
>      printf( "\n -- Now try pressing Ctrl+C or Ctrl+Break, or" )
>      printf( "\n    try logging off or closing the console...\n" )
>      printf( "\n(...waiting in a loop for events...)\n\n" )
>
>      while true
>      end
> else
>      printf( "\nERROR: Could not set control handler")
> end
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>

From djberg96 at gmail.com  Mon Feb 18 09:02:30 2008
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 18 Feb 2008 07:02:30 -0700
Subject: [Win32utils-devel] More on cross thread violation on Windows
In-Reply-To: <88c9ce410802172336t50bd3c44kf49f08d71b7632e0@mail.gmail.com>
References: <47B90447.3030700@gmail.com>
	<88c9ce410802172336t50bd3c44kf49f08d71b7632e0@mail.gmail.com>
Message-ID: <47B98FF6.3070407@gmail.com>

Yeah, but why would that alter Ruby's thread ID? I'm not saying you're 
wrong, I'm saying I don't get it.

Also, I want to cleanup these warnings and see if it helps:

eval.c
eval.c(962) : warning C4018: '>=' : signed/unsigned mismatch
eval.c(4412) : warning C4646: function declared with 
__declspec(noreturn) has non-void return type
eval.c(10708) : warning C4244: '=' : conversion from 'double' to 'long', 
possible loss of data
eval.c(10709) : warning C4244: '=' : conversion from 'double' to 'long', 
possible loss of data
eval.c(13200) : warning C4646: function declared with 
__declspec(noreturn) has non-void return type
eval.c(13228) : warning C4645: function declared with 
__declspec(noreturn) has a return statement

Thanks,

Dan

Wayne Vucenic wrote:
> Hi Dan,
> 
> "HandlerRoutine Callback Function:
> An application-defined function used with the SetConsoleCtrlHandler
> function. A console process uses this function to handle control
> signals received by the process. When the signal is received, the
> system creates a new thread in the process to execute the function."
> http://msdn2.microsoft.com/en-us/library/ms683242(VS.85).aspx
> 
> Often Win32 creates a new thread to use to call a callback function.
> That seems to be what's happening here.
> 
> Best regards,
> 
> Wayne
> 
> On Feb 17, 2008 8:06 PM, Daniel Berger <djberg96 at gmail.com> wrote:
>> Hi all,
>>
>> Just investigating the source of errors for the test script at the
>> bottom of this email. Here's the relevant code from eval.c:
>>
>> #ifdef HAVE_NATIVETHREAD
>>      if (!is_ruby_native_thread()) {
>>         rb_bug("cross-thread violation on rb_thread_schedule()");
>>      }
>> #endif
>>
>> ...
>>
>> #ifdef HAVE_NATIVETHREAD
>> static rb_nativethread_t ruby_thid;
>>
>> int is_ruby_native_thread() {
>>      return NATIVETHREAD_EQUAL(ruby_thid, NATIVETHREAD_CURRENT());
>> }
>>
>> And in ruby.h:
>>
>> #elif defined(_WIN32) || defined(_WIN32_WCE)
>> typedef DWORD rb_nativethread_t;
>> # define NATIVETHREAD_CURRENT() GetCurrentThreadId()
>> # define NATIVETHREAD_EQUAL(t1,t2) ((t1) == (t2))
>> # define HAVE_NATIVETHREAD
>> #endif
>>
>> So, somehow Ruby's thread ID is no longer the same as what it originally
>> started at? How can that be?
>>
>> Regards,
>>
>> Dan
>>
>> # test.rb
>> require 'windows/console'
>> require 'windows/sound'
>> include Windows::Console
>> include Windows::Sound
>>
>> CtrlHandler = Win32::API::Callback.new('L', 'I'){ |ctrl_type|
>>      case ctrl_type
>>         when CTRL_C_EVENT
>>            puts "Ctrl-C event"
>>            Beep(750, 300)
>>            return true
>>         when CTRL_CLOSE_EVENT
>>            Beep(600, 200)
>>            puts "Ctrl-Close event"
>>            return true
>>         when CTRL_BREAK_EVENT
>>            Beep(900, 200)
>>            puts "Ctrl-Break event"
>>            return false
>>         when CTRL_LOGOFF_EVENT
>>            Beep(1000, 200)
>>            puts "Ctrl-Logoff event"
>>            return false
>>         when CTRL_SHUTDOWN_EVENT
>>            Beep(750, 500)
>>            puts("Ctrl-Shutdown event")
>>            return false
>>         else
>>            return false
>>      end
>> }
>>
>> if SetConsoleCtrlHandler(CtrlHandler, TRUE)
>>      printf( "\nThe Control Handler is installed.\n" )
>>      printf( "\n -- Now try pressing Ctrl+C or Ctrl+Break, or" )
>>      printf( "\n    try logging off or closing the console...\n" )
>>      printf( "\n(...waiting in a loop for events...)\n\n" )
>>
>>      while true
>>      end
>> else
>>      printf( "\nERROR: Could not set control handler")
>> end
>> _______________________________________________
>> win32utils-devel mailing list
>> win32utils-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/win32utils-devel
>>
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
> 


From Daniel.Berger at qwest.com  Mon Feb 25 14:52:45 2008
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Mon, 25 Feb 2008 13:52:45 -0600
Subject: [Win32utils-devel] Taking a stab at a native windows timeout method
Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D3010@ITOMAE2KM01.AD.QINTRA.COM>

Hi all,

Charles O. Nutter posted an interesting entry regarding timeout.rb

http://headius.blogspot.com/2008/02/rubys-threadraise-threadkill-timeout
rb.html

Based on one of the followup comments I tried this:

require 'windows/synchronize'
require 'win32/event'

def wtimeout(sec, exception=Error)
   return yield if sec == nil or sec.zero?
   raise ThreadError, "timeout within critical session" if
Thread.critical
   begin
      terminate_event = Win32::Event.new
      x = Thread.current
      y = Thread.start {
         result = WaitForSingleObject(terminate_event.handle, sec *
1000) 
         if x.alive? && result == Win32::Event::TIMEOUT 
            x.raise exception, "execution expired"
         end
      }
      yield sec
   ensure
      if y and y.alive?
         terminate_event.set
      end 
   end
end

wtimeout(2){
   puts "Starting"
   sleep 5
   puts "Shouldn't reach here"
}

But, it doesn't seem to work. Any suggestions?

Thanks,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From djberg96 at gmail.com  Tue Feb 26 22:28:55 2008
From: djberg96 at gmail.com (Daniel Berger)
Date: Tue, 26 Feb 2008 22:28:55 -0500
Subject: [Win32utils-devel] Making redirecting output with win32-process a
	bit easier
Message-ID: <6037b70c0802261928r1f42a8fdhe41dbef1071d5674@mail.gmail.com>

Hi all,

Inspired by Sander Pool's help request, I came up with this change to
win32-process which makes redirecting stdin/stdout/stderr less of a
hassle:

C:\Documents and
Settings\djberge\workspace\win32-process\lib\win32>diff -u
process.orig process.rb
--- process.orig        Tue Feb 26 22:23:56 2008
+++ process.rb  Tue Feb 26 22:23:20 2008
@@ -270,6 +270,10 @@
    # library. Note that the 'stdin', 'stdout' and 'stderr' options can be
    # either Ruby IO objects or file descriptors (i.e. a fileno). However,
    # StringIO objects are not currently supported.
+   #
+   # If 'stdin', 'stdout' or 'stderr' are specified, then the +inherit+ value
+   # is automatically set to true and the Process::STARTF_USESTDHANDLES flag is
+   # automatically OR'd to the +startf_flags+ value.
    #
    # The ProcessInfo struct contains the following members:
    #
@@ -381,8 +385,10 @@
             if handle == INVALID_HANDLE_VALUE
                raise Error, get_last_error
             end
-
+
             si_hash[io] = handle
+            si_hash['startf_flags'] |= STARTF_USESTDHANDLES
+            hash['inherit'] = true
          end
       }

This would eliminate the need to remember that the startf_flags and
inherit value must be set properly in order for redirection to work
with Process.create. Also, it means less typing for the user. :)

What do you think?

Regards,

Dan

From Daniel.Berger at qwest.com  Wed Feb 27 11:19:15 2008
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Wed, 27 Feb 2008 10:19:15 -0600
Subject: [Win32utils-devel] Process.waitpid blocking in win32-process
Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D3021@ITOMAE2KM01.AD.QINTRA.COM>

Hi all,

Anyone have any ideas on this one?

http://rubyforge.org/forum/forum.php?thread_id=13417&forum_id=320

Thanks,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.