Re: tcltklib and not init'ing tk

Hi, 

# I resend the following message, because I had no delivery of it. 
# I'm sorry, if you saw it twice. 

From: [e-mail] (Aamer Akhter)
Subject: Re: tcltklib and not init'ing tk
Date: Sun, 5 Oct 2003 06:56:12 +0900
Message-ID: <[e-mail]>
> I would suggest not using the argv parameter space for indicating the
> non-desire for Tk. One might one to pass command line arguments to
> tclsh ( in the same way as to wish)

Hmm... I don't think so. Because, command line options ( except
display options for wish ) can be given by Ruby. 
For example, when want to evaluate the following script on Ruby/Tcl, 
---<foo.tcl>----------------
puts "argc = $argc"
puts "argv = $argv"
puts "argv0 = $argv0"
----------------------------
the following can simulate 'tclsh foo.tcl 1 2 3'.
----------------------------
require 'tcltklib'
ip = TclTkIp.new('foo.tcl', nil)
ip._eval('set argc 3')
ip._eval('set argv {1 2 3}')
ip._eval('source foo.tcl')
----------------------------

> > BTW, there is a known bug on tcltklib.c. It causes 'Segmentation 
> > Fault' when 'vwait' or 'tkwait' command is called on the other 
> > thread than 'mainloop' thread. Those commands call Tcl_DoOneEvent() 
> > function. And it conflicts with the eventloop control of tcltklib.c. 
> > I've been working on fixing the problem. I think I must implement 
> > the routines to replace 'vwait' and 'tkwait'.
> While I'm not an active user of vwait, tkwait  and espically not
> threads as they're not supported in tcl-expect, I think the TKinter
> python library has worked around these type of issues see:
> Modules/_tkinter.c in the regular python distribution

If you don't use threads, there is no problem (probably). 
The trouble depends on "thread switching". 

To avoid confliction of Tk operations between threads, the invoked
command on the other thread than eventloop thread are serialized 
by adding into the event queue. And then, the invoking thread sleeps 
and waits for evaluation of the command. The event queue handler, 
which called on Tcl_DoOneEvent(), evaluates the command, and wakes 
the sleeping thread. 

Tcl's eventloop is the repeat of calling Tcl_DoOneEvent(). 
Current Ruby/Tk uses its own eventloop for smooth switching of 
threads. But, as I wrote on the last mail, 'vwait' and 'tkwait' 
call Tcl_DoOneEvent() repeatedly. It is equal to situation where 
two eventloops are running on each thread. Therefore, the call stack 
of Tcl is broken by thread switching. 

> I would like to work with yon on improving the transferability of
> lists and arrays between tcl and ruby, if you are interisted.

Thank you for your proposal. Please tell me what is not enough on 
tk.rb (tcltk.rb is not maintained). 
-- 
                                  Hidetoshi NAGAI ([e-mail])