Tk : non blocking Tk.mainloop

Hi all,

I'm new in this forum (but I have been following it for months)

I did some canvas tests on my Debian Squeeze with Ruby 1.8 + Tk, and
everything was OK.

Then I chose to move to Ruby 1.9 ; so I cleaned my old Ruby packages and
installed "ruby1.9.1-full package", which comes with Tk8.4

My problem is I can't get Ruby TK programs run properly, because the
Tk.mainloop is non blocking ; my program exists immediately, I only see
the Tk canvas appear and disappear.

This occurs even on the simpliest program, like :
require 'tk'
rr=TkRoot.new
cc=TkCanvas.new(rr)
cc.pack
Tk.mainloop

Running it under IRB, the window appears correctly.

Any clue about this behaviour and how to make Tk.mainloop work as
expected ? Thanks

···

--
Posted via http://www.ruby-forum.com/.

fwiw, it should not exit, mine does not. i think nahi good help you further.
best regards -botp

···

On Thu, Apr 14, 2011 at 1:20 AM, Juju SL <jujusl@free.fr> wrote:

Tk.mainloop is non blocking ; my program exists immediately, I only see
the Tk canvas appear and disappear.

Hi,

I'm very sorry for my late response.

···

From: Juju SL <jujusl@free.fr>
Subject: Tk : non blocking Tk.mainloop
Date: Thu, 14 Apr 2011 02:20:37 +0900
Message-ID: <58d66ab4de539ec84adb59d9fbde9312@ruby-forum.com>

I did some canvas tests on my Debian Squeeze with Ruby 1.8 + Tk, and
everything was OK.

Then I chose to move to Ruby 1.9 ; so I cleaned my old Ruby packages and
installed "ruby1.9.1-full package", which comes with Tk8.4

My problem is I can't get Ruby TK programs run properly, because the
Tk.mainloop is non blocking ; my program exists immediately, I only see
the Tk canvas appear and disappear.

I don't use Debian. I couldn't re-generate your trouble on my environment.
It may depend on race condition of native threads.

Could you try the followings and report the results?

(1) If you call Tk.mainloop on the main thread only,
    please call the follwing line berore "require 'tk'".
    ----------------------------------------------------------------------
    module TkCore; RUN_EVENTLOOP_ON_MAIN_THREAD = true; end
    ----------------------------------------------------------------------

(2) Please run your simple script, which occurs your trouble, with -d option.
    e.g.
    ----------------------------------------------------------------------
    ruby -d your_script.rb > exec.log 2>&1
    ----------------------------------------------------------------------
    If it has same trouble, please send me the log file.

(3) Please apply the following patch.
    If it has same trouble, please send the log when running with -d option.

--- tk.rb-orig 2011-04-25 06:37:19.000000000 +0900
+++ tk.rb 2011-04-25 06:54:13.000000000 +0900
@@ -1271,6 +1271,7 @@
}
set __initial_state_of_rubytk__ 1
trace add variable __initial_state_of_rubytk__ unset __startup_rbtk_mainloop__
+update
EOS

         begin
@@ -1301,7 +1302,8 @@
       }

       until INTERP_THREAD[:interp]
- Thread.pass
+ #Thread.pass
+ INTERP_THREAD.run
       end
       # INTERP_THREAD.run
       raise INTERP_THREAD[:interp] if INTERP_THREAD[:interp].kind_of? Exception

--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

Hi,

Thank you for this answer Hidetoshi.

So, as I had gone back to Ruby 1.8, I desinstalled its packages and
reinstalled the 1.9 ones.

I tried your first suggestion with my simple script and the script ran
OK.

Then I tried another more complicated script, which did not work last
time ; it now runs OK too with your first hack.

I haven't tried your third suggestion, as I prefer to keep my packages
clean ; I keep it in mind in case the first hack does not solve my
problems.

Thanks a lot for your help ; I will keep you aware if my problem occurs
again.

Best regards

JujuSL

···

--
Posted via http://www.ruby-forum.com/.

Hi Hidetoshi,

I understand your need and as I asked for help, I have to help you back
:slight_smile:

So I applied the patch to tk.rb :

···

==============================
...
set __initial_state_of_rubytk__ 1
trace add variable __initial_state_of_rubytk__ unset
__startup_rbtk_mainloop__
update
EOS

        begin
          begin
            #TclTkLib.mainloop_abort_on_exception = false
...
and
...
      }

      until INTERP_THREAD[:interp]
        #Thread.pass
   INTERP_THREAD.run
      end
      # INTERP_THREAD.run
      raise INTERP_THREAD[:interp] if INTERP_THREAD[:interp].kind_of?
Exception
...

Running the small script gives the same problem ; here is the end of the
debug output showing an exception :

tcltklib: destroy root widget
tcltklib: check `finalize-hook-proc'
tcltklib: check `foreach' & `after'
tcltklib: cancel after callbacks
tcltklib: finish ip_finalize
Exception `TypeError' at /usr/lib/ruby/1.9.1/tk.rb:1283 - exception
class/object expected
tcltklib: eventloop_ensure: current-thread : 8802278
tcltklib: eventloop_ensure: eventloop-thread : 8802278
tcltklib: eventloop-ensure: new eventloop-thread -> 4
tcltklib: finish current eventloop 8802278
tcltklib: ip is deleted
tcltklib: ip is deleted
tcltklib: ip is deleted
tcltklib: delete deleted IP
tcltklib: free Tcl Interp 881a678
tcltklib: complete freeing Tcl Interp

But the weird thing is that sometimes it runs OK ! (once every 6 ou 7
times) ; I just run the same command again and again...

Hope this will help !

Best regards
Stéphane

--
Posted via http://www.ruby-forum.com/.

So, I patched manually the tk.rb file :

···

=====================================
# diff tk.rb.ORIG tk.rb

1238a1239,1241

        interp.mainloop_abort_on_exception = true
        Thread.current.instance_variable_set("@interp", interp)

1273a1277,1279

# complete initializing
ruby {TkCore::INTERP_THREAD[:interp] =

TkCore::INTERP_THREAD.instance_variable_get('@interp')}

1280,1281c1286,1287
< interp.mainloop_abort_on_exception = true
< Thread.current[:interp] = interp
---

# interp.mainloop_abort_on_exception = true
# Thread.current[:interp] = interp

1286a1293

            p e if $DEBUG

1302a1310

      # check a Tcl/Tk interpreter is initialized

1304c1312,1313
< Thread.pass
---

# Thread.pass
        INTERP_THREAD.run

1308a1318,1322

      # check an eventloop is running
      while INTERP_THREAD.alive? && TclTkLib.mainloop_thread?.nil?
        INTERP_THREAD.run
      end

1318a1333,1336

      # (for safety's sake) force the eventloop to run
      INTERP_THREAD.run

=====================================

Unfortunately, my small scripts ends with an exception :

tcltklib: delete slaves
tcltklib: destroy root widget
tcltklib: check `finalize-hook-proc'
tcltklib: check `foreach' & `after'
tcltklib: cancel after callbacks
tcltklib: finish ip_finalize
Exception `TypeError' at /usr/lib/ruby/1.9.1/tk.rb:1288 - exception
class/object expected
tcltklib: eventloop_ensure: current-thread : 9e62658
tcltklib: eventloop_ensure: eventloop-thread : 9e62658
tcltklib: eventloop-ensure: new eventloop-thread -> 4
tcltklib: finish current eventloop 9e62658
tcltklib: ip is deleted
tcltklib: ip is deleted
tcltklib: ip is deleted
tcltklib: delete deleted IP
tcltklib: free Tcl Interp 9e7ae68
tcltklib: complete freeing Tcl Interp

Line 1288 is : Thread.current[:status].value = interp.mainloop(true)

Best regards
Stéphane

--
Posted via http://www.ruby-forum.com/\.

fyi

Attachments:
http://www.ruby-forum.com/attachment/6166/per.jpg

···

--
Posted via http://www.ruby-forum.com/.

compare it

Attachments:
http://www.ruby-forum.com/attachment/6169/Compare_It_.jpg

···

--
Posted via http://www.ruby-forum.com/.

Hi Hidetoshi,

First, sorry for the long delay but I was very busy and could not find
time to test your patch.

But I tried it today (had to partially patch by hand because 1 hunk was
rejected).

And guess ? It worker like a charm, with and without debug option, and
without the debug logs !

Congratulation for this great work !

Best regards
Stéphane

···

--
Posted via http://www.ruby-forum.com/.

Message-ID: <4b011d545d5bb7930a6ec35b1546f500@ruby-forum.com>

I tried your first suggestion with my simple script and the script ran
OK.

Then I tried another more complicated script, which did not work last
time ; it now runs OK too with your first hack.

First of all, it's a good news that your script worked properly.

However, the first counterplan is not a good one.
Because, when you use it, you cannot call Tk.mainloop in a sub-thread
(e.g. "Thread.new{Tk.mainloop}" doesn't work).

I haven't tried your third suggestion, as I prefer to keep my packages
clean ; I keep it in mind in case the first hack does not solve my
problems.

I can understand your care. So, I can't force you to try the third
counterplan. But I need your help to fix the problem, because I can't
generate the problem.
If you try the third one temporally and it is effective, I can commit
the patch for the next release of Ruby.
Again, I never force you. But your trial report has very high value.

···

From: Juju SL <jujusl@free.fr>
Subject: Re: Tk : non blocking Tk.mainloop
Date: Fri, 29 Apr 2011 06:03:21 +0900
--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

Message-ID: <733de9fa2c38d6afb198de71ac3569a7@ruby-forum.com>

I understand your need and as I asked for help, I have to help you back
:slight_smile:

I'm sorry that I bothered you about it, and thank you for your help.

Running the small script gives the same problem ; here is the end of the

    (snip)

But the weird thing is that sometimes it runs OK ! (once every 6 ou 7
times) ; I just run the same command again and again...

Well, there is no wrong code about compatibility with your Tcl/Tk and
other libraries. And probably, it means that the trouble depends on
the race condition between a main thread and a background eventloop
(with initializing Tcl/Tk interpreter) thread.
I can focus to check when such race condition occurs.
Thank you for your report.

···

From: Juju SL <jujusl@free.fr>
Subject: Re: Tk : non blocking Tk.mainloop
Date: Sat, 30 Apr 2011 04:37:52 +0900
--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

Thank you for your reply.

···

From: Juju SL <jujusl@free.fr>
Subject: Re: Tk : non blocking Tk.mainloop
Date: Tue, 3 May 2011 05:46:55 +0900
Message-ID: <beee0c75cd89cf0fa720304393532c71@ruby-forum.com>

So, I patched manually the tk.rb file :

You don't need manual patch. Please use "patch" command.

# Or, packaged version of tk.rb is not a normal one of ruby192p0?
# If so, please tell me the version of your package.

Unfortunately, my small scripts ends with an exception :

Hmmm... Maybe, I misunderstood the reason of the trouble.
The exception is not important.
It is a normal situation when a Tcl/Tk interpreter is deleted at exit.

I want to know when and how Tk.mainloop exits.
Could you send me a *FULL* debug log with tk.rb (patched by previous
(ruby-talk:382536) patch) patched by the following?

--- tk.rb~ 2011-05-02 18:16:29.000000000 +0900
+++ tk.rb 2011-05-03 11:18:17.000000000 +0900
@@ -1852,32 +1852,56 @@
       TclTkLib.mainloop(check_root)

     else ### Ruby 1.9 !!!!!
+p :log001
       unless TkCore::INTERP.default_master?
+p :log002
         # [MultiTkIp] slave interp ?
         return TkCore::INTERP._thread_tkwait('window', '.') if check_root
       end
+p :log003

       # like as 1.8, withdraw a root widget before calling Tk.mainloop
       TkCore::INTERP._eval_without_enc('catch {unset __initial_state_of_rubytk__}')
+p :log004
       INTERP_THREAD.run
+p :log005

       begin
         TclTkLib.set_eventloop_window_mode(true)
+p :log006
         if check_root
+p :log007
           INTERP_MUTEX.synchronize{
+p :log008
             INTERP_ROOT_CHECK.wait(INTERP_MUTEX)
+p :log009
             status = INTERP_THREAD_STATUS.value
+p [:log010, status]
             if status && TkCore::INTERP.default_master?
               INTERP_THREAD_STATUS.value = nil if $SAFE < 4
+p :log011
               raise status if status.kind_of?(Exception)
             end
+p :log012
           }
         else
- INTERP_THREAD.value
+p :log013
+ # INTERP_THREAD.value
+ begin
+ INTERP_THREAD.value
+ rescue Exception => e
+p [:log014, e]
+ raise e
+ end
         end
+ rescue Exception => e
+p [:log015, e]
+ raise e
       ensure
+p :log016
         TclTkLib.set_eventloop_window_mode(false)
       end
+p :log017
     end
   end

--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

Message-ID: <0758a877c35efecba7bae41c93ea2abf@ruby-forum.com>

But I tried it today (had to partially patch by hand because 1 hunk was
rejected).

And guess ? It worker like a charm, with and without debug option, and
without the debug logs !

I'm glad to hear that. :slight_smile:
Thank you for your help and kindness.

I'll commit the changes to trunk.
Probably, a maintainer of ruby192 will decide whether backport it to
1.9.2 or not.

···

From: Juju SL <jujusl@free.fr>
Subject: Re: Tk : non blocking Tk.mainloop
Date: Tue, 17 May 2011 04:15:39 +0900
--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

Message-ID: <20110430.072659.74734013.nagai@ai.kyutech.ac.jp>

I can focus to check when such race condition occurs.

Could you try the followiing patch?

--- ../ruby-1.9.2-p0.orig/ext/tk/lib/tk.rb 2010-06-29 06:44:06.000000000 +0900
+++ ext/tk/lib/tk.rb 2011-05-02 18:16:29.000000000 +0900
@@ -1236,6 +1236,9 @@
           raise e
         end

+ interp.mainloop_abort_on_exception = true
+ Thread.current.instance_variable_set("@interp", interp)

···

From: Hidetoshi NAGAI <nagai@ai.kyutech.ac.jp>
Subject: Re: Tk : non blocking Tk.mainloop
Date: Sat, 30 Apr 2011 07:27:07 +0900
+
         status = [nil]
         def status.value
           self[0]
@@ -1271,19 +1274,23 @@
}
set __initial_state_of_rubytk__ 1
trace add variable __initial_state_of_rubytk__ unset __startup_rbtk_mainloop__
+
+# complete initializing
+ruby {TkCore::INTERP_THREAD[:interp] = TkCore::INTERP_THREAD.instance_variable_get('@interp')}
EOS

         begin
           begin
             #TclTkLib.mainloop_abort_on_exception = false
             #Thread.current[:status].value = TclTkLib.mainloop(true)
- interp.mainloop_abort_on_exception = true
- Thread.current[:interp] = interp
+ #interp.mainloop_abort_on_exception = true
+ #Thread.current[:interp] = interp
             Thread.current[:status].value = interp.mainloop(true)
           rescue SystemExit=>e
             Thread.current[:status].value = e
           rescue Exception=>e
             Thread.current[:status].value = e
+ p e if $DEBUG
             retry if interp.has_mainwindow?
           ensure
             INTERP_MUTEX.synchronize{ INTERP_ROOT_CHECK.broadcast }
@@ -1300,12 +1307,20 @@
         end
       }

+ # check a Tcl/Tk interpreter is initialized
       until INTERP_THREAD[:interp]
- Thread.pass
+ # Thread.pass
+ INTERP_THREAD.run
       end
+
       # INTERP_THREAD.run
       raise INTERP_THREAD[:interp] if INTERP_THREAD[:interp].kind_of? Exception

+ # check an eventloop is running
+ while INTERP_THREAD.alive? && TclTkLib.mainloop_thread?.nil?
+ INTERP_THREAD.run
+ end
+
       INTERP = INTERP_THREAD[:interp]
       INTERP_THREAD_STATUS = INTERP_THREAD[:status]

@@ -1316,6 +1331,9 @@
           INTERP_THREAD.kill
         end
       }
+
+ # (for safety's sake) force the eventloop to run
+ INTERP_THREAD.run
     end

     def INTERP.__getip

--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

Good morning,
You're doing better than me...
I'm working with an iMac Snow Leopard...and Ruby 1.8.7...
I have TK installed and can access it from the Bash command line - but it is not known to my Ruby, eg, require 'Tk' returns and error message in irb...
I probably should have started a separate link...but I thought I stand a good chance of getting some help here...
Thank you

···

----- Original Message ----- From: "Hidetoshi NAGAI" <nagai@ai.kyutech.ac.jp>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>; <jujusl@free.fr>
Sent: Monday, May 02, 2011 10:21 PM
Subject: Re: Tk : non blocking Tk.mainloop

Thank you for your reply.

From: Juju SL <jujusl@free.fr>
Subject: Re: Tk : non blocking Tk.mainloop
Date: Tue, 3 May 2011 05:46:55 +0900
Message-ID: <beee0c75cd89cf0fa720304393532c71@ruby-forum.com>

So, I patched manually the tk.rb file :

You don't need manual patch. Please use "patch" command.

# Or, packaged version of tk.rb is not a normal one of ruby192p0?
# If so, please tell me the version of your package.

Unfortunately, my small scripts ends with an exception :

Hmmm... Maybe, I misunderstood the reason of the trouble.
The exception is not important.
It is a normal situation when a Tcl/Tk interpreter is deleted at exit.

I want to know when and how Tk.mainloop exits.
Could you send me a *FULL* debug log with tk.rb (patched by previous
(ruby-talk:382536) patch) patched by the following?

--- tk.rb~ 2011-05-02 18:16:29.000000000 +0900
+++ tk.rb 2011-05-03 11:18:17.000000000 +0900
@@ -1852,32 +1852,56 @@
      TclTkLib.mainloop(check_root)

    else ### Ruby 1.9 !!!!!
+p :log001
      unless TkCore::INTERP.default_master?
+p :log002
        # [MultiTkIp] slave interp ?
        return TkCore::INTERP._thread_tkwait('window', '.') if check_root
      end
+p :log003

      # like as 1.8, withdraw a root widget before calling Tk.mainloop
      TkCore::INTERP._eval_without_enc('catch {unset __initial_state_of_rubytk__}')
+p :log004
      INTERP_THREAD.run
+p :log005

      begin
        TclTkLib.set_eventloop_window_mode(true)
+p :log006
        if check_root
+p :log007
          INTERP_MUTEX.synchronize{
+p :log008
            INTERP_ROOT_CHECK.wait(INTERP_MUTEX)
+p :log009
            status = INTERP_THREAD_STATUS.value
+p [:log010, status]
            if status && TkCore::INTERP.default_master?
              INTERP_THREAD_STATUS.value = nil if $SAFE < 4
+p :log011
              raise status if status.kind_of?(Exception)
            end
+p :log012
          }
        else
- INTERP_THREAD.value
+p :log013
+ # INTERP_THREAD.value
+ begin
+ INTERP_THREAD.value
+ rescue Exception => e
+p [:log014, e]
+ raise e
+ end
        end
+ rescue Exception => e
+p [:log015, e]
+ raise e
      ensure
+p :log016
        TclTkLib.set_eventloop_window_mode(false)
      end
+p :log017
    end
  end

--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

Hi Hidetoshi

Found some time to come back to my Tk problem.

You don't need manual patch. Please use "patch" command.

That's what I did, but it rejected 2 chunks, so I had no other choice...

# Or, packaged version of tk.rb is not a normal one of ruby192p0?
# If so, please tell me the version of your package.

Debian Squeeze comes with 1.9.1 packages, but Ruby version is 1.9.2p0

I want to know when and how Tk.mainloop exits.
Could you send me a *FULL* debug log with tk.rb (patched by previous
(ruby-talk:382536) patch) patched by the following?

Good news ! This patch applied with the previous one works ;Tk.mainloop
works as expected and waits after "log008" (I attached the log file)

Best regards
Stéphane

PS for the other guys : please create a new thread for your own problem
to keep this one clean. Thanks.

Attachments:
http://www.ruby-forum.com/attachment/6176/logtk.txt.gz

···

--
Posted via http://www.ruby-forum.com/\.

Message-ID: <DBA039E5453C4849A525D5FF801EB84A@UserPC>

I'm working with an iMac Snow Leopard...and Ruby 1.8.7...
I have TK installed and can access it from the Bash command line - but it is
not known to my Ruby, eg, require 'Tk' returns and error message in irb...
I probably should have started a separate link...but I thought I stand a
good chance of getting some help here...

I'm not a Mac user. So, I don't have a proper answer.
However...
I heard that Snow Leopard stopped official support of Ruby/Tk.
It means that you must compile full or tcltklib extension of Ruby,
if you want use Ruby/Tk.
When compile, please pay attention to binary type; whether 32bit or
64bit. Ruby/Tk should work on each of 32bit and 64bit, if Ruby and
Tcl/Tk libraries are made as same binary type.

···

From: "Patrick Lynch" <kmandpjlynch@verizon.net>
Subject: Re: Tk : non blocking Tk.mainloop
Date: Tue, 3 May 2011 22:52:45 +0900
--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

I'm very sorry for bothering you.

# Before this mail, a direct mail might be sent you.
# The mail rejected by ruby-talk ML because of mail size.
# So, I send this to ML for other ML members.

···

From: Juju SL <jujusl@free.fr>
Subject: Re: Tk : non blocking Tk.mainloop
Date: Fri, 6 May 2011 05:11:23 +0900
Message-ID: <a300236309b957f16fc5b649fa48ea9b@ruby-forum.com>

> You don't need manual patch. Please use "patch" command.
That's what I did, but it rejected 2 chunks, so I had no other choice...

> # Or, packaged version of tk.rb is not a normal one of ruby192p0?
> # If so, please tell me the version of your package.
Debian Squeeze comes with 1.9.1 packages, but Ruby version is 1.9.2p0

I see. I made a new diff from libtcltk-ruby1.9.1_1.9.2.0-2.

> I want to know when and how Tk.mainloop exits.
> Could you send me a *FULL* debug log with tk.rb (patched by previous
> (ruby-talk:382536) patch) patched by the following?
Good news ! This patch applied with the previous one works ;Tk.mainloop
works as expected and waits after "log008" (I attached the log file)

It may be not so good news. Because, It shows that the problem may
depend on severe timing of thread switching.
I made a new patch to force to run the eventloop just before waiting a
condition variable.
Could you try it both of with and without $DEBUG (-d) option?
If not work, please send me the full log.
If work, please remove all debug log "log???" lines in mainloop method
and try it. (Probably, I'm too worried about changing timing of thread
switching by checking $DEBUG variable.)

--- tk.rb.deb-libtcltk-ruby1.9.1_1.9.2.0-2 2010-11-01 17:54:54.000000000 +0900
+++ tk.rb 2011-05-07 06:25:42.000000000 +0900
@@ -1236,6 +1236,9 @@
           raise e
         end

+ interp.mainloop_abort_on_exception = true
+ Thread.current.instance_variable_set("@interp", interp)
+
         status = [nil]
         def status.value
           self[0]
@@ -1271,19 +1274,23 @@
}
set __initial_state_of_rubytk__ 1
trace add variable __initial_state_of_rubytk__ unset __startup_rbtk_mainloop__
+
+# complete initializing
+ruby {TkCore::INTERP_THREAD[:interp] = TkCore::INTERP_THREAD.instance_variable_get('@interp')}
EOS

         begin
           begin
             #TclTkLib.mainloop_abort_on_exception = false
             #Thread.current[:status].value = TclTkLib.mainloop(true)
- interp.mainloop_abort_on_exception = true
- Thread.current[:interp] = interp
+ #interp.mainloop_abort_on_exception = true
+ #Thread.current[:interp] = interp
             Thread.current[:status].value = interp.mainloop(true)
           rescue SystemExit=>e
             Thread.current[:status].value = e
           rescue Exception=>e
             Thread.current[:status].value = e
+ p e if $DEBUG
             retry if interp.has_mainwindow?
           ensure
             INTERP_MUTEX.synchronize{ INTERP_ROOT_CHECK.broadcast }
@@ -1300,12 +1307,20 @@
         end
       }

+ # check a Tcl/Tk interpreter is initialized
       until INTERP_THREAD[:interp]
- Thread.pass
+ # Thread.pass
+ INTERP_THREAD.run
       end
+
       # INTERP_THREAD.run
       raise INTERP_THREAD[:interp] if INTERP_THREAD[:interp].kind_of? Exception

+ # check an eventloop is running
+ while INTERP_THREAD.alive? && TclTkLib.mainloop_thread?.nil?
+ INTERP_THREAD.run
+ end
+
       INTERP = INTERP_THREAD[:interp]
       INTERP_THREAD_STATUS = INTERP_THREAD[:status]

@@ -1316,6 +1331,9 @@
           INTERP_THREAD.kill
         end
       }
+
+ # (for safety's sake) force the eventloop to run
+ INTERP_THREAD.run
     end

     def INTERP.__getip
@@ -1834,32 +1852,63 @@
       TclTkLib.mainloop(check_root)

     else ### Ruby 1.9 !!!!!
+p :log001 if $DEBUG
       unless TkCore::INTERP.default_master?
         # [MultiTkIp] slave interp ?
         return TkCore::INTERP._thread_tkwait('window', '.') if check_root
       end
+p :log002 if $DEBUG

       # like as 1.8, withdraw a root widget before calling Tk.mainloop
+p :log003 if $DEBUG
       TkCore::INTERP._eval_without_enc('catch {unset __initial_state_of_rubytk__}')
+p :log004 if $DEBUG
       INTERP_THREAD.run

       begin
+p :log005 if $DEBUG
         TclTkLib.set_eventloop_window_mode(true)
+
+p :log006 if $DEBUG
+ # force run the eventloop
+ TkCore::INTERP._eval_without_enc('update')
+p :log007 if $DEBUG
+ TkCore::INTERP._eval_without_enc('catch {set __initial_state_of_rubytk__}')
+p :log008 if $DEBUG
+ INTERP_THREAD.run
         if check_root
+p :log009 if $DEBUG
           INTERP_MUTEX.synchronize{
+p :log010 if $DEBUG
             INTERP_ROOT_CHECK.wait(INTERP_MUTEX)
+p :log011 if $DEBUG
             status = INTERP_THREAD_STATUS.value
+p [:log012, status] if $DEBUG
             if status && TkCore::INTERP.default_master?
               INTERP_THREAD_STATUS.value = nil if $SAFE < 4
+p :log013 if $DEBUG
               raise status if status.kind_of?(Exception)
             end
+p :log014 if $DEBUG
           }
         else
- INTERP_THREAD.value
+p :log015 if $DEBUG
+ # INTERP_THREAD.value
+ begin
+ INTERP_THREAD.value
+ rescue Exception => e
+p [:log016, e] if $DEBUG
+ raise e
+ end
         end
+ rescue Exception => e
+p [:log017, e] if $DEBUG
+ raise e
       ensure
+p :log018 if $DEBUG
         TclTkLib.set_eventloop_window_mode(false)
       end
+p :log019 if $DEBUG
     end
   end

================================================================
--
Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
Department of Artificial Intelligence, Kyushu Institute of Technology

Good morning,

I'm a newbie to this site and I'm not sure if this is the way to start a new thread...if I'm doing something wrong, please let me know...

I'm also a newbie to the iMac Snow Leopard machine...
I have the 'aluminum' keyboard and it does not have a 'forward delete' button...
It does have the 'backward delete' button...
I've been able to solve the not having a 'forward delete' button by using 'fn' + '[backward] delete' in all other places but not within irb...
In irb, when I press 'fn'+'delete' I get the 'squigly' character '~'...
...for example, if I'm in irb and want to delete the '2' in the string "123", using 'fn'+'delete', I get "1~23"....
No big deal, but it is driving me nuts...I'd appreciate any help...

Good day

first hit on google:

http://hints.macworld.com/article.php?story=20050525040921189

···

~

On Wed, May 4, 2011 at 11:45 AM, Patrick Lynch <kmandpjlynch@verizon.net> wrote:

Good morning,

I'm a newbie to this site and I'm not sure if this is the way to start a new
thread...if I'm doing something wrong, please let me know...

I'm also a newbie to the iMac Snow Leopard machine...
I have the 'aluminum' keyboard and it does not have a 'forward delete'
button...
It does have the 'backward delete' button...
I've been able to solve the not having a 'forward delete' button by using
'fn' + '[backward] delete' in all other places but not within irb...
In irb, when I press 'fn'+'delete' I get the 'squigly' character '~'...
...for example, if I'm in irb and want to delete the '2' in the string
"123", using 'fn'+'delete', I get "1~23"....
No big deal, but it is driving me nuts...I'd appreciate any help...

Good day