Prev: Installing libxml-ruby on Windows: zlib
Next: installing gems
From: Eric Armstrong on 28 Jul 2006 20:43
N Okia wrote:
>> I have cygwin running on my machine at home. What's
>> the best way to get ruby running on it?
>
> Startup the cygwin setup.exe program. Select Ruby from the list of
> packages to install. Finish the installation.
>
Spectacular. Didn't know about the program.
Thanks much.


From: Matt Lawrence on 28 Jul 2006 20:45
On Sat, 29 Jul 2006, Sam Smoot wrote:

> I can appreciate the general Ruby community attitude that OS-Threading
> isn't absolutely vital when you're on Linux and have _fork_ at the
> ready, but under Windows it's very painful and really limits the types
> of applications you can build with Ruby (with a reasonable amount of
> effort) IME.

This has been brought up at previous Ruby Conferences. It is my
understanding that it is being worked on. So, relax and watch the
blinking lights.

-- Matt
It's not what I know that counts.
It's what I can remember in time to use.


From: Eric Armstrong on 28 Jul 2006 20:49
Sam Smoot wrote:
>
> My experience has been that IO is blocking in Ruby/Windows. Just try
> creating a background thread to insert into an MSSQL server through
> WIN32OLE+ADO. It's an exercise in futility. :-)
>
Ah. That explains why the two counter threads
worked. There was no I/O going on. But outside
of computational supercomputers, there is zero
point in having threads if they don't let you
keep doing things while waiting for I/O.

> ...under Windows it's very painful and really limits the types
> of applications you can build with Ruby...
>
I'm forced to agree. My little application is dead in the
water. Windows users would have been a major market for it.
It would have helped drive ruby installs, which would have
helped to drive awareness. Similarly with game programs,
music programs, and a wide variety of other interesting
applications.

This limitation is a severe shot in the foot with respect
to platform independence.



From: Srinivas JONNALAGADDA on 29 Jul 2006 05:45
On Sat, 2006-07-29 at 06:18 +0900, Eric Armstrong wrote:
> Below. And now that I'm at work, rather than
> at home, I've been able to determine that it
> works as expected on my Solaris box, but fails
> on Windows XP. (There, the display only updates
> after pressing spacebar or some other key.)
>

Here is an improvisation to your code. This automatically exits at the
end of the set timer, rather than wait for a 'q/Q' from the user.

Greetings,
JS

----
require 'curses'
require 'thwait'

count = ARGV[0] ? ARGV[0].to_i : 100

Curses.addstr "I am going to count #{count}. Press 'q' or 'Q' to
exit.\n"
Curses.refresh

threads = ThreadsWait.new

timer_thread = Thread.new do
count.downto(1) do |i|
Curses.addstr(".")
Curses.refresh
sleep 1
end
end
threads.join_nowait timer_thread

wait_thread = Thread.new do
while true
c = Curses.getch
case c
when ?q, ?Q
return true
end
end
end
threads.join_nowait wait_thread

begin
threads.next_wait
ensure
Thread.kill(timer_thread)
Thread.kill(wait_thread)
end


From: Jan Svitok on 29 Jul 2006 08:53
On 7/29/06, Eric Armstrong <Eric.Armstrong(a)sun.com> wrote:
> So how would you implement a simple keyboard-controller
> for threads on Windows?

Maybe you can use kbhit() and getch() from msvcrt.dll

kbhit returns whether there are any keystrokes in the buffer
getc returns them.

So, what I do is (or something similar, I don't have the exact code here):

kbhit = Win32API.new('msvcrt','kbhit',...)
getch = ...

def wait_for_keypress
while true
if kbhit.Call
ch = getch.Call while kbhit.Call # to flush the buffer
return
end
sleep 0.1 # this should allow other threads to run
end
end

J.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Installing libxml-ruby on Windows: zlib
Next: installing gems