How do I imbed tcl in an application
Jay Schmidgall
to imbedding tcl within an application, or just some tips/general how-to?
I've got a Motif app to which I've been thinking about adding some sort of
scripting languauge, and of course Tcl leaps to mind. However, while I'm
familiar with tcl, this will be the first time I've tried to actually use
it in a manner for which it was intended :).
Browsing through the man pages, I get the feeling that I do
A) Tcl_CreateInterp()
B) a miracle occurs
C) Tcl_Eval()
D) Use the results (see B)
E) a miracle occurs.
F) Tcl_DeleteInterp().
As you can tell, I'm kind of fuzzy on steps B, D and E. Any help or
guidelines would be most appreciated. Thanks.
--
: jay j...@vnet.ibm.com My opinions and ideas, not my employer's.
: shmd...@rchland.vnet.ibm.com (c) Copyright 1992. All rights reserved.
Adrian J Ho
>Does anyone have a document which describes some sort of cookbook approach
>to imbedding tcl within an application, or just some tips/general how-to?
A pretty good example is in the Tcl distribution itself: tclTest.c is
a simple Tcl command-shell. If you don't have the distribution handy,
let me know and I'll send it to you.
A quick overview:
>A) Tcl_CreateInterp()
>B) a miracle occurs
Tcl_CreateCommand(), Tcl_CreateCmdBuf(), Tcl_AssembleCmd()
>C) Tcl_Eval()
>D) Use the results (see B)
Check the return value of Tcl_Eval() and interp->result, do your
thing with them...
>E) a miracle occurs.
Loop back to (B)?
>F) Tcl_DeleteInterp().
Check the man pages for all the above functions -- it should be fairly
clear how they work.
--
-----------------------------------------------------------------------------
Adrian Ho, He With The Embarrassingly *Dead* Passion ** Phone: (510) 642-5563
System Manager, CFD Lab, ME Dept, UC Berkeley * adri...@barkley.berkeley.edu
Maintainer, Tcl/Tk Contrib Archive ---- barkley.berkeley.edu [128.32.142.237]
Send all Tcl/Tk Archive-related stuff to tcl-a...@barkley.berkeley.edu
Larry W. Virden
John's two initial papers. They described the tcl/tk environment in
such a way that it seemed that a user would be able to write their own
extended sub-options for tcl commands and then the application would
read these extentions / parameters , etc and allow the user customizations.
Did I get the wrong idea? Is there a way for me to add new commands to
a tcl/tk application automatically, or does each application need to add
code to handle this possibility? If so, where does that fit into the
previously described skeleton that you folks are talking about?
--
Larry W. Virden UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas INET: lvi...@cas.org
Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
America Online: lvi...@aol.com
Jay Schmidgall
|> A pretty good example is in the Tcl distribution itself: tclTest.c is
|> a simple Tcl command-shell.
Thanks to Adrian and the off-line responses. The consensus seems to be look
at how tclTest works, which I am in the process of doing.
Question 2: (long winded, sorry)
How do I provide access to structures more complex than just strings?
For example, I've got a structure
typedef struct {
char *name;
int rank;
int ssn;
} Soldier;
Soldier grunt;
Now, is there any way I can pass ``grunt'' to a tcl proc and have it be
able to access grunt.name or grunt.rank ?
I was thinking that I would do this by adding a new command, say soldier,
which would be like
soldier name x : returns x.name
soldier rank x : returns x.rank
soldier ssn x : returns x.ssn
But I'm still left with the problem of x being a Soldier, rather than a
string. For that matter, how would I initialize x.name?
Hmmm. I guess what I'm wondering is sort of how other people have made
the association between a string and the more complex data structure of
which that string is just the name? a pointer to it, somehow? ??
I hope this makes sense.
(In the meantime, I'll look at tk as well to see how the man did it for
windows, etc.)
Adrian J Ho
>How do I provide access to structures more complex than just strings?
I was going to suggest arrays (vanilla Tcl) or keyed lists (Extended
Tcl), but it sounds like...
>typedef struct {
> char *name;
> int rank;
> int ssn;
>} Soldier;
>Soldier grunt;
...you want to preserve the struct in *this* form so that your
internal code can mess around with it too.
>Now, is there any way I can pass ``grunt'' to a tcl proc and have it be
>able to access grunt.name or grunt.rank ?
As you mentioned, you could add a tcl command whose sole purpose is to
provide a Tcl interface to the appropriate fields, doing any necessary
string conversions along the way. Of course, this tends to blow up in
your face if you have more than one struct type...
A good compromise (if you have Extended Tcl) is to use keyed lists.
Support C functions to access and manipulate keyed lists are included,
so you don't have to parse the keyed list yourself to extract the
appropriate fields. You'll have to remember the field types to do
back conversions to numeric data, of course, but you'd have to do
that anyways...
Kevin B. Kenny
In article <1992Jul28.1...@rchland.ibm.com> you write:
|> Question 2: (long winded, sorry)
|>
|> How do I provide access to structures more complex than just strings?
|>
|> For example, I've got a structure
|>
|> typedef struct {
|> char *name;
|> int rank;
|> int ssn;
|> } Soldier;
|>
|> Soldier grunt;
|>
|> Now, is there any way I can pass ``grunt'' to a tcl proc and have it be
|> able to access grunt.name or grunt.rank ?
My preference is to have a single Tcl function that represents an
object. For instance, in the tclTCP package, there is a command,
tcp server
that creates a TCP server object. One of the side effects to `tcp
server' is that it creates a new Tcl command, with a name like
`tcp_server_4', and returns its name. The data structure describing
the server is allocated from free store and initialized, and carried
along as the command's client data. That way, I can say
set s [tcp server]
and then say things like
# Begin accepting connections
$s start
# Tell the user what port we're listening to
puts stdout "Server is listening at [$s configure -port]"
... and so on. If you want to see some more coding examples, ftp the
tclTCP package from barkley.berkeley.edu.
Extended Tcl uses a competing approach, owing primarily to personal
taste (Karl Lehenbauer doesn't care for the noun-verb syntax that the
use of the client data enforces, while I prefer it). It has an
additional type of object called a `handle' that provides a textual
reference to the data structures. If you ftp Extended Tcl from
barkley.berkeley.edu, you'll find a file called `Handle.man' in the
`man' directory that describes the C rountines that Extended Tcl uses
to map between structure pointers and textual names.
If I had done tclTCP the latter way, the syntax would have looked
like:
set s [tcp create_server]
# Start accepting new connections
server start $s
# Tell the user the listening port
puts stdout "Server listening at port [server configure $s -port]"
... and so on. The code would also have been a trifle more
complicated, because the handles would have to be converted to
pointers explicitly, rather than having Tcl_Eval just look up a client
data word. As I said, which method to choose is largely a matter of
personal taste.
John Ousterhout has experimented with both methods: files in Tcl are
identified by handles, while widgets in Tk are independent commands
having client data. John, do you have anything to add about the
tradeoffs?
73 de ke9tv/2, Kevin There isn't any .signature virus, is there?
David Herron
> typedef struct {
> char *name;
> int rank;
> int ssn;
> } Soldier;
>
> Soldier grunt;
>
> Now, is there any way I can pass ``grunt'' to a tcl proc and have it be
> able to access grunt.name or grunt.rank ?
Traditionally TCL has had you use `handles'. A handle is a character-string
which is passed back to the TCL program, and which the TCL program supplies
when it wants to manipulate that object. In the command-handler for each
interested command, there must be a smidgeon of code which takes the handle and
finds the object it refers to. Once the C code has that object, it can do
whatever it likes with it.
Then, if you want the TCL programmer to be able to manipulate things within
the object, you provide a `soldier name <handle>' command. It looks up the handle
and returns the name. Or it could look for a fourth argument, and use that to
set the value.
This all works. The supposedly most convenient way of coding the `handle'
stuff is in the NeoSoft extensions. I have been able to make them work,
but the explanation isn't the most clear and it isn't clear I'm making the
best use of this facility.
Another possible way is to use the key'd lists of the NeoSoft extensions.
When returning a structure, instead of returning its handle you'd convert
it into a key'd list. Then the TCL programmer would have to hand that key'd
list back when it want's to do something. This seems, however, to cause a
lot more overhead as the key'd list would have to be parsed over and over
again. Also for lots of cases, the structure you're manipulating is the property
of another module, which makes this strategy difficult.
BTW,
: jay j...@vnet.ibm.com My opinions and ideas, not my employer's.
: shmd...@rchland.vnet.ibm.com (c) Copyright 1992. All rights reserved.
This copyright notice is not compatible with Usenet. Usenet's inner soul
and being involves copying and widely propogating everything it gets
its hands on. But, a strict reading of this notice, prevents that sort
of thing. Are you going to sue every Usenet site because of this? What is
the point of such a broad claim?
No need to respond in public..
David
Tom Poindexter
>Question 2: (long winded, sorry)
>
>How do I provide access to structures more complex than just strings?
>
>For example, I've got a structure
>
>typedef struct {
> char *name;
> int rank;
> int ssn;
>} Soldier;
>
>Soldier grunt;
>
>Now, is there any way I can pass ``grunt'' to a tcl proc and have it be
>able to access grunt.name or grunt.rank ?
I would suggest looking into the Handles(TCL) code (part of Extended TCL),
or possibly using Keyed Lists (also in Extended TCL).
If all your structure elements can be represented as strings, I'd say go for
Keyed Lists. If your structure has more difficult elements, say pointers,
then go for Handles.
I've recently written a TCL to Sybase package (which I soon hope to release)
that uses the Handles approach, but without using the Handles code. I
wrote my own struct access functions, similar to how files are treated in
the base TCL code. I have a routine to connect to a database; if successful,
my code looks for an unused slot in a fix array of structs, and returns a
"handle" string. The handle is then passed to every other database access
command as the first argument. Each command decodes the handle into an
index into the array.
Regards,
Tom Poindexter
--
Tom Poindexter tpoi...@nyx.cs.du.edu (What? You were expecting more?)
John Ousterhout
First, in response to Kevin Kenny's question about the noun-versus-verb
approach to Tcl commands:
John Ousterhout has experimented with both methods: files in Tcl are
identified by handles, while widgets in Tk are independent commands
having client data. John, do you have anything to add about the
tradeoffs?
I don't have much to add to this. To tell the truth, I never thought
very explicitly about this choice until seeing it in Kevin's message.
I used the handle approach for files because that seemed a natural
imitation of the corresponding UNIX C procedures, and I used the
"object-name-as-command" approach for Tk widgets because that provided
for a uniform approach across all widget types and allowed inidividual
widget types to define different sets of sub-commands without polluting
the Tcl command space. In retrospect, I think I like the "object-name-as
command" approach better, but I think it works best for moderate numbers
of objects (10's or 100's). If there are a million objects, then I think
the handle approach would have significantly lower overhead.
Second, Larry Virden asked about the extension at the level of sub-commands:
Something that I have been wondering about along these lines is based on
John's two initial papers. They described the tcl/tk environment in
such a way that it seemed that a user would be able to write their own
extended sub-options for tcl commands and then the application would
read these extentions / parameters , etc and allow the user customizations.
Did I get the wrong idea? Is there a way for me to add new commands to
a tcl/tk application automatically, or does each application need to add
code to handle this possibility? If so, where does that fit into the
previously described skeleton that you folks are talking about?
You can add commands, but you can't add subcommands to existing commands.
For example, if you wanted to add a "remove" option to the string command,
so that you could say "string remove <string> <letter>" to remove all
instances of <letter> from <string>, you'd have to modify the C code that
implements "string".
Gerald W. Lester
>...
>Second, Larry Virden asked about the extension at the level of sub-commands:
>
> Something that I have been wondering about along these lines is based on
> John's two initial papers. They described the tcl/tk environment in
> such a way that it seemed that a user would be able to write their own
> extended sub-options for tcl commands and then the application would
> read these extentions / parameters , etc and allow the user customizations.
>
> Did I get the wrong idea? Is there a way for me to add new commands to
> a tcl/tk application automatically, or does each application need to add
> code to handle this possibility? If so, where does that fit into the
> previously described skeleton that you folks are talking about?
>
>You can add commands, but you can't add subcommands to existing commands.
>For example, if you wanted to add a "remove" option to the string command,
>so that you could say "string remove <string> <letter>" to remove all
>instances of <letter> from <string>, you'd have to modify the C code that
>implements "string".
John,
You could also rename string to something else (eg string_org) than add
a proc called string that sees if the "command" is an extended command (like
"remove" in your example above), if so it would process it, otherwise it would
do an uplevel on "string_orig $args". I know it is "cheating", but it works.
gwl
Adrian J Ho
>You could also rename string to something else (eg string_org) than add
>a proc called string that sees if the "command" is an extended command (like
>"remove" in your example above), if so it would process it, otherwise it would
>do an uplevel on "string_orig $args". I know it is "cheating", but it works.
True, but in a very dangerous fashion. Suppose you and I published
new suboptions to the "canvas" widget that do, say, pixmap and 3D
polygon drawing respectively. Unless the user (manually) rolls the
two sets of suboptions together into a single suboption package, the
original widget code would become inaccessible from the command level.
Of course, you could do a recursive renaming, but then the overhead of
crawling through 20 different "canvas{_orig}*" suboption wrappers
(mostly at the Tcl level) just to use one of the *original* "canvas"
suboptions could become pretty high. Suboption namespace collisions
are also next to impossible to handle cleanly in this fashion.
IMHO, a neater way is to modify the Tcl library to allow for the
specification and storage of subcommand descriptors. Properly done, a
Tcl programmer would be able to create a theoretically infinite tree
of subcommands without changing the programming interface a single
bit, like this:
Tcl_CreateCommand(interp, "string remove", Tcl_StringRemoveCmd,
clientData, deleteProc);
Support can also be designed in to handle namespace collisions.
Here's how I'd implement it:
-----
(0) Change the definition of struct Command (in tclInt.h) to:
typedef struct Command {
Tcl_CmdProc *proc; /* Procedure to process command. */
ClientData clientData; /* Arbitrary value to pass to proc. */
Tcl_CmdDeleteProc *deleteProc;
/* Procedure to invoke when deleting
* command. */
int is_subproc; /* Flag to denote subprocs underneath */
Tcl_HashTable subprocs; /* Table of Command structs pointing
* to suboptions */
} Command;
(1) Modify Tcl_CreateCommand() to:
(a) logically divide the cmdName argument (eg. "string remove")
into space-delimited command words
(b) create an entry in the main commandTable for the first word if
it doesn't exist, and an empty Command struct
(c) while there are command words left, set is_subproc to TRUE and
insert a pointer to a new Command struct in the subprocs hash
table with the next command word as key. (if the key already
exists, and is_subproc == FALSE, signal a namespace collision,
else use that struct as the next link in the chain)
(d) [no more command words] set is_subproc to FALSE and fill in
the other fields as per normal
(2) Modify Tcl_Eval() to:
(a) decompose the cmd argument into words and walk down the
Command tree as far as possible
(b) when a leaf Command is reached (ie. is_subproc == FALSE),
execute the proc as per normal
-----
I've left out quite a few details, but there should be enough in there
to enable anyone to patch the sources themselves.
Peter da Silva
>Tcl_CreateCommand(interp, "string remove", Tcl_StringRemoveCmd,
> clientData, deleteProc);
Why restrict it to "Tcl_CreateCommand"?
proc {string remove} {string substring} {
...
}
--
`-_-'
Have you hugged your wolf today? 'U`
Peter da Silva, Taronga Park BBS, Houston, TX +1 713 568 0480/1032
Gerald W. Lester
>
>IMHO, a neater way is to modify the Tcl library to allow for the
>specification and storage of subcommand descriptors. Properly done, a
>Tcl programmer would be able to create a theoretically infinite tree
>of subcommands without changing the programming interface a single
>bit, like this:
>
Adrian,
I agree, your proposed change would be nice, but the poster wanted to
be able to extend a command from *Tcl* your suggestion only directly allows it
to be done from *C*.
Another change that would be noce is to extend the proc command to take
an optional fourth arguement that would be a tcl command to invoke when the
procedure is deleted.
Adrian J Ho
>In article <ADRIANHO.92...@barkley.berkeley.edu> adri...@barkley.berkeley.edu (Adrian J Ho) writes:
>>Tcl_CreateCommand(interp, "string remove", Tcl_StringRemoveCmd,
>> clientData, deleteProc);
>Why restrict it to "Tcl_CreateCommand"?
>proc {string remove} {string substring} {
> ...
>}
Well, if I read the Tcl sources correctly, Tcl_ProcCmd() (the routine
that processes the "proc" command) calls Tcl_CreateCommand with
argv[1] as the command name. So, I think that takes care of the Tcl
case too.
Adrian J Ho
> I agree, your proposed change would be nice, but the poster wanted
>to be able to extend a command from *Tcl* your suggestion only
>directly allows it to be done from *C*.
If I read the code correctly, my changes automagically take care of
the Tcl case too, since Tcl_ProcCmd() calls Tcl_CreateCommand() with
argv[1] as the command name anyways.
> Another change that would be noce is to extend the proc command to take
>an optional fourth arguement that would be a tcl command to invoke when the
>procedure is deleted.
Adding that just requires a few changes to Tcl_ProcCmd() to accomplish
that, but I can't think of any application for this enhancement. Can
you suggest any concrete examples? (The reason I ask is coz I figured
John would've added it a long time ago if it had any utility.)
Adrian J Ho
And of course I forgot to describe the changes for Tcl_DeleteCommand()
and every other procedure that looks up the command hash table. At
last glance, the list of procedures to be modified looks like this:
tclBasic.c:
Tcl_CreateCommand()
Tcl_DeleteCommand()
Tcl_DeleteInterp()
Tcl_Eval()
tclCmdIL.c:
Tcl_InfoCmd()
tclCmdMZ.c:
Tcl_RenameCmd()
tclProc.c:
TclFindProc()
All these procedures need to be modified to do some tree-walking
instead of grabbing/modifying the top-level entry from the command
hash table. Of course, it would probably be easier to construct
special access methods for commandTables and modify all the above
procedures to use them.
Larry W. Virden
:In article <1992Jul30.1...@cpu.com> gwle...@cpu.com (Gerald W. Lester) writes:
:
:> Another change that would be noce is to extend the proc command to take
:>an optional fourth arguement that would be a tcl command to invoke when the
:>procedure is deleted.
:
:Adding that just requires a few changes to Tcl_ProcCmd() to accomplish
:that, but I can't think of any application for this enhancement. Can
:you suggest any concrete examples? (The reason I ask is coz I figured
:John would've added it a long time ago if it had any utility.)
:--
Would that be useful in the case where the user tells the window manager to
kill the Tk window?
Gerald W. Lester
>>an optional fourth arguement that would be a tcl command to invoke when the
>>procedure is deleted.
>
>Adding that just requires a few changes to Tcl_ProcCmd() to accomplish
>that, but I can't think of any application for this enhancement. Can
>you suggest any concrete examples? (The reason I ask is coz I figured
>John would've added it a long time ago if it had any utility.)
Adrian,
Sure, I'm writting a server. I have a procedure in my program, that
*must* not be changed (like something that checks security). I would like to
put a delete command on that causes a failure if, on of the files that get
sourced in to handle a service request, an attempt is made to redefine the
procedure in question.
If one is using Extended Tcl with packages (*.tlib) the problem becomes
even more likely unless your packages are very small.
Karl Lehenbauer
>Extended Tcl uses a competing approach, owing primarily to personal
>taste (Karl Lehenbauer doesn't care for the noun-verb syntax that the
>use of the client data enforces, while I prefer it). It has an
>additional type of object called a `handle' that provides a textual
>reference to the data structures. If you ftp Extended Tcl from
>barkley.berkeley.edu, you'll find a file called `Handle.man' in the
>`man' directory that describes the C rountines that Extended Tcl uses
>to map between structure pointers and textual names.
When I invented the handle mechanism for the original implementations of
files and scan contexts in Extended Tcl 4.0, I didn't know very much about
Tk, so it didn't really occur to me to create them as commands.
My two objections to objects-as-commands are pretty simple. One
is really mild, and neither one is a show-stopper or anything. The first
is simply that it clutters up the command namespace. (Granted, handles
likewise clutter the variable namespace, but that seems less serious to me.)
The other is that, with object-as-command you end having to have functions
which access the object like a handle, anyway. For example, "configure" in
Tk takes a widget *command* as an argument and acts upon it, so now you
say things like ".foo activate" but also things like "configure .foo ...".
What is so much better about ".foo activate" than "activate .foo" to justify
the inconsistency?
Again, to me it's no big deal. I program in Tk (with Extended Tcl built in)
full time, and it's great.
--
-- Email in...@NeoSoft.com for info on getting interactive Internet access.
"What luck for rulers that men do not think." -- Adolph Hitler (1889-1945)
Michael Chen
>
>My two objections to objects-as-commands are pretty simple. One
>is really mild, and neither one is a show-stopper or anything. The first
>is simply that it clutters up the command namespace. (Granted, handles
>likewise clutter the variable namespace, but that seems less serious to me.)
>
>The other is that, with object-as-command you end having to have functions
>which access the object like a handle, anyway. For example, "configure" in
>Tk takes a widget *command* as an argument and acts upon it, so now you
>say things like ".foo activate" but also things like "configure .foo ...".
>What is so much better about ".foo activate" than "activate .foo" to justify
>the inconsistency?
>
widget alert (creates the widget type)
alert install init {alert_init $WHO} (set whatever initialization)
alert install -btntxt {eval [concat $WHO.b config -text $ARGS]}
to define a widget type, and then use it like so...
alert .a1 -btntxt "Dismiss me" -msgtxt "Hi there, partner!" -title "Bleah!"
It's basically a way to let you define your own types of widgets that react
to the same syntax as standard Tk widgets. That gets rid of the "configure .a"
vs. ".a configure" problem... you can just use .a whatever.
If you're interested, I can post it or mail you a copy. I've found it to be
pretty handy so far.
--
_____________________________________________________________________________
| Michael Chen | From the depths of our most lucid horrors |
| | spring our fond hopes and pure desires... |
| mc...@groucho.cs.psu.edu | except what comes from HELL! :-) 7/23/92 |
Jay Schmidgall
educational, in particular the post by Kevin Kenny I thought quite good.
However, a common thread which seemed to run through most responses was that
one provides the user with a command which _they_ use to signal the app that
it should initialize some data structure, etc., possibly creating a new
command or a handle, which then lets the user set or get info from that
structure.
My situation is more along the lines where the app already has created the
data structure and user can never do so; however, the user may be interested
in the contents of that structure and wants to access various pieces therein.
So the user doesn't have to create anything -- the data is already there --
she just wants to look at what it is, maybe do some operations on it, that
kind of thing.
Now what I've been considering is patterning my whole command after the
string command, i.e., treating my data structure as just another low-level
object and having a command w/subcommands that access the various internals.
So, does this sound like a reasonable thing or am I probably setting myself
up for some obvious pitfalls down the road? Maybe this is too high-level a
view and I should try to come up with a primitive that the user can use to
create the structure and initialize it, etc?
Thoughts, anyone?