[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Allegro-Emacs interface on NeXT



Maybe I'm doing something wrong, but the following behavior is
not quite what I expected (or desire).  I have set up my .emacs
file to load the site-init.elc file (found in /usr/lib/emacs/lisp/fi,
presumably all put together by Franz).  Then, after bringing up
emacs, I can get an inferior-common-lisp window (and subprocess)
by typing "<m-X>fi:common-lisp".

OK, first question: why does Allegro come up loading things like
	; Fast loading /usr/cl/lib/code/ipc.fasl.
	; Fast loading /usr/cl/lib/code/process.fasl.
	; Fast loading /usr/cl/lib/code/foreign.fasl.
	; Fast loading /usr/cl/lib/code/cstructs.fasl.
	; Fast loading /usr/cl/lib/code/emacs.fasl.
	; Fast loading /usr/cl/lib/code/mdproc.fasl.
OK, ipc and emacs (and maybe process) I can believe should be there, 

but why foreign, cstructs, and mdproc?  Unless, I explicitly need
some of the latter functionalities, aren't I just cluttering up my
world with those packages?  (I can't even locate just where these 

loads are being called.)  If one DOES need these things, then
wouldn't it be better to make a new lisp image with these things 

included in the usr/cl/build/custom.cl file?

Then, the major question: I can then bring in a *.lisp file in a
separate buffer and execute, say, the previous s-expression with
<c-C><c-S>.  The interface does in fact DO this but in a funny
way (or, funny to me).  It writes out the region being evaluated
to a temporary file, which is then loaded into the Lisp world.  

(If you only had one window showing, the window splits and the cursor
drops into the the *common-lisp* buffer below.)  But, all you get 

from this, besides the "; Loading ..." comment, is the file "t"
indicating successful load.

What I would have preferred to see, if I were evaluating the line
	(setq sil 'bar)
would be the usual returned-value from the setq, namely 

	=> bar.
Or, if it were a defun or make-instance or whatever, the printed
representation of the object that was made.  I feel much better about
what I'm doing if I can see the intermediate results showing me that 

I am doing it right.  (Or wrong, for that matter; I like to develop
my defuns piecemeal.)

One reason I ask to see the returned value is because I know it CAN 

be done this way.  I have seen (and even used) an emacs-shell that
runs Lucid's CL as an inferior process, and this seems to send the 

defun or sexp more directly to the Lisp, printing value.

Am I missing some step in the set-up?

Change of subject/different question: the PCL package is a year old.
I have gotten ahold of the MayDay version from this year, but have
not been able to execute the (pcl::compile-pcl) successfully.  I did
change all the *.lisp extensions to *.cl, but it still complains:

	<cl> (load "~//Lisp//CLOS//defsys.cl")
	; Loading /silbar/Lisp/CLOS/defsys.cl.
	t 

	<cl> (pcl::compile-pcl)
	Compiling pkg...Error: File "/usr/pcl/pkg.cl" does not exist.
	[1] <cl> 


Does anyone know the right incantations to do this?  (Having written
this, wouldn't you know, it occurs to me to move all these files into 

a dir called /usr/pcl.  I'll try that presently.)

	Dick Silbar (neophyte Allegroist)