From: Axel on 21 Feb 2010 02:34
> Hopefully that will be enough of a stop gap until somebody comes in and
> patches RubyInstaller to have the Tk binaries...
I think, that's good.
The only thing which might be missing is a gem/binary for Ruby1.8.x +
People might want to have it because of better looking (really?)
I'll send you an email on this issue.
From: Axel on 21 Feb 2010 02:42
> I think that most of troubles on installation of a binary distribution
> depend on:
> (1) install wrong version (not supported by tcltklib.so) of Tcl/Tk.
> (2) "Path" environment variable doesn't include the folder of Tcl/Tk
I agree. I would add:
(3) Get the binaries in order to avoid compilation; becoming solved
now by Roger Pack.
(4) _Find_ the explanation on how to install ( 1. right versions
are ..., 2. TCL of version xyz from here..., 3. Ruby/Tk-binaries/gems
from rp..., 4. If it does not work, check PATH, path must be...)
From: Mark Roseman on 21 Feb 2010 11:46
Axel <a99.googlegroups.a99(a)dfgh.net> wrote:
> _Until_ a very good solution is available, I think, it would be good
> to have a clear description on how to install Ruby/Tk on Windows,
> using for example ActiveTCL, and having binaries for download.
> Something like Roger Pack provides, but even more.
Agreed. I've tried to provide the step-by-steps in my Tk tutorial at
http://www.tkdocs.com (please let me know if there are any
inaccuracies), but I too would like to see this a lot smoother.
The Tclkit-style approach made a huge difference in the Tcl world as far
as ease of deployment, so I'm glad to see it being advanced here as well.
From: Michael Fellinger on 21 Feb 2010 12:50
On Sun, Feb 21, 2010 at 3:21 PM, Hidetoshi NAGAI <nagai(a)ai.kyutech.ac.jp> wrote:
> From: mdiam <maurice.diamantini(a)gmail.com>
> Subject: Re: Tk on Windows and Mac OS X 10.6
> Date: Sat, 20 Feb 2010 19:16:41 +0900
> Message-ID: <f758cf0f-774f-47a2-8069-1d53ea4b08f7(a)f15g2000yqe.googlegroups.com>
> > The FFI ffi-tk ruby project should work with any plateform
> > (e.g. Â jruby but also macruby, etc...).
> > But if Hidetoshi hasn't choose that way (i.e. ffi) for tk,
> > propably there is a good reason (like the threads, or simply
> > it much more work ?)
> Because I'm not familiar with FFI, I don't have good ideas to soleve
> complexity of combination of callbacks, threads, and exceptions.
> For example ...
> The eventloop is running on thread1.
> thread2 calls Tk function1 (send to thread1; serialized on event queue).
> thread1 get thread2's request from the event queue.
> thread1 call callback1 on Ruby.
> callback1 (running on thread1) calls Tk function2.
> function2 call callback2 on Ruby.
> And, an exception is raised in callback2.
> Then, how should we treat the exception?
> Tcl/Tk functions know nothing about Ruby threads.
> Of course, there are some methods to solve it.
> However, those methods may have other problems;
> slow operation or response (with lock process),
> depend on global variables, explosion of entry tables,
> CPU power eater (by busy loop), and so on.
> To solve or avoid all of them on Ruby only may be difficult.
> # I agree that ffi-tk is valuable even if it has some restrictions.
I've solved this by creating a separate thread that handles all calls
using the interp.
By using Queue#pop, the code will simply block the Thread until it can
handle a send,
so it's very little overhead, and has zero CPU usage when idle.
On OSX, sometimes only the master thread is allowed to be a sender, so
I handle that case as well.
CTO, The Rubyists, LLC
From: Hidetoshi NAGAI on 21 Feb 2010 17:12
From: Michael Fellinger <m.fellinger(a)gmail.com>
Subject: Re: Tk on Windows and Mac OS X 10.6
Date: Mon, 22 Feb 2010 02:50:45 +0900
> I've solved this by creating a separate thread that handles all calls
> using the interp.
> By using Queue#pop, the code will simply block the Thread until it can
> handle a send,
> so it's very little overhead, and has zero CPU usage when idle.
After calling Tk.mainloop, is the thread for Tk blocked from other
Although it is important whether threads are switched at proper
timing, thread switching troubles may not occur if ffi-tk supports
ruby1.9 only (I don't know about JRuby's thread switching),
Maybe you should pay attention to exceptions.
Does "reaper" thread down when block.call raises an exception?
When ruby1->tcl-(callback)->ruby2 and ruby2 raises an exception,
can ruby1 get the exception?
I don't read all part of ffi-tk. I'm sorry if I misunderstand.
Hidetoshi NAGAI (nagai(a)ai.kyutech.ac.jp)