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

Getting LaserJets to work



    Date: 14 Apr 88 09:09 EST
    From: STERRITT%SDEVAX.decnet@ge-crd.arpa

	    First, I have to make a pretty convoluted hack to get the loader
    NOT to complain that the functions defined in the file being loaded are
    redefinitions of stuff defined elsewhere.  Couldn't this be an (optional)
    switch on load?

Check out the m-X Set Patch File command in Zmacs.  This is even better
than a switch on load, since you don't have to remember to specify the
switch every time you load the file.

	    Third (nobody expects the spanish...), as long as I'm complaining
    about load, I created a useful program in a particular package (kee), and
    tried loading it into a world in whom Kee didn't exist; I figured, well,
    I'll just tell the load function (or the command line Load File) to use
    a :package of 'cl-user.  WELL -- load bombs (both ways!) into the debugger,
    and makes me respecify the package to get it to load!  _I_ know Kee doesn't
    exist, that's why I told you to use the other package... aaarrrgghg.

Probably what's going on here is that the :package option merely
controls the default package to use, if the file does not specify its
own package.  However, many files do specify a package, in their file
attribute lists, and this overrides the :package argument.

The :package argument is really a holdover from the days before file
attribute lists, when people had to manually remember which package to
load things into.  I had forgotten that there even was such a keyword.
I appreciate that it's annoying that it's not immediately obvious
whether it overrides the file attribute list or vice versa.

Rather than typing ":package 'xxx", you could have typed "(defpackage
xxx ..options...)", and then loaded the file; that would have worked,
and lets you control the package options, such as whether it inherits
from Common Lisp or Zetalisp, and things like that.