I would like to include libtcl and libtk into Allegro on SunOS 4.1.3
(or any other unix allegro), and then be able to load and run a tcl
gui and have it talk back and forth with lisp.
has anyone successfully done this? I wrote a couple of C functions
supposedly to manage the callbacks, but there's more 'wish'
functionality I need in terms of getting a window on the screen...
and I had a hell of a time getting the libraries to load...I got
errors about multiply-defined functions in /lib/libc.a, which I fixed
be extracting the offending .o files from libc.a and including them as
more .o files to load
(load "c-interf.o"
:foreign-files '("naughty-file-1.o" "naughtly-file-2.o")
:system-libraries '("libtcl.a" "libtk.a"))
-- clint
--
Clint Hyde "Give me a LispM or give me death!" -- anonymous
BBN Internet: <a ··················@bbn.com">·····@bbn.com</a>
Columbia, MD (410) 290-5061
Clinton Hyde wrote:
>
> I would like to include libtcl and libtk into Allegro on SunOS 4.1.3
> (or any other unix allegro), and then be able to load and run a tcl
> gui and have it talk back and forth with lisp.
>
> has anyone successfully done this?
That's what we've done in a number of our "newer" programs at STScI:
Allegro server/TclTk clients. We run a separate Tcl process, though,
that communicates over sockets to the Allegro server. Below I've in-
cluded a brief overview of the architecture. It might not be fully
comprehensible as it is meant to accompany the code for a demonstration
program.
======================================================================
;;; Copyright 1990-1996 AURA/STScI. All Rights Reserved.
;;;
;;; STScI developed the Spike planning and scheduling software in
;;; support of the Hubble Space Telescope as a general toolkit for
;;; planning and scheduling under Contract NAS5-26555 with the
;;; National Aeronautics and Space Administration.
;;;
;;; It is our desire that this toolkit be used to promote scientific
;;; research through the effective and efficient use of ground- and
;;; space-based astronomical observatories. By providing the Spike
;;; system to other facilities, we hope to develop a community of
;;; users who develop and use the Spike system. To the degree our
;;; resources allow, STScI will act as a clearinghouse for users,
;;; bug fixes, modifications, etc. To help ensure this vision,
;;; the use of the Spike software is governed by a License Agreement
;;; between STScI and your organization.
;;;
;;; Please refer to our WWW page http://presto.stsci.edu/spike/
;;;
Lisp/Tcl Interface
==================
This file provides an overview of the Lisp to Tcl Interface and
describes the
installation procedures and trace of a demonstration program, DemoApp,
which
has a Lisp and a Tcl component.
Software Requirements
=====================
- Allegro CL 4.2 including foreign function interface
- Itcl and Itk 2.0 and Tcl-DP
- Currently this Package works on SunOS 4.1.3. It has not
been tested on Solaris.
Hardware Requirements
=====================
- Sun Microsystem Computers
Assumptions
===========
None of these assumptions are cast in stone, but are descriptive of our
implementation. Any one or all of these assumptions could be relaxed or
modified to meet different design goals.
1. The Lisp process is the server.
2. Processing may be initiated from a Unix script, or directly from a
Lisp image.
3. As much computation as possible is done on the Lisp side.
4. As much information as possible is shipped to the Tcl side for the
GUI to
manipulate and display. The Tcl GUI maintains a local store of
values
for many variables that are also maintained on the Lisp side. This
reduces
communication overhead, but care must be taken that the state of the
GUI is
kept in line with the state of the Lisp process.
5. The Tcl client uses a few Tcl-DP (distributed programming) extensions
to
establish a connection to the Lisp server process.
6. A GUI object is instantiated on the Lisp side which is an abstract
representation of the Tcl GUI.
Overview
========
In a new GUI developed for SPIKE we have dropped our reliance on CLIM
and
moved to a client/server model where the GUI is a separate process
written
in Tcl/Tk (iTcl). The GUI process is a client to the Allegro Lisp
server,
where non user-interface processing is carried out.
After the Common Lisp session is started the START-SERVER function
creates a
separate daemon process which listens to a socket for attempts to
connect, and
starts a lisp listener for each connection. An actual port number and
host
name are returned, and the client (Tcl) process is started with the host
name
and port as arguments.
The SERVER function is the function that is run in the newly created
lisp
listener. It starts up yet another process, which is the actual
communicator.
It runs in a loop, reading the stream for a Lisp form to evaluate.
After the
form is evaluated, the server process waits until a LOCK semaphore is
set to
NIL, and then sets the LOCK to T and sends to the client the contents of
its
OUT-BUFFER, or the function NO_OP, if the out buffer is empty. The LOCK
is
reset to NIL.
The Tcl process on startup creates a TCP protocol INET socket at the
given
port and connects it to the remote server process on the given host. A
filehander command, READSERVER, is designated which will be evaluated
whenever
the file descriptor represented by the socket Id is readable. The first
form
that the client process sends to the server, CLIENT-INIT, sets LOCK to
NIL and
OUT-BUFFER to NIL. This causes the SERVER function to come out of its
wait
state and respond with a NO_OP response to the client.
The client function READSERVER evaluates Tcl commands generated from the
server, and calls SEND-TO-SERVER, which sends either the contents of its
OUT-BUFFER or a NO-OP, if empty. Thus, the Lisp server is continually
in
a loop sending NO_OP to the client and the client responds by sending
NO-OP
to the server, as long as its out buffer is empty.
The second command, CONFIG-GUI, that the client sends to the server
causes
the server to call the appropriate function to set up the top level
window
for the GUI. From this point on the client program never sends any
calls to
the server process, but merely puts the calls in its out buffer, and
relies
on the handshaking in READSERVER to trigger a call to SEND-TO-SERVER.
Laurence Kramer <······@stsci.edu> writes:
>Clinton Hyde wrote:
>>
>> I would like to include libtcl and libtk into Allegro on SunOS 4.1.3
>> (or any other unix allegro), and then be able to load and run a tcl
>> gui and have it talk back and forth with lisp.
>>
>> has anyone successfully done this?
>That's what we've done in a number of our "newer" programs at STScI:
>Allegro server/TclTk clients. We run a separate Tcl process, though,
>that communicates over sockets to the Allegro server.
In case anyone here might be interested, there exists a scheme interpreter
which has been extended with the Tk library - just think wish with the
scripting langauge being scheme instead of tcl. I suspect that people already
versed in Lisp would find it much more pleasant to script a gui in scheme
than in tcl (I definitely do).
Anyhow, it's called STk and it has a web page at:
http://kaolin.unice.fr/html/STk.html
S.
·····@lemur.bbn.com (Clinton Hyde) writes:
>I would like to include libtcl and libtk into Allegro on SunOS 4.1.3
>(or any other unix allegro), and then be able to load and run a tcl
>gui and have it talk back and forth with lisp.
I wrote some code a while ago to make dpTcl and CMU CL talk to each
other via sockets. CMU sends straight Tcl/Tk commands out, and Tcl/Tk
handles all of the GUI stuff.
This is just CMU CL -> Tcl. I haven't done the opposite direction,
but I would imagine it's just a small matter of programming.
--Pat