Tk : non blocking Tk.mainloop

Discussion in 'Ruby' started by Juju SL, Apr 13, 2011.

  1. Juju SL

    Juju SL Guest

    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/.
     
    Juju SL, Apr 13, 2011
    #1
    1. Advertising

  2. Juju SL

    botp Guest

    On Thu, Apr 14, 2011 at 1:20 AM, Juju SL <> wrote:
    > Tk.mainloop is non blocking ; my program exists immediately, I only see
    > the Tk canvas appear and disappear.


    fwiw, it should not exit, mine does not. i think nahi good help you further.
    best regards -botp
     
    botp, Apr 14, 2011
    #2
    1. Advertising

  3. Hi,

    I'm very sorry for my late response.

    From: Juju SL <>
    Subject: Tk : non blocking Tk.mainloop
    Date: Thu, 14 Apr 2011 02:20:37 +0900
    Message-ID: <>
    > 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 ()
    Department of Artificial Intelligence, Kyushu Institute of Technology
     
    Hidetoshi NAGAI, Apr 24, 2011
    #3
  4. Juju SL

    Juju SL Guest

    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/.
     
    Juju SL, Apr 28, 2011
    #4
  5. From: Juju SL <>
    Subject: Re: Tk : non blocking Tk.mainloop
    Date: Fri, 29 Apr 2011 06:03:21 +0900
    Message-ID: <>
    > 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.
    --
    Hidetoshi NAGAI ()
    Department of Artificial Intelligence, Kyushu Institute of Technology
     
    Hidetoshi NAGAI, Apr 29, 2011
    #5
  6. Juju SL

    Juju SL Guest

    Hi Hidetoshi,

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

    So I applied the patch to tk.rb :
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D
    ...
    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 =3D 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
    ...
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D

    Running the small script gives the same problem ; here is the end of the
    debug output showing an exception :
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D
    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
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D

    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=C3=A9phane

    -- =

    Posted via http://www.ruby-forum.com/.=
     
    Juju SL, Apr 29, 2011
    #6
  7. From: Juju SL <>
    Subject: Re: Tk : non blocking Tk.mainloop
    Date: Sat, 30 Apr 2011 04:37:52 +0900
    Message-ID: <>
    > I understand your need and as I asked for help, I have to help you back
    > :)


    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.
    --
    Hidetoshi NAGAI ()
    Department of Artificial Intelligence, Kyushu Institute of Technology
     
    Hidetoshi NAGAI, Apr 29, 2011
    #7
  8. From: Hidetoshi NAGAI <>
    Subject: Re: Tk : non blocking Tk.mainloop
    Date: Sat, 30 Apr 2011 07:27:07 +0900
    Message-ID: <>
    > 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)
    +
    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 ()
    Department of Artificial Intelligence, Kyushu Institute of Technology
     
    Hidetoshi NAGAI, May 2, 2011
    #8
  9. Juju SL

    Juju SL Guest

    So, I patched manually the tk.rb file :
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    # diff tk.rb.ORIG tk.rb

    1238a1239,1241
    > interp.mainloop_abort_on_exception =3D true
    > Thread.current.instance_variable_set("@interp", interp)
    >

    1273a1277,1279
    > # complete initializing
    > ruby {TkCore::INTERP_THREAD[:interp] =3D

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

    1280,1281c1286,1287
    < interp.mainloop_abort_on_exception =3D true
    < Thread.current[:interp] =3D interp
    ---
    > # interp.mainloop_abort_on_exception =3D true
    > # Thread.current[:interp] =3D 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
    >

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    Unfortunately, my small scripts ends with an exception :
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    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
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Line 1288 is : Thread.current[:status].value =3D interp.mainloop(true)

    Best regards
    St=C3=A9phane

    -- =

    Posted via http://www.ruby-forum.com/.=
     
    Juju SL, May 2, 2011
    #9
  10. Thank you for your reply.

    From: Juju SL <>
    Subject: Re: Tk : non blocking Tk.mainloop
    Date: Tue, 3 May 2011 05:46:55 +0900
    Message-ID: <>
    > 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 ()
    Department of Artificial Intelligence, Kyushu Institute of Technology
     
    Hidetoshi NAGAI, May 3, 2011
    #10
  11. 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" <>
    To: "ruby-talk ML" <>; <>
    Sent: Monday, May 02, 2011 10:21 PM
    Subject: Re: Tk : non blocking Tk.mainloop


    > Thank you for your reply.
    >
    > From: Juju SL <>
    > Subject: Re: Tk : non blocking Tk.mainloop
    > Date: Tue, 3 May 2011 05:46:55 +0900
    > Message-ID: <>
    >> 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 ()
    > Department of Artificial Intelligence, Kyushu Institute of Technology
    >
    >
     
    Patrick Lynch, May 3, 2011
    #11
  12. From: "Patrick Lynch" <>
    Subject: Re: Tk : non blocking Tk.mainloop
    Date: Tue, 3 May 2011 22:52:45 +0900
    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.
    --
    Hidetoshi NAGAI ()
    Department of Artificial Intelligence, Kyushu Institute of Technology
     
    Hidetoshi NAGAI, May 4, 2011
    #12
  13. Forward delete with irb on a iMac Snow Leopeard machine...

    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
     
    Patrick Lynch, May 4, 2011
    #13
  14. Juju SL

    Stu Guest

    Re: Forward delete with irb on a iMac Snow Leopeard machine...

    first hit on google:

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

    ~

    On Wed, May 4, 2011 at 11:45 AM, Patrick Lynch <> 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
    >
    >
     
    Stu, May 4, 2011
    #14
  15. Akshay Jangid, May 4, 2011
    #15
  16. Akshay Jangid, May 5, 2011
    #16
  17. Re: Forward delete with irb on a iMac Snow Leopeard machine...

    Good morning Stu,
    control+option+D indeed works as a 'forward delete' for an iMac with Snow
    Leopard and aluminum keyboard...
    Thank you - I hope I can return the favor someday...
    Ciao
    ----- Original Message -----
    From: "Stu" <>
    To: "ruby-talk ML" <>
    Sent: Wednesday, May 04, 2011 1:31 PM
    Subject: Re: Forward delete with irb on a iMac Snow Leopeard machine...


    > first hit on google:
    >
    > http://hints.macworld.com/article.php?story=20050525040921189
    >
    > ~
    >
    > On Wed, May 4, 2011 at 11:45 AM, Patrick Lynch <>
    > 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
    >>
    >>

    >
    >
     
    Patrick Lynch, May 5, 2011
    #17
  18. Juju SL

    Juju SL Guest

    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=C3=A9phane


    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/.=
     
    Juju SL, May 5, 2011
    #18
  19. 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 <>
    Subject: Re: Tk : non blocking Tk.mainloop
    Date: Fri, 6 May 2011 05:11:23 +0900
    Message-ID: <>
    > > 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 ()
    Department of Artificial Intelligence, Kyushu Institute of Technology
     
    Hidetoshi NAGAI, May 6, 2011
    #19
  20. Juju SL

    Juju SL Guest

    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=C3=A9phane

    -- =

    Posted via http://www.ruby-forum.com/.=
     
    Juju SL, May 16, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hendra Gunawan
    Replies:
    1
    Views:
    12,592
    Allan Herriman
    Apr 8, 2004
  2. Andre Kelmanson

    blocking i/o vs. non blocking i/o (performance)

    Andre Kelmanson, Oct 10, 2003, in forum: C Programming
    Replies:
    3
    Views:
    939
    Valentin Tihomirov
    Oct 12, 2003
  3. nukleus
    Replies:
    14
    Views:
    837
    Chris Uppal
    Jan 22, 2007
  4. Christian
    Replies:
    5
    Views:
    738
    Esmond Pitt
    Dec 2, 2007
  5. Serge Savoie
    Replies:
    4
    Views:
    272
    Serge Savoie
    Oct 1, 2008
Loading...

Share This Page