HDTenEightyP/NetNews huggingface dataset:
From: welch@sacral.cis.ohio-state.edu (Arun Welch)
Subject: Re: How can I run INTERLISP?
Originator: welch@sacral.cis.ohio-state.edu
Organization: OSU-LAIR
Date: Thu, 10 Sep 1992 14:53:47 GMT

In article <1992Sep9.195640.5922@bert.eecs.uic.edu> inglehar@bert.eecs.uic.edu (James Inglehart) writes:

   I have a 1977 INTERLISP program, written at Stanford, and originally
   run under TOPS-20 at the Xerox PARC facility. (Its author has suggested
   to me that it may still run under "Xerox Lisp.")

Interlisp still exists, it's now a part of Medley, which is a
combination of Interlisp-D and Common Lisp. You can get info on the
product by calling Venue at (800)-228-5325, or send mail to
AISupport.mv@envos.xerox.com. Medley runs on a wide variety of
architectures, so you should be able to get it running

   Should I resign myself to learning Lisp and translating this old program
   into some more modern dialect (GNULisp, for example)? This could take me
   a month or more. But I must get this program running.

There are a couple of IL to CL translators in the Medley LispUsers
Archives on nervous.cis.ohio-state.edu:pub/lispusers/medley, but they
generally require some hand tweaking of the resulting code. Given that
you don't know Lisp right now, that might take a bit of work.

I've resurrected some truly ancient code to run under recent releases
of Medley, and it's been pretty painless.

...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@cis.ohio-state.edu


Newsgroups: comp.lang.lisp
From: charest@Aig.Jpl.Nasa.Gov (Len Charest)
Subject: Re: changing the pathname type
Followup-To: comp.lang.lisp
Reply-To: charest@aig.jpl.nasa.gov
Organization: NASA/Jet Propulsion Laboratory
Date: Mon, 14 Sep 1992 18:40:04 GMT

In article <HALTRAET.92Sep14091247@monsun.si.no>, haltraet@monsun.si.no (Hallvard Tr{tteberg) writes:
|> I would like to change the filetype of a pathname (e.g. to nil
|> (unspecified) or .lisp).... 
|> I cannot use (merge-pathnames <filename> ".lisp") since this
|> will only "change" the pathname-type if it is nil (unspecified)

(make-pathname :defaults <filename>
               :type ".lisp")

(make-pathname :defaults <filename>
               :type nil)
..................................................
                                  Len Charest, Jr.
                 JPL Artificial Intelligence Group
                          charest@aig.jpl.nasa.gov
Newsgroups: comp.lang.lisp
From: liberte@cs.uiuc.edu (Daniel LaLiberte)
Subject: Re: Function to print in #S format
Followup-To: comp.lang.lisp
Organization: University of Illinois, Urbana-Champaign, Dept CS
	<1992Sep9.011022.14516@jpl-devvax.jpl.nasa.gov>
Date: Wed, 9 Sep 1992 19:26:46 GMT

In article <1992Sep9.011022.14516@jpl-devvax.jpl.nasa.gov> charest@Aig.Jpl.Nasa.Gov (Len Charest) writes:

   3. (mutually exclusive) Use CLOS. Ha Ha only serious.


I took this suggestion seriously.  It wasnt obvious (to me) at first
how one is supposed to print an object readably.  I wrote the
following to help.  Please comment.

Dan LaLiberte
liberte@cs.uiuc.edu
(Join the League for Programming Freedom: league@prep.ai.mit.edu)
--------
;;; Mixin to facilitate printing objects readably.
;;; Author: Daniel LaLiberte (liberte@ncsa.uiuc.edu) September 1992

#|
Any class of instances may be printed with non-nil
*print-readably* by mixing in the print-mixin class.
A print-slots method must be defined for each class
to print all of the slots needed to reconstruct the instance.  
Any such slots must, of course, also have an :initarg.
|#

(defclass print-mixin ()
  ())

(defmethod print-object :around ((object print-mixin) stream)
  "Print the object readably if *print-readably* is non-nil."
  (if *print-readably*
    (progn
      (format stream "~%#.(make-instance '~s " (class-name (class-of object)))
      (print-slots object stream)
      (format stream ")"))
    (call-next-method object stream))
  object)

(defgeneric print-slots (print-mixin t)
  (:method-combination progn))

(defmethod print-slots progn ((object print-mixin) stream)
  (declare (ignore stream)))

#|

(defclass foo1 (print-mixin)
  ((foo1 :accessor foo1 :initarg :foo1 :initform 1) ))

(defmethod print-slots progn ((object foo1) stream)
  (format stream "~%   :foo1 ~s " (foo1 object)))


(defclass foo2 (print-mixin)
  ((foo2 :accessor foo2 :initarg :foo2 :initform 2) ))

(defmethod print-slots progn ((object foo2) stream)
  (format stream "~%   :foo2 ~s " (foo2 object)))


(defclass foo (foo1 foo2)
  ())

(let ((*print-readably* t))
  (format nil "~%~s" (make-instance 'foo :foo2 4)))

=> "

#.(make-instance 'FOO 
   :foo1 1 
   :foo2 4 )"
|#
Xref: sparky comp.lang.lisp:2402 comp.lang.lisp.franz:46 comp.unix.bsd:5485
From: mock@madrone.eecs.ucdavis.edu (Kenrick Mock)
Newsgroups: comp.lang.lisp,comp.lang.lisp.franz,comp.unix.bsd
Subject: Re: Franz Lisp lives!
Date: 10 Sep 92 20:51:55 GMT
Followup-To: comp.lang.lisp
Organization: U.C. Davis - Department of Electrical Engineering

The author of "PC-Lisp" for MS-DOS machines also has C source code
available.  I've compiled the source on our suns, and it runs franz
lisp just fine.  Quite fast too.  You can get the address of the
author from the PC-LISP archive if you want to write to him.

Kenrick
-- 
------------------------------------------------------------------------------
GEnie : K.MOCK     			Net : mock@madrone.eecs.ucdavis.edu
"Don't worry about the world ending today, it's already tomorrow in
 Australia..."  					      - CMS
Newsgroups: comp.lang.lisp,comp.arch,comp.lang.functional,comp.lang.misc,comp.lang.scheme,comp.lang.sigplan,comp.parallel,comp.compilers,comp.theory
From: Lori Lynn Avirett-Mackenzie <lori@au-bon-pain.lcs.mit.edu>
Subject: Wrong e-mail address in FPCA '93 Call for Papers Announcement
Reply-To: Lori Lynn Avirett-Mackenzie <lori@au-bon-pain.lcs.mit.edu>
Organization: MIT Lab for Computer Science, Cambridge, Mass.
Date: Fri, 11 Sep 1992 17:50:18 GMT
Keywords: CFP, conference, errors

The email address for submission and other inquiries is incorrect.
Please send submission and other inquiries to:  fpca93@jj.lcs.mit.edu.
Thank you.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.lang.lisp,comp.lang.lisp.x,comp.os.msdos.apps,comp.os.msdos.misc,brown.common-lisp
From: dth@cs.brown.edu (Dzung T. Hoang)
Subject: need help recovering Star Sapphire Common Lisp 3.3
Organization: Brown University Department of Computer Science
Date: Wed, 16 Sep 1992 00:10:09 GMT

While trying to install Star Sapphire Common Lisp ver. 3.3 on my MSDOS PC
I accidentally deleted Disk 2.  The sole content of that disk was an archive
file named _AR2_.  If you have Star Sapphire Common Lisp ver. 3.3, I would
like your help in retrieving this file.  Your help would be greatly
appreciated.  Please reply by email to the address below.

Dzung Hoang
----------------------------------------------------------------------------
Dzung T. Hoang
dth@cs.brown.edu
----------------------------------------------------------------------------
Newsgroups: comp.lang.lisp,comp.lang.clos
From: raman@cs.cornell.edu (T. V. Raman)
Subject: Smart diplay method 
Summary:   print-object method that displays slot names   and values
Keywords: display objects, print objects clos 
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Tue, 15 Sep 1992 23:41:32 GMT


How do I write a print-object method for a class that neatly formats
slot names and values one per line without having to explicitly write
(format "..."
(<slot-name-value> object)
..
)

Thanks,

--Raman
-- 
   T. V. Raman <raman@cs.cornell.edu>Tel: (607)255-9202  R 272-3649
                       Office: 4116 Upson Hall,
Department of Computer Science, Cornell University Ithaca NY 14853-6201
                Res: 226 Bryant Avenue Ithaca NY 14850
From: news@sail.LABS.TEK.COM (-Network News Daemon)
Newsgroups: comp.lang.lisp.x
Subject: Test message
Date: 10 Sep 92 20:26:25 GMT
Organization: Tektronix, Inc., Beaverton,  OR.

This is a test message. (I'm checking a reported distribution problem.)

Sorry,
Ron Kirkpatrick
News Administrator
Tektronix, Inc.
From: toma@sail.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.lisp.x
Subject: Re: Trouble with lcl and clx
Date: 10 Sep 92 19:59:33 GMT
Reply-To: toma@sail.labs.tek.com
Organization: Tektronix, Inc., Beaverton,  OR.

Test message -- please ignore

























































-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply
From: ronk@cascade.ens.tek.com (Ron Kirkpatrick)
Newsgroups: comp.lang.lisp.x
Subject: test message - please ignore
Date: 10 Sep 92 20:39:29 GMT
Reply-To: Ron.C.Kirkpatrick@tek.com
Organization: Tektronix, Inc.,  Beaverton, OR
NNTP-Posting-Host: cascade.ens.tek.com

Please ignore - testing problem with news distribution.

Ron Kirkpatrick
Tektronix, Inc.
News Administrator
503-627-6707
From: toma@sail.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.lisp.x
Subject: 8 bit characters in Xlisp
Date: 11 Sep 92 19:59:07 GMT
Reply-To: toma@sail.labs.tek.com
Organization: Tektronix, Inc., Beaverton,  OR.

Unfortunately posting news from this system has been broken for a couple
of months and no one knew it, so my posts on this issue ended up in the
proverbial bit bucket.

It turned out to be a trivial task to add the ability for 8 bit characters
to Xlisp-plus 2.1d since all 256 character values were supported virtually
everywhere anyway. Another couple of hours added the ability to handle
uppercase vs. lowercase where appropriate. Total additional code was 500
bytes including the new "ctype" table.

With the changes (which apply to the PC only), character codes 128-254 are
valid symbol constituent characters, work correctly in all the character
predicates, are handled properly by the *readtable-case* and *print-case*,
and are printed without special escapes alone and in strings.

In the next couple of weeks I will have version 2.1e ready for distribution.
I will put up a posting at that time, so don't ask about availability yet.

One major change in the new version is that fixnums (and ratios) do not
silently overflow anymore, but are coerced into flonums. This is still not
compatible with Common Lisp, but is a major improvment given the lack of
bignums. (Anyone want to volunteer adding bignums??)

-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply
Newsgroups: comp.lang.lisp.x
From: news@sail.LABS.TEK.COM (-Network News Daemon)
Newsgroups: comp.lang.lisp.x
Subject: Re: Trouble with lcl and clx
Date: 11 Sep 92 16:06:41 GMT
Organization: Tektronix, Inc., Beaverton,  OR.

In article <12524@sail.LABS.TEK.COM> toma@sail.labs.tek.com writes:
>Test message -- please ignore
>
>-- 
>Tom Almy
>toma@sail.labs.tek.com
>Standard Disclaimers Apply

Sorry for the band width...We are still expriencing problems.

Ron Kirkpatrick
News Administrator
Tektronix, Inc.
503-627-6707
From: news@cascade.ens.tek.com
Newsgroups: comp.lang.lisp.x
Subject: Re: test message - please ignore
Date: 10 Sep 92 22:27:31 GMT
Organization: Tektronix, Inc., Beaverton,  OR.
NNTP-Posting-Host: cascade.ens.tek.com

test please ignore.

Ron Kirkpatrick
News Administrator
Tektronix, Inc
503-627-6707
From: news@cascade.ens.tek.com
Newsgroups: comp.lang.lisp.x
Subject: test article
Date: 10 Sep 92 22:32:04 GMT
Organization: Tektronix, Inc., Beaverton,  OR.
NNTP-Posting-Host: cascade.ens.tek.com

test news article.

Please ignore

Ron Kirkpatrick
News Administrator
Tektronix
From: toma@sail.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.lisp.x
Subject: test message
Date: 10 Sep 92 20:20:43 GMT
Reply-To: toma@sail.labs.tek.com
Organization: Tektronix, Inc., Beaverton,  OR.

Test message -- please ignore
-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply
From: toma@sail.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.lisp.x
Subject: test
Date: 10 Sep 92 20:28:35 GMT
Organization: Tektronix Inc., Beaverton, Or.

This is a test with postnews

-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply
From: ronk@cascade.ens.tek.com (Ron Kirkpatrick)
Newsgroups: comp.lang.lisp.x
Subject: Re: test message - please ignore
Date: 10 Sep 92 21:43:44 GMT
Organization: Tektronix, Inc., Beaverton,  OR.

Test message please ignore.

Ron Kirkpatrick
News Administrator
Tektronix, Inc
503-627-6707
-- 
Ron Kirkpatrick
Tektronix, Inc
MailBridge Postmaster
503-627-6707
Newsgroups: comp.lang.lisp.x
From: sjameson@fergie.dnet.ge.com (Stephen M Jameson)
Newsgroups: comp.lang.lisp
Subject: Function to print in #S format
Date: 8 Sep 92 20:19:26 GMT
Reply-To: sjameson@atl.ge.com
Organization: General Electric Advanced Technology Labs

This ought to be a FAQ, but I haven't seen it.  How do I print a structure in
#S-format, i.e. so that the reader will automatically reconstruct the
structure?  The application is obvious: I would like to have a :PRINT-FUNCTION
specified in the DEFSTRUCT which will print in a concise, non-readable format
if a certain switch is set, and print in the verbose, readable format if the
switch is not set.  On the Symbolics I figured out a way to do it but it did
not seem portable, and CLTL2 doesn't mention anything beyond the semantics of
#S format, and that if you don't specify a :PRINT-FUNCTION, "a function is
provided for the structure which will print out all its slots using #S syntax."

-- Steve


--
Steve Jameson                           General Electric Aerospace 
sjameson@atl.ge.com                     Advanced Technology Laboratories
                                        Moorestown, New Jersey              
****************************************************************************
**  . . . but I do not love the sword for its sharpness, nor the arrow    **
**  for its swiftness, nor the warrior for his glory.  I love only that   **
**  which they defend . . .                                               **
**    -- Faramir, "The Two Towers"                                        **
****************************************************************************
Xref: sparky comp.lang.lisp:2400 comp.arch:9337 comp.lang.functional:1089 comp.lang.misc:3003 comp.lang.scheme:2173 comp.lang.sigplan:30 comp.parallel:2098 comp.compilers:1538 comp.theory:1907
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp,comp.lang.lisp.franz,comp.unix.bsd
Subject: Re: Franz Lisp lives!
Date: 10 Sep 92 16:56:53 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <7482@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>>        * A Franz Lisp environment which includes:
>>            - An interpreter (lisp, at least version Opus 38.22).
>>            - A compiler (liszt, at least version 8.08 [.22]).
>
>I have a compile-to-C version of Liszt that I developed a number of
>years ago and (together with some other people) I've recently made
>Franz Lisp work in 386BSD.  So, although I don't have time to do it
>myself right now, this version of Franz should be fairly easy to
>port to Sparcs and to random "Berkeley Unix" machines in general.
>If there is any interest in this, I will try to make the sources
>available fairly soon.

A number of people have written to say that they are interested, 
so I'll try to do something.  There are some tedious but necessary
changes I have to make to the sources before I can relevase them,
but once I do that I'll put them somewhere for ftp.

-- jeff
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: window-zoom-event-handler (C-X 1)
Date: 16 Sep 92 00:18:41 GMT
Full-Name: Bill St. Clair
Original-To: squeegee@world.std.com (Stephen C. Gilardi)
Original-Cc: info-mcl

>Dear info-mcl:
>
>I tried to make "C-X 1" zoom the window to full screen similar to
>the EMACS command of the same keystroke.  Based on the examples,
>I tried this:
>
>(defmethod ed-zoom-window ((w fred-mixin))
>  (window-zoom-event-handler w 8))
>
>(comtab-set-key *control-x-comtab* '(#\1) 'ed-zoom-window)
>
>That works a little, but it doesn't update the window properly.
>To see this you could try loading the forms above and then
>trying "C-X 1" on a newly opened "Fred Commands" window.  I tried
>"inval"-ing certain things at certain times, but nothing worked.
>
>Could someone please clue me in on how to make "C-X 1" work.  I thought
>"C-X 0" might be a good name for a command to Zoom a window down to
>its small size --> (window-zoom-event-handler 7).

Your example works fine for me in 2.0 final, but fails in the way
you outline in 2.0b1. The reason was not immediately apparent to me,
but it seems to be a timing problem of some sort. If I
(trace window-size-parts), which causes a delay to print stuff in
the Listener between the time the window is zoomed and when it is
redisplayed, then it works fine.

Are you indeed using 2.0b1?
From: ranson@LANNION.cnet.fr (Ranson)
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  MPW C Help
Date: 15 Sep 92 10:45:00 GMT
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
	Relayed; 15 Sep 92 10: 44:59+0200
X400-Received: by /PRMD=CNET/ADMD=ATLAS/C=FR/;
	Relayed; 15 Sep 92 10: 45:00 GMT
Original-To: info-mcl@cambridge.apple.com, slack@starbase.MITRE.ORG

Have you checked how the compiler allocates local static variables? What it
they are allocated as a5-relative?
The Apple-recommanded way of storing task variables is to extend the TMTask
structure. On entry, A0 points to the TMTask so you can access your variables.
     Daniel.
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: MCL 2.0 final defsys package screw
Date: 11 Sep 92 17:34:32 GMT
Full-Name: Bill St. Clair
Original-To: nathan@akbar.teleos.com
Original-Cc: kab@cambridge.apple.com (Kim Barrett), info-mcl

> Date: Thu, 10 Sep 92 18:09:48 EST
> From: kab@cambridge.apple.com (Kim Barrett)
> To: nathan@akbar.teleos.com
> Subject: Re: MCL 2.0 final defsys package screw
> Cc: info-mcl%cambridge.apple.com@apple.COM
>
> [...]
>
> Another (to me, clearer) way to write it is
>
>  (let ((*package* (if package (find-package package) *package*)))
>    (load path))

This can get you in trouble if FIND-PACKAGE can't find a package
with the given name and returns NIL. Binding *package* to NIL tends
to make MCL very unhappy. Better would be:

(let ((*package* (if package 
                   (or (find-package package)
                       (error "There is no package named: ~s" package))
                   *package*)))
  (load path))
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Bug in Inspector?
Date: 8 Sep 92 22:04:44 GMT
Full-Name: Bill St. Clair
Original-To: djskrien@COLBY.EDU (Dale J. Skrien)
Original-Cc: info-mcl

>Sometimes when I inspect a list of CLOS objects with the inspector, the
>HEX values associated with the objects seems to change arbitrarily.  Here's
>a simple example:
>
>? (defvar xx (list (make-instance 'view) (make-instance 'view)))
>(#<VIEW #xB5AD69> #<VIEW #xB5ADE9>)
>? (inspect 'xx)
>#<INSPECTOR-WINDOW "XX" #xB5AED1>
>
>At this point, the inspector window opens and shows that the value of xx is
>a list of two views.  If I double-click on that list of two views in the
>inspector window to inspect these views, I get a new inspector window
>for the list.  So far, so good.
>     However, now I close this new inspector window and double-click
>on the list of two views again in the original inspector window to reopen
>the new inspector window for the list.  I repeat this closing and opening
>the inspector window for the list of two views several times.  Eventually,
>the inspector window for the list of two views shows different HEX values
>associated with the two views.  For example, I got
>   (#<VIEW #xB5A3C1> #<VIEW #xB5A431>)
>
>Does this mean the objects moved (due to garbage collection or some
>other reason)?  I have the ephemeral garbage collector on.

The hex number in the print string for views (and many other objects) is a
memory address. Hence, as you surmised, it may change whenever garbage
collection happens, ephemeral or otherwise.
From: lynch@ils.nwu.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: ccl::draw-outline
Date: 9 Sep 92 18:03:48 GMT
Original-To: info-mcl@cambridge.apple.com

>In my application, I turned the outline of an editable-text-dialog-item on and off according  
>to some event.
>
>In the beta version, (setf (slot-value x 'ccl::draw-outline) nil) worked well.  
>
>(x is an instance of the editable-text-dialog-item).  
>
>
>But this is not working in MCL2.0.  I also tried 
>
>
>(setf (slot-value x 'ccl::draw-outline) nil) 
>
>(view-focus-and-draw-contents x)
>
>and though x would redraw itself.  This does not work either.
>
>The opposite operation, i.e., to turn the outline on,  works fine by the following:
>
>(setf (slot-value x 'ccl::draw-outline) t) 
>
>(view-focus-and-draw-contents x).
>
>Any suggestion?  Thanks
>
>Sheldon

Since the outline is not within the bounds of (view-corners ) [ugh!] you
will probably need to erase a suitable rectangle after setting the slot
value and before calling view-focus-and-draw-contents.

If this causes too much flash, you can use a region which is the difference
of a suitable rectangle and view-corners...
"TANSTAAFL" Rich lynch@ils.nwu.edu
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Typep problem on array dimensions?
Date: 11 Sep 92 20:38:50 GMT
Full-Name: Bill St. Clair
Original-To: westling@starbase.mitre.org (Mark Westling)
Original-Cc: info-mcl

>I create an array like this:
>
>(setq ar (make-array '(4 4) 
>               :element-type 'double-float
>               :initial-element 0.0))
>
>and, as expected, 
>
>  (type-of ar)
>  -->  (simple-array double-float (4 4)).
>
>But here's what I get when I try a typep:
>
> (typep ar '(simple-array double-float (4 4))) 
>  --> nil
>
>At first I thought this was a type discrimination problem,
>but MCL 2.0 stores double-floats as double-floats; and then
>I found:
>
>  (typep ar '(simple-array double-float (* *)))
>  --> t
>
>What gives?

Bug in TYPEP. Has probably been there at least since 2.0b1. I guess
nobody has ever specified the dimensions of an array to TYPEP.
I have prepared a patch for inclusion in patch 2 for MCL 2.0. I'll
mail it to anyone who asks for "typep-of-array-patch".
From: kab@cambridge.apple.com (Kim Barrett)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: MCL 2.0 final defsys package screw
Date: 10 Sep 92 23:09:48 GMT
Full-Name: Kim Barrett
Original-To: nathan@akbar.teleos.com
Original-Cc: info-mcl%cambridge.apple.com@apple.COM

> The offending piece of code is:
> 
> (defun ...
> 
>   (if package
>     (let ((spackage *package*))
>       (unwind-protect
>           (progn (in-package package)
>                  (load path))
>         (in-package (package-name spackage))))
>     (load path))
> 
> ...)
> 
> I assume that the problem has to do with a change in when in-package
> gets evaluated (presumably related to the change between CLtL1 and
> CLtL2) and what it expects to see as its argument.  Packages have
> always seemed a little magical to me, so I was hoping someone would
> tell me whether the following translation would have the correct
> effect:
> 
>   (if package
>     (let ((*package* (find-package package)))
>       (load path))
>     (load path))

Yes.  In fact, it should have been written in that fashion to start with.  
(That business of using unwind-protect with in-package is quite yucky).  
Another (to me, clearer) way to write it is

  (let ((*package* (if package (find-package package) *package*)))
    (load path))