Nice to see a fellow industry member dealing with the same problem 
Hello,
I’m using the tcltklib extension in ruby 1.8. It seems to be working
well for my transition from tcl. There are a couple of stumbling
blocks I’m running into:
- is there a way to not start tk? When I create a new interpreter
(let’s say from a non X-fwded ssh session) it may cause a failure. I’m
only interested in Tcl.
This is a big pain for me as well. I would really like to have this fixed,
as Ruby/Tcl interaction is important to me. But it hasn’t been a big
enough pain to try and hack around in the C code 
(yet)
I’m more than willing to spend some time on this. But I’m new to ruby, and
to the tcl-C portions.
It seems like the thing to do is be able to pass the desire for no tk in via
the new call:
TclTkIp.new(notk => 1),
It looks like tcltklib.c:ip_init() gets called. The current parameters wind
up being plugged into Tcl’s argv0 and args. So, in keeping with the current
implementation perhaps something like:
TclTkIp.new($argv0, $args, 1) would be “better”
Where 1 represents the non-desire to load Tk.
One would need to skip over when 1 is set.:
/* from Tcl_AppInit() */
DUMP1("Tk_Init");
if (Tk_Init(ptr->ip) == TCL_ERROR) {
rb_raise(rb_eRuntimeError, "%s", ptr->ip->result);
}
DUMP1("Tcl_StaticPackage(\"Tk\")");
#if TCL_MAJOR_VERSION >= 8
Tcl_StaticPackage(ptr->ip, “Tk”, Tk_Init, Tk_SafeInit);
#else
Tcl_StaticPackage(ptr->ip, “Tk”, Tk_Init,
(Tcl_PackageInitProc *) NULL);
#endif
This kind of approach has merit… however, in the current setup, simply
doing:
require ‘tk’
dies if the DISPLAY is not set. It seems a reorganization of how the
tcltklib module is presented would be needed as well.
Am I missing a better way to get access to the Tcl interpreter?
yeah. I already ran into that. I’ve been using the ruby_fmt proc that
tcltk creates on init. That’s just a wrapper for calling the ruby tcl
command.
I have not been using this, but perhaps I should. The way I’ve been doing
it usually leads to naming differences and confusion, like:
TclFuncs = <<-EOTCL
proc foo {args} {
ruby {bar(‘$args’)}
}
EOTCL
#TclFuncs is evaled into the tcl interpreter…
def bar(args)
…
end
You likely will have to do some creative things to get the scope that you
want–Tcl can only communicate directly with class or global variables.
This means if you call out to Tcl from Ruby, you will not have access to
instance or local variables. It makes perfect sense, but typically
requires doing some non-rubyish things to get access to what you need in
Tcl.
I don’t think the importance of the above has sunk in yet. Do you mean to
say that in a class, I won’t be able to do something like:
Ip._eval(“puts #{var}”)
No, because #{var} will be interpolated before the call to Tcl’s eval.
What I mean is that the following will not work (note that TclUtils
provides some wrapper functionality that ultimately results in a call to
Tk.tk_call(“eval”, cmd)… I didn’t know about _eval which is probably what
I should be using):
#tcl function defined as follows…
proc some_proc {} {
set somevar [ruby {do_something()}]
}
#and a ruby methods defined as…
class SomeClass
def do_something()
…
return some_str
end
def some_instance_method()
TclUtils.eval(“some_proc”)
end
end
When you call some_instance_method(), and it runs the tcl proc ‘some_proc’,
the Tcl interpreter is calling things at the basest level of Ruby scoping,
so there will be no such method ‘do_something’ at that level.
If this seemed obvious to you that such a thing wouldn’t work, perhaps it
is. But it is an ugliness you have to deal with when spanning the two
worlds.
I end up having a current_obj variable or something which can be gotten at
with a class method at the Tcl level, i.e.:
proc some_proc {} {
set somevar [ruby {SomeClass.current_obj.do_something()}]
}
#and…
class SomeClass
def SomeClass.current_obj
return @@current_obj
end
…
def some_instance_method()
@@current_obj = self
TclUtils.eval(“some_proc”)
end
end
Ugly. Sinfully ugly. Luckily, I try to keep Ruby in control of most
everything, and the Tcl is a configuration file, so I don’t need to do this
that often.
···
On Oct 2, Aamer Akhter wrote:
On 10/1/03 10:06 AM, in article > 20031001140652.GA29212@vor-lord.ftc.agilent.com, “Brett H. Williams” > brett_williams@agilent.com wrote:
On Oct 1, Aamer Akhter wrote:
–
---------------------------------------------- | --------------------------
Brett Williams | (970) 288-0475