From: Erik Eilerts
Subject: Lisp and C++ X-Windows
Date:
Message-ID: <1506@ai.cs.utexas.edu>
I've been programming an X-window interface to a large knowledge base
using CLX for the past couple of months, but CLX has proven to be much too
cumbersome to work with. So, after looking at other languages, I decided
that it would be much better to keep the knowledge base in Lisp and move
the interface to X-windows using C++. Now that I have reached that decision,
I'm faced with one big question. HOW?
My program has two parts that are independent of each other: the
knowledge base and the interface. The interface basically gathers input
from the user and passes it on to the knowledge base, where it gets
processed. Then, the knowledge base can send back update messages if
needed. So, what I need is some kind of system where I can quickly pass
information back and forth between a Lisp and C program. Also,
I need it to work on SunOs and Ultrix.
I saw another message on this group from Jonathan Unger of the
University of Washington who seemed to have the same problem. So, I assume
that there must be someone out there that has already solved this. My
initial thought was to try to communicate through the X-Server, but it
doesn't look like the server would support it. So, my thought is
to have lisp call some C code that creates sockets and connects them to
the C interface program. I also thought about loading all the C code into the
lisp image, but this seems pretty dangerous and prone to many problems,
especially making debugging almost impossible.
I appreciate any help and ideas.
Thanks,
Erik Eilerts
University of Texas at Austin
·······@cs.utexas.edu
Regarding Lisp and C++ X-Windows; ·······@cs.utexas.edu (Erik Eilerts) adds:
> I've been programming an X-window interface to a large knowledge base
> using CLX for the past couple of months, but CLX has proven to be much too
> cumbersome to work with.
This sounds a bit unfair. CLX is the Common Lisp equivalent of Xlib,
which is at least equally cumbersome. Just as there are higher level
C and C++ X11 toolkits available, there are much higher level Common
Lisp toolkits available. Unfortunately, the Common Lisp ones are
younger.
Of hand, your Common Lisp options may (depending on the Common Lisp
you're using) include:
1. CLM, a Common Lisp to Motif interface that runs an OSF/Motif
server written in C and communicates with it via a socket
collection from Lisp. The performance is supposed to be very
good. All graphics have to be done with CLX, but then Motif
graphics in C have to be done with Xlib so you're still better
off. The biggest disadvantage of this approach is that you can't
get much leverage from using Common Lisp and CLOS to extend the
Motif toolkit. If it's not already in Motif you're pretty much
stuck.
2. Garnet, a mostly look-and-feel independent toolkit written in
Common Lisp with a non-CLOS object language. Designed to
support graphical interfaces. Not designed to support text IO
and text editing. I'm not very impressed with the performance,
but didn't try to tune it.
3. CLIM, a product available for several commercial Common Lisps.
Essentially a portable evolution of Symbolic's Dynamic Windows.
The demo performance on a Sparc running Lucid Common Lisp
looked pretty good. Very powerful if it's available for your
Lisp and you can afford it.
4. Express Windows, a free, mostly undocumented, CLOS-based
package that does many of the same things as CLIM.
5. CLUE and CLIO. The Common Lisp toolkit intrinsics and first
(Open Look like) widget set. CLOS based. Badly needs
performance work.
--
dan
In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: ·······@encore.com
In article <·····················@xenna.encore.com>, ·······@encore.com (Dan L. Pierson) writes:
> Regarding Lisp and C++ X-Windows; ·······@cs.utexas.edu (Erik Eilerts) adds:
> > I've been programming an X-window interface to a large knowledge base
> > using CLX for the past couple of months, but CLX has proven to be much too
> > cumbersome to work with.
>
> This sounds a bit unfair. CLX is the Common Lisp equivalent of Xlib,
> which is at least equally cumbersome.
Unfair? Xlib is much easier to use than CLX. I don't have to debug Xlib. When I
used CLX I continually was debugging it. Also, the CLX documentation doesn't
reflect the current version; many functions are non-existant or have been renamed!
Dan Pierson also recommended several other higher level X-based tools. Without
going into details I don't feel that any of them offer a viable alternative to
those in C for people that want to get real work done. This assertion is based
on 2 years of trying to do X in Lisp. The only thing that comes close is LispView
from Sun. The only language I've used since 1979 has been Lisp. I've finally learned C so that I can do X programming. Reliable, efficient, well-documented,
and useable X libraries and toolkits just don't exist at the moment in Lisp.
--
Kirk Kandt
Artificial Intelligence Group
Advanced Information Systems Section
Information Systems Division
Jet Propulsion Laboratory
California Institute of Technology
From: Christopher Connolly
Subject: CLX works. (was Re: Lisp and C++ X-Windows)
Date:
Message-ID: <33613@dime.cs.umass.edu>
In article <······················@jpl-devvax.jpl.nasa.gov> ·····@AI-Cyclops.JPL.NASA.GOV writes:
. . . . .
>Unfair? Xlib is much easier to use than CLX. I don't have to debug Xlib. When I
>used CLX I continually was debugging it. Also, the CLX documentation doesn't
>reflect the current version; many functions are non-existant or have been renamed!
I can't explain that phenomenon unless you were working with an old copy of
CLX. If you examine the current CLX library and compare it to the Xlib
library, you will indeed find that just about every CLX function has an Xlib
counterpart, and is named similarly (up to hyphens vs. underscores). They
are essentially the same library, just tailored for different languages.
. . . . .
>Dan Pierson also recommended several other higher level X-based tools. Without
>going into details I don't feel that any of them offer a viable alternative to
>those in C for people that want to get real work done. This assertion is based
>on 2 years of trying to do X in Lisp.
At the beginning of 1990, the group I worked in at GE made a decision to go
to X windows and a more "portable" environment. Our software was all written
in Lisp, but tailored to Symbolics machines and the Symbolics window system.
It took approximately 4 months for me to gear up and implement a CLX-based
interface which was approximately equivalent to the user interface we had
implemented on the Symbolics. I had no prior knowledge of the X system or of
Xlib, and worked almost entirely from the CLX documentation and system as
obtained from csc.ti.com. With the exception of one speedup hack for the
network I/O (which has since been fixed by the CLX contributors), I made no
change whatsoever to CLX.
Hence, my opinion differs radically from yours. CLX works, and is a
reasonably faithful reflection of the functions found in Xlib. Perhaps your
copy of CLX was old, or the documentation and source code came from different
sources at different times.
>Kirk Kandt
In article <·····················@xenna.encore.com> ·······@encore.com (Dan L. Pierson) writes:
> 1. CLM, a Common Lisp to Motif interface that runs an OSF/Motif
This package also comes with GINA with is a toolkit that gives you an
interface somewhat like the Macintosh finder. It also comes with an
interface builder called IB.
> 2. Garnet, a mostly look-and-feel independent toolkit written in
> Common Lisp with a non-CLOS object language. Designed to
Garnet uses an object system called KR. It is based on frames (from AI
parlance). I can send a list of the major differences between KR and
CLOS to those interested. They recently dropped the Macintosh port of
Garnet because it was too hard.
> 3. CLIM, a product available for several commercial Common Lisps.
It looks like all the major Lisp vendors will supporting this one.
I believe there are plans to support both Motif and Open Look look and
feel.
> 4. Express Windows, a free, mostly undocumented, CLOS-based
...
> 5. CLUE and CLIO. The Common Lisp toolkit intrinsics and first
6. Picasso. Available from postgres.berkeley.edu. Has constraint
system and interface builder. Only runs on Franz. Homegrown look and
feel. Uses CLOS.
7. LispView. Comes with Lucid (Sun) CL. Open Look interface.
Interface builder.
8. Common Windows. From Franz. No interface builder. Motif look
and feel.
--
Scott Simpson TRW ·····@coyote.trw.com
In article <····@ai.cs.utexas.edu> ·······@cs.utexas.edu (Erik Eilerts) writes:
> I've been programming an X-window interface to a large knowledge base
> using CLX for the past couple of months, but CLX has proven to be much too
> cumbersome to work with.
Indeed! As other people have mentioned, it is no more cumbersome than
programming in Xlib. My biggest problem with CLX (and any higher-level
toolkits atop CLX) is not CLX itself, but Common Lisp. I personally don't
think that such low-level code should be implemented in Lisp. It generates
too much garbage that eventually needs collection, it runs too slow, and
generates a monstrous, thrashing Lisp image. Meanwhile, lots of interesting
Unix UI toolkits are available, debugged, documented, and are undergoing
continual refinement/improvement due to wide usage. Best of all, they've
all been implemented with relative efficiency via "cons free" local memory
management in our most favorite of portable assembly languages -- C.
> So, after looking at other languages, I decided
> that it would be much better to keep the knowledge base in Lisp and move
> the interface to X-windows using C++. Now that I have reached that decision,
> I'm faced with one big question. HOW?
>
> My program has two parts that are independent of each other: the
> knowledge base and the interface. The interface basically gathers input
> from the user and passes it on to the knowledge base, where it gets
> processed. Then, the knowledge base can send back update messages if
> needed. So, what I need is some kind of system where I can quickly pass
> information back and forth between a Lisp and C program. Also,
> I need it to work on SunOs and Ultrix.
>
> I saw another message on this group from Jonathan Unger of the
> University of Washington who seemed to have the same problem. So, I assume
> that there must be someone out there that has already solved this. My
> initial thought was to try to communicate through the X-Server, but it
> doesn't look like the server would support it. So, my thought is
> to have lisp call some C code that creates sockets and connects them to
> the C interface program.
It sounds like you've just described CLM.
> I also thought about loading all the C code into the
> lisp image, but this seems pretty dangerous and prone to many problems,
> especially making debugging almost impossible.
Loading widgets into the CL process is frought with peril, but it can be
done -- see Hans Muller's paper "LispView: Using Common Lisp and CLOS to
Hide a C Toolkit" in "Lisp Pointers", ACM SIGPLAN, Vol IV, no 1.
In implementations where the CL and the C code for a X toolkit reside in
the same image, there is the problem of control-flow and lack of
interactivity: I've seen some Lisp/X interfaces (i won't name names) which
expect you to interrupt the X event loop in order to make any programmatic
changes, and then rerun the X event loop in order to see the graphical
side-effects of the programmatic changes in X. I find such interfaces a
big pain, since they make rapid prototyping of GUI based applications
difficult. After all, one of the points of doing X under Lisp is to allow
interactive changes to the UI through the Lisp interpreter.
However, CLs supporting multiple threads can handle the problem -- place
the X event loop in it's own thread, and have the Lisp interpreter's
read-eval-print be a different thread. This is the approach that seems to
be used in LispView, other X interfaces to Lisp aren't so lucky.
--------------------
Another alternative to CLM is WINTERP, the OSF/Motif Widget INTERPreter,
written by yours truly. WINTERP can be used as (1) a Motif widget server
for other applications, (2) an interactive application prototyping
environent, (3) a platform for delivering extensible applications that can
talk to other applications via remote procedure calls (through the server
socket).
Unlike some of the Lisp/X solutions out there, WINTERP works around the
non-interactivity problem noted above by treating input to the Lisp
evaluator as an event, and handling it on the same event-stream as X
events. Input to WINTERP's lisp evaluator is through a server socket
(either inet or unix domain) thereby allowing other applications and
processes to talk to WINTERP.
Most people use WINTERP to build entire applications entirely within
Winterp-Lisp, but you can also use WINTERP as a UI server for an
application running in a CL process. Unlike CLM, WINTERP allows you to run
interpreted Lisp programs inside the "widget server": this may be needed
for "impedance matching" between the highly interactive Motif-server and
the slow-as-molasses CL process. For example, you needn't bother CL with
low-level UI interactions that can be handled entirely inside WINTERP.
Of course, WINTERP's Lisp isn't based on CL -- I got tired about having to
worry about licensing, codeword/id-modules, slowness, non-portability and
memory-pigging (e.g. causing "normal" Unix workstations with only 16Mb of
memory to thrash) when prototyping/delivering applications in CL. Instead,
I went for an approach more like gnuemacs' (or AutoCAD) where a
small/fast/free C-implemented Lisp interpreter serves as a glue-language to
tie together high-level, efficient, C-implemented functionality (such as
the OSF/Motif toolkit). The Lisp interpreter is based on David Betz' XLISP
2.1, and I make extensive use of XLISP's Smalltalk-like object system in my
widget interface -- for example, instantiable Motif widgets may be
subclassed in Winterp-Lisp.
WINTERP 1.13 (release date unknown) will also allow for you to run your CL
process as a subprocess of WINTERP, allowing the two processes to execute
without blocking while passing messages back and forth through pty's. This
is done through an interface to Don Libes' "expect" library, resulting in a
WINTERP enabling concurrent interaction with multiple unix subprocesses all
controlled by a non-blocking Motif-based UI. The effect is similar to
emacs' process-filter and process-sentinel capabilities, and will allow
WINTERP to become a general GUI-wrapper for terminal-based programs. The
same facilities can also be used to communicate with other serverized
applications (via telnet or rlogin). I have a good part of this working
already, but more testing, coding, and documentation needs to be done
before release.
For more information on WINTERP, see "The WINTERP Widget INTERPreter -- A
Lisp Prototyping and Extension Environment for OSF/Motif-based Applications
and User-Interfaces", "Lisp Pointers", ACM SIGPLAN, Vol IV, no 1. (This is
the same issue of "Lisp pointers" that describes LispView and CLIM).
Here's a blurb on WINTERP, and information on the current release (v. 1.12)
and how to obtain WINTERP for free.
==============================================================================
WINTERP: An object-oriented rapid prototyping, development and delivery
environment for building user-customizable applications with the OSF/Motif
UI Toolkit.
------------------------------------------------------------------------------
WINTERP is a Widget INTERPreter, an application development environment
enabling rapid prototyping of graphical user-interfaces (GUI) through the
interactive programmatic manipulation of user interface objects and their
attached actions. The interpreter, based on David Betz's XLISP, provides an
interface to the X11 toolkit Intrinsics (Xtk), the OSF/Motif widget set,
primitives for collecting data from UN*X processes, and facilities for
interacting with other UN*X processes. WINTERP thus supports rapid
prototyping of GUI-based applications by allowing the user to interactively
change both the UI appearance and application functionality. These features
make WINTERP a good tool for learning and experimenting with the
capabilities of the OSF/Motif UI toolkit, allowing UI designers to more
easily play "what if" games with different interface styles.
WINTERP is also an excellent platform for delivering extensible or
customizable applications. By embedding a small, efficient language
interpreter with UI primitives within the delivered application, users and
system integrators can tailor the static and dynamic layout of the UI,
UI-to-application dialogue, and application functionality. WINTERP's use of
a real programming language for customization allows WINTERP-based
applications to be much more flexible than applications using customization
schemes provided by the X resource database, Brunecky&Smythe's Widget
Creation Library (WCL), or OSF/Motif's UIL (user interface language).
An environment similar to WINTERP's already exists in the Gnu-Emacs text
editor -- WINTERP was strongly influenced by Gnu-Emacs' successful design.
In Gnu-Emacs, a mini-Lisp interpreter is used to extend the editor to
provide text-browser style interfaces to a number of UN*X applications
(e.g. e-mail user agents, directory browsers, debuggers, etc). Whereas
Emacs-Lisp enables the creation of new applications by tying together
C-implemented primitives operating on text-buffer UI objects, WINTERP-Lisp
ties together operations on graphical UI objects implemented by the Motif
widgets. Both achieve a high degree of customizability that is common for
systems implemented in Lisp, while still attaining the speed of execution
and (relatively) small size associated with C-implemented applications.
Other features:
* WINTERP is free software -- available via anonymous ftp from
export.lcs.mit.edu.
* Portable -- runs without porting on many Unix systems.
* Interface to gnuemacs' lisp-mode allows code to be developed
and tested without leaving the editor;
* Built-in RPC mechanism for inter-application communications;
* XLISP provides a simple Smalltalk-like object system.
* OSF/Motif widgets are real XLISP objects -- widgets can be
specialized via subclassing, methods added or altered, etc.
* Automatic storage management (via garbage collection) of
Motif/Xt/X data.
* Contains facilities for "direct manipulation" of UI components;
You may obtain the latest released version of the WINTERP source,
documentation, and examples via anonymous ftp from internet host
export.lcs.mit.edu (18.30.0.238): in directory contrib/winterp you will
find the compress(1)'d tar(1) file winterp-???.tar.Z. (??? represents the
version number). Slides, papers and further documentation can be found in
directory contrib/winterp/papers.
If you do not have Internet access you may request the source code to be
mailed to you by sending a message to ·····················@hplabs.hp.com
or hplabs!hplnpm!winterp-source.
There is also a mailing list for WINTERP-related announcements and
discussions. To get added to the list, send mail to
······················@hplabs.hp.com or hplabs!hplnpm!winterp-request.
For discussions about XLISP, see the USENET newsgroup comp.lang.lisp.x.
-------------------------------------------------------------------------------
Niels Mayer -- hplabs!mayer -- ·····@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*
Subject: Announcing WINTERP release 1.12 (for Motif 1.1 and 1.1.1)
==============================================================================
WINTERP 1.12 is a minor patch release over WINTERP 1.11 -- it corrects a
few simple source bugs that appeared when porting to non-HP platforms. This
release should work on most hardware and software platforms. WINTERP 1.12
has been tested on the following platforms:
* HP9000s3xx (68030/68040) running HPUX 7.0, HPUX 6.5.
* HP9000s8xx (HP's PA-RISC) running HPUX 7.0, HPUX 3.1.
* HP9000s7xx (HP's PA-RISC 1.1) running HPUX 8.0
* Sun Sparc 2 running SunOS Release 4.1.1
* Data General AViiON (m88k, DG/UX 4.30, GNU C 1.37.23)
* DECStation 3100 running Ultrix.
* SGI 4D ("MIPS, SGI Unix, latest release (Cypress)")
I've received reports that previous versions of WINTERP have run on the
following:
* IBM RS6000 AIX 3.1
* Sun 3 running SunOS 4.0.3
* MIPS (Mips RS2030)
* Intel System Vr3.2 v2.2 (using Intel X11R3 with Intel Motif v1.0.A and TWG/TCP v3.1)
* Apollo's 680xx machines.
Release 1.11 and 1.12 feature (briefly):
* Support for most of the new functionality of Motif 1.1 and 1.1.1
* Support for some of the new functionality of X11r4
* Source is #ifdef'd to automatically compile with Motif 1.1/1.1.1
or 1.0.
* Lots of new & nifty example and test programs.
* Various bug fixes and code cleanup.
* Added a number of missing Motif resources, methods, etc.
* Better portability -- I've tried to accomodate all the
patches and changes people have suggested in order to
allow WINTERP to compile on a variety of machines.
* Imakefiles corrected and updated to X11r4.
* Makefile.generic, Makefile.hpux, Makefile.sparc -- a generic
makefile system for those that don't want to bother with Imake.
* The TCP/IP eval server is now a compilation option, a Unix Domain
socket is used by default. This means that running WINTERP is
no longer a security hole. The TCP/IP server seemed to be a
big portability problem -- hopefully the Unix Domain socket
version will be more portable.
* TCP/IP and Unix Domain Socket servers can be enabled/disabled
via X resources. Verbosity of evaluation messages output can also
be reduced via X resource options. These options are useful for
people building stand-alone applications on top of WINTERP.
* Entering XLISP break-loop on Xlib errors, XtWarnings, and
XtErrors is optional. This allows applications delivered in
WINTERP to behave more like normal Xtoolkit programs.
* More and Better documentation.
* Various emacs-lisp functionality added in "contrib" directory,
courtesy of Bob Weiner of Brown University. (I Haven't had time
to integrate or test this software yet).
* etc, etc, etc.
Note that I've mainly tested WINTERP 1.12 on HPUX 7.0 running on HP9000s3xx
(Motif 1.0, Motif 1.1, Motif 1.1.1, and HP UEDK Motif 1.1); I've done a
little bit of testing on an HP9000s8xx machine, but only with Motif 1.0.
I've also briefly tested on an HP9000s7xx (Snakes series) machine running
HPUX 8.0 and HP UEDK Motif 1.1. I've also tested it on a Sun Sparc 2
running SunOS Release 4.1.1 and Motif 1.1.1.
I've received reports from Victor Kan (Data General Corporation) that this
version of WINTERP compiles and seems to run ok on a Data General AViiON
(m88k, DG/UX 4.30, GNU C 1.37.23).
* *
* *
***** I'd like to hear results from any Apollo, DEC, MIPS, IBM *****
***** users out there. *****
* *
* *
--------------------
This is the size of the new compressed tar file:
-rw-r--r-- 1 mayer users 1414493 Apr 22 02:06 winterp-1.12.tar.Z
--------------------
If you have internet access, you may retrieve this version of WINTERP via
anonymous ftp. If you don't, send e-mail to
··············@hplnpm.hpl.hp.com (hplabs!hplnpm!winterp-source)
and I'll begin to send out sources by electronic mail in about one to three
weeks. If you are requesting the sources to be e-mailed, please make sure
that your e-mail system can handle receiving up to two megabytes of
uuencoded text split into 30-50 messages of under 50 kbytes each. (No
requests for tapes, please!)
--------------------
Here's how to ftp WINTERP 1.12: (your input denoted by ^^^^^^^^^^)
hplnpm-17-/tmp> ftp export.lcs.mit.edu (HPites, use hplnpm.hpl.hp.com)
^^^^^^^^^^^^^^^^^^^^^^
[...]
Name (hplnpm.hpl.hp.com:mayer): anonymous
^^^^^^^^^
Password (hplnpm.hpl.hp.com:anonymous): <anypassword you want here>
^^^^^^^^^^^^^^^^^^^^^^^^^^^
331 Guest login ok, send ident as password.
230 Guest login ok, access restrictions apply.
ftp> cd contrib/winterp (HPites should do "cd pub")
^^^^^^^^^^^^^^^^^^
200 CWD command okay.
ftp> type image
^^^^^^^^^^
200 Type set to I.
ftp> get winterp-1.12.tar.Z
^^^^^^^^^^^^^^^^^^^^^^
200 PORT command okay.
150 Opening data connection for winterp-1.12.tar.Z (15.255.176.225,3988) (1414493 bytes).
226 Transfer complete.
1414493 bytes received in 690.63 seconds (1.96 Kbytes/sec)
ftp> quit
^^^^
221 Goodbye.
hplnpm-18-/tmp> zcat winterp-1.12.tar.Z | tar xvf -
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[... lengthy list of files from tar ...]
hplnpm-19-/tmp> rm winterp-1.12.tar.Z
^^^^^^^^^^^^^^^^^^^^^
* For compilation tips, take a look at winterp-1.12/doc/COMPILING
* For running hints, take a look at winterp-1.12/doc/RUNNING
* For known (Motif 1.1 only) bugs, see winterp-1.12/doc/BUGS
* For information on the examples, look at winterp-1.12/examples/README
* For general information about WINTERP, see winterp-1.12/doc/winterp.doc
-------------------------------------------------------------------------------
Niels Mayer -- hplabs!mayer -- ·····@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*
·····@hplnpm.hpl.hp.com (Niels P. Mayer) writes:
> Other features:
> * WINTERP is free software -- available via anonymous ftp from
> export.lcs.mit.edu.
But, according to the accompanying docs, "motif" (or rather, all known
implementations of) is not... Anyone know otherwise?
-Miles
--
--
Miles Bader -- HCRC, University of Edinburgh -- ···········@ed.ac.uk
In article <···················@scott.cogsci.ed.ac.uk> ·····@cogsci.ed.ac.uk (Miles Bader) writes:
> > * WINTERP is free software -- available via anonymous ftp from
> > export.lcs.mit.edu.
>
> But, according to the accompanying docs, "motif" (or rather, all known
> implementations of) is not... Anyone know otherwise?
Depends on how you define "free" -- Unix isn't free either, yet I don't
hear people complaining about that. Motif comes as part of the operating
system on a large number of "mainstream" Unix workstations that support the
X Window System, e.g. HP, Apollo, DEC, IBM, Data General, SGI, SCO, MIPS,
Sony, etc. The only mainstream workstation it doesn't come with is Sun.
Thus, from the perspective of the majority of workstation users, WINTERP is
completely free, in that you can compile it "right out of the box" using
the libraries included with the vendor's Unix. More importantly, you can
sell or freely distribute WINTERP, or WINTERP-based applications, in binary
form.
PS: The only people that really give me shit about having chosen Motif is
the GNU project, and Richard Stallman in particular... I can see the FSF's
perspective on this, and I hope they can understand mine -- I happen to
work for a company that is strongly behind Motif. Sorry....
~ From: ···@GNU.AI.MIT.EDU (Richard Stallman)
~ Newsgroups: gnu.emacs.help,comp.emacs
~ Subject: Winterp and Motif
~ Date: 24 May 91 15:06:28 GMT
~
~ Can Winterp be used with a toolkit other than Motif?
~
~ If not, the FSF recommends that you not use Winterp.
~ This is not because of anything wrong with Winterp itself.
~ Rather, it is because of Motif.
~
~ The FSF recommends against use of Motif because it is proprietary and
~ will not be available in the GNU system. We will have only the free
~ toolkits. Programs such as Winterp that use Motif won't run on a GNU
~ system.
~
~ The free X toolkits are improving. They deserve your support.
~ They will improve faster if more people use them.
~
~ If Winterp does require Motif, you could help the GNU project by
~ porting it to run with other toolkits. This project would make
~ Winterp available for use on GNU.
~
~ Alternatively (and even better), you could implement a free version of
~ Motif. But that's a lot of work. Porting Winterp is probably not too
~ hard.
-------------------------------------------------------------------------------
Niels Mayer -- hplabs!mayer -- ·····@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*
This thread prompts me to the general question, has anyone taught
CommonLisp how to open a pair of sockets and do RPC (remote
procedure calling) with other programs? This is a very good way
to communicate with C programs, or for that matter other CommonLisp
processes, even on other machines. It has the virtues of being
relatively fast and relatively simple. Most importantly, with RPC,
you could add plenty C functionality to your lisp without loading C
object files into your lisp image.
RPC is two things: a way of calling a specific function within
a specific program (a server) on some machine, and a way of serially
encoding data structures for transmission between processes.
Even just the data transmission would make it very easy to
communicate with a C process.
RPC provides a very nice protocol for communicating complex data, and I
believe that there is a program called rpcgen which will generate C
code to support that protocol from a look at your data structures.
Presumably, it wouldn't be hard to write some lisp code to generate
the equivalent lisp functions for sending and receiving the same
structures.
At any rate, someone must have something more authoritative to say
about this than I do, so comments are most welcome. I imagine
people who have designed interfaces between CommonLisp and
special-purpose I/O servers (like X or hardware driver) might
have considered using RPC.
cheers,
matt
In article <···················@mephisto.ils.nwu.edu> ·····@mephisto.ils.nwu.edu
(Matthew Brand) writes:
This thread prompts me to the general question, has anyone taught
CommonLisp how to open a pair of sockets and do RPC (remote
procedure calling) with other programs? This is a very good way
to communicate with C programs, or for that matter other CommonLisp
processes, even on other machines. It has the virtues of being
relatively fast and relatively simple. Most importantly, with RPC,
you could add plenty C functionality to your lisp without loading C
object files into your lisp image.
Symbolics provides a nice implementation. This is how they do the Mac
and Sun embeddings.
Regards,
Albert Boulanger
··········@bbn.com