2 questions about TkVariable and ruby/tk

[Ferenc Engard]

Hi all!

I have the following code snippet:

-----------------------------------
....
h=Hash.new
(0..4).each {|c|
(0..9).each {|r|
h["#{r},#{c}"]="#{r} ; #{c}";
}
}
v=TkVariable.new(h)
#~ puts "before: #{v.value}"
puts "ok."
t2=TkTable.new() {
rows 10
cols 5
variable v
}
t2.pack()
Tk.mainloop()
-------------------------------------
(TkTable is a wrapper for a tktable tcl widget written by me. It uses
'variable' to store the data of the table cells.)

This works perfectly, just as I expect. BUT, if I comment out the
debugging puts(), then it prints v's content, then 'ok.' just as before,
but after that the program hangs, the X window do not appear, and I
cannot even stop the program with CTRL-C! If I simply just read the
v.value (do not print it), the result is similar. :-O With v.inspect the
problem do not occur. What difference makes reading a TkVariable's
value???

My second question is related to the previous: I have the feeling that
this 'hang' really means a runtime error in the ruby code which is
executed from tcl (which is executed from ruby . So, my question is
how to receive these error messages, and why do the process hang if it
encounters with an error like this?

 

[Hidetoshi NAGAI]

Hi,

From: Ferenc Engard <[email protected]>
Subject: 2 questions about TkVariable and ruby/tk
Date: Sat, 6 Sep 2003 09:11:26 +0900

This works perfectly, just as I expect. BUT, if I comment out the
debugging puts(), then it prints v's content, then 'ok.' just as before,
but after that the program hangs, the X window do not appear, and I
cannot even stop the program with CTRL-C! If I simply just read the
v.value (do not print it), the result is similar. :-O With v.inspect the
problem do not occur. What difference makes reading a TkVariable's
value???

Do you use which version of Ruby/Tk?
I tried it on "ruby 1.8.0 (2003-09-05) [i686-linux]",
but I couldn't get the occurrence of the problem.

# To try your script, I use the following definition.
# -------------------------------------------------
# class TkTable < TkWindow
# def create_self
# tk_call('table', @path)
# end
# end
# -------------------------------------------------

Maybe the problem depends on the fixed bugs between the 1.8.0 release
and the CVS head.

My second question is related to the previous: I have the feeling that
this 'hang' really means a runtime error in the ruby code which is
executed from tcl (which is executed from ruby . So, my question is
how to receive these error messages, and why do the process hang if it
encounters with an error like this?

Sorry. It is a bug on tcltklib. The bug has already fixed on CVS.
Please get the newest version of tcltklib and tk from CVS,
and try your script on the new Ruby/Tk.

 

[Ferenc Engard]

Hello,

I have simplified the problem. Here is the testprogram:

---------------------------
#!/usr/bin/env ruby
require 'tk.rb'

begin
Tk::INTERP._eval('bad_cmd_name xxsx')
rescue
end
puts "before mainloop"
Tk.mainloop
---------------------------

It prints out 'before mainloop', but do not creates its X form, and
cannot be interrupted by ctrl-c. Tested with 1.6.8 and 1.8.0. (Anyway,
TkVariable::result generates a (catched) error when the tcl variable is
an array, that's why the program in my previous posting encountered this
problem.)

If the _eval cmd is replaced to
---------------------------
Tk.tk_call('bad_cmd_name','xxsx')
---------------------------

then on 1.6.8 it prints the following error message, and do not print
the "before mainloop" message:

/usr/lib/ruby/1.6/tk.rb:604:in `tk_call': invalid command name
`bad_cmd_name' (NameError)
from ./test2.rb:7

On 1.8.0 it behaves just as with _eval (i.e. no form).

I have made another test where the following call is in a button's
callback, and had similar results. So, on the first error in tcl the
program hangs out.

This is done on a debian unstable linux, with the ruby and ruby1.8
packages. On my win machine there are no such problems (except that
Tk::tk_call do not forward exceptions to the caller, but displays the
'Error in tcl script' error window) (version 1.6.8).

What can be the problem? If it matters, I use XWin32 as X-server (do not
have X on the linux machine).

Should I try the CVS version, or is it a local problem to me?

Thank you:
Circum

 

[Hidetoshi NAGAI]

Hi,

From: Ferenc Engard <[email protected]>
Subject: Re: 2 questions about TkVariable and ruby/tk
Date: Sun, 7 Sep 2003 06:33:33 +0900

It prints out 'before mainloop', but do not creates its X form, and
cannot be interrupted by ctrl-c. Tested with 1.6.8 and 1.8.0. (Anyway,
TkVariable::result generates a (catched) error when the tcl variable is
an array, that's why the program in my previous posting encountered this
problem.)

Sorry. It is a bug on tcltklib.c. I fixed it on CVS.

Should I try the CVS version, or is it a local problem to me?

Please try the CVS version.

 

[Ferenc Engard]

It prints out 'before mainloop', but do not creates its X form, and

Sorry. It is a bug on tcltklib.c. I fixed it on CVS.

Why does it work in the win32 version 1.6.8? :-O It is a bit weird that
this bug didn't bother anybody, since everyone who uses ruby/tk should
run into it, as catching a tcl error is a quite common thing... I cannot
even close any ruby/tk app normally, i.e. it do not stop if I close the
window, but freeze. And IIRC I didn't have such problems a few
months ago... So is it possible that it is a relatively new bug?

I would prefer not to compile ruby for myself as my program should run
on many machines, where I am not an administrator.

Thanks:
Circum

PS: I hope the guys at debian will quickly package the new version...
)

 

[Hidetoshi NAGAI]

Hi,

From: Ferenc Engard <[email protected]>
Subject: Re: 2 questions about TkVariable and ruby/tk
Date: Mon, 8 Sep 2003 08:57:01 +0900

Why does it work in the win32 version 1.6.8? :-O

There are important changes from 1.6.8 to 1.8.0. Those are
(1) fixed the problem of eating 100% CPU power,
(2) support multiple Tk interpreters.
'seem to ignore KILL signal' problem depends on the 1st one,
and 'return no exceptions' problem depends on the 2nd one.

To get better response for Ruby/Tk with other Ruby threads and fix
some problems (sometimes hung up when controling widgets from threads
except the eventloop thread), I re-wrote the eventloop implementation
on tcltklib.c. But that had the 100% CPU problem.
Although the problem was fixed on 1.8.0, then I forgot to check
signal traps when the eventloop thread is the only thread.

If we want to run a safe-Tk interpreter, we must control at least
two interpreters; those are the master IP and the slave safe-Tk IP.
All interpreters running at same time are handled by only one eventloop.
If the eventloop accepts an exception from one interpreter and stops
working because of the exception, other interpreters stop working too.
That is meaning that one interpreter can stop other interpreters.
Of course, it is undesirable. I changed tcltklib.c on 1.8.0 release to
avoid the problem. But some bugs lay on the changes.

I think (or I want ) those were fixed by the last change of
tcltklib.c on CVS. Whenever you find problems that are not fixed,
please report them on the ML. Whatever problems you found are welcome.

# If you are interested in implementation for selecting the proper Tk
# interpreter on a same method call (e.g. TkButton.new), please see
# multi-tk.rb.