[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MacIvory, RPC and Think C
Date: Thu, 21 Dec 89 09:22:53 -0100
From: gmdzi!bruening@uunet.UU.NET (Inke Bruening)
I have a question concerning the RPC-facility of the
MacIvory. I used it with Lisp as client and C as server.
The C compiler is the one used in the example in the
MacIvory Programmer's Reference, Lightspeed C (THINK C),
version 3.01. First, I just programmed a small example and
it went well; but then I wanted to write a real
application. It was necessary to create a RPC-structure
of 48 c-strings. That was the interface between Lisp and
C. Unfortunateley, the C-programm created by the
Lispmachine was very large. So, after including some
libraries and adding a few lines to the C-program, the
C-compiler wasn't able to build a code resource. "Code
resource too big".
The THINK C libraries are extremely large, and if you use most
of them, the libraries alone eat up most of the 32K segment size
allowed in THINK C version 3. This is made worse by a bug in
THINK C version 3, known to be fixed in version 4, which tells
you that you have overflowed the 32K segment size when in fact
you have not; this is because it checks the segment size before
it eliminates library modules that are not actually used by your
program. The workaround for this is to make a custom library
that only contains what you really need (copy the THINK C
supplied library, which is really a project, and eliminate
files from it until you get a library that suits you). To see
what library entries you actually need, remove the library
from your project and do Check Link, which will create a
window containing a list of the undefined symbols that need to
come from libraries.
The Symbolics RPC library itself is very small, since most of its code
does not reside in your code resource, but is dynamically linked.
It was necessary to create a RPC-structure
of 48 c-strings.
It's possible that a fixed-length array of 48 elements, rather than a
structure with 48 components, would have produced more compact C code.