[1]> (compile-file "src/calcOBP.lisp")
Compiling file C:\MyPrograms\lisp\clisp-2.28\src\calcOBP.lisp ...
** - Continuable Error
INTERN("CALCOBP"): #<PACKAGE EXT> is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
1. Break [2]>
// this is contents of calcOBP.lisp
(defun calcOBP(h w hbp ab sf)
(print (/(+ h w hbp)(+ ab w hbp sf)))
)
"Chichen710" <··········@aol.com> wrote in message ··································@mb-df.aol.com...
> I apologize ahead if this is an easy question, new to LISP
Hey, don't apologize for easy questions, you think we
all sit around and wait for the tough ones?
> [1]> (compile-file "src/calcOBP.lisp")
>
> Compiling file C:\MyPrograms\lisp\clisp-2.28\src\calcOBP.lisp ...
> ** - Continuable Error
> INTERN("CALCOBP"): #<PACKAGE EXT> is locked
> If you continue (by typing 'continue'): Ignore the lock and proceed
> 1. Break [2]>
>
>
> // this is contents of calcOBP.lisp
> (defun calcOBP(h w hbp ab sf)
> (print (/(+ h w hbp)(+ ab w hbp sf)))
> )
Hmm, well, this is an easy question, but it has a tricky answer.
The reason you are getting this error is because the current package
is the "EXT" package, and that package is `locked' so that you don't
accidentally wipe out the lisp system (the "EXT" package is a system
package).
The immediate `solution' to the problem is this: put an IN-PACKAGE
form at the beginning of your file,
(in-package "COMMON-LISP-USER")
and after you load the file, you ought to be able to just call
(calcOBP ...) with the appropriate parameters. If you can't, then
your lisp is starting with the wrong default value for the
current package and you'll have to write
(common-lisp-user::calcOBP ...)
Here are the details of what is going on, they aren't important in
the short run, but you will need to know them in the long run.
A package is mapping from strings to symbols. When lisp reads
(parses) your file, it has to convert the tokens you typed
(strings) into the symbols you meant. It use a package to
determine the symbol.
You can tell lisp explicitly which package to use for each
and every symbol by putting the package name before the symbol:
(common-lisp-user::defun common-lisp-user::calcOBP
(common-lisp-user::h common-lisp-user::w ....
But this is obviously not what one would want to do all the
time. So when lisp reads a token *without* a package name
in front of it, it uses a default package (stored in the variable
*package*).
Under normal circumstances, the initial value of *package* when
you start lisp should be the "COMMON-LISP-USER" package.
When you compile a file the file first has to be read, and
the reader will use the default package for mapping the tokens
to symbols if the fully qualified name is not used. This can
cause problems if the author of the file assumed that the
file would be compiled with a different default package.
Therefore, when you are writing a file, it is in general a very
good idea to put an (in-package ...) form at the very top to
ensure the default package is the one you intended. (A defpackage
form is another alternative.) It is extremely rare that you
would *not* want an (in-package ...) form, so getting into the
habit of doing will save you frustration.
(If you are paranoid, it might occur to you that the token "IN-PACKAGE"
might be incorrectly mapped because the default package may contain an
unusual mapping for it. Some people write (cl:in-package ...) to safeguard
against this.)
Notice that packages are consulted *only* when reading the file. They
are not used during loading or execution of the file. So there is no
concept of `loading a file into a package' or `running a program in a
package'.
However, if you load a file and it seemed to have no effect, it may
be because the interactive command line reader is using a different
default package than the file had. If that's the case, you can
either use the fully qualified name at the command line, or instruct
your lisp to read the command line in a different package.
>
> Notice that packages are consulted *only* when reading the file. They
> are not used during loading or execution of the file. So there is no
> concept of `loading a file into a package' or `running a program in a
> package'.
>
hi, some newbie question
what's the difference btw 'reading' and 'loading' in lisp?
thanks
"Raymond Tam" <··········@hotmail.com> wrote in message
·································@posting.google.com...
> >
> > Notice that packages are consulted *only* when reading the file. They
> > are not used during loading or execution of the file. So there is no
> > concept of `loading a file into a package' or `running a program in a
> > package'.
> >
>
> hi, some newbie question
>
> what's the difference btw 'reading' and 'loading' in lisp?
reading is taking a printed representation of something (a bunch of characters)
and converting them into what they represent (some lists, numbers, strings,
symbols, etc.) (This roughly corresponds to parsing the text.)
loading is taking a file that is presumed to contain lisp code and
causing that code to be evaluated. (This roughly corresponds to
linking and initializing.)
If you load a text file, the reader will be used to convert the characters
in the text file to a structure suitable for the evaluator. You can load
things other than text files, though. If you load a compiled file, the reader
is generally *not* used because the compiled file is specially coded.
Some lisp systems let you load `foreign' files like dlls or libs.
When you compile a text file, the reader will be used to convert the
characters in the text file to a structure suitable for the compiler.
Read can be used (and abused) on its own.
(setq thing (read (concatenate 'string "(" "foo ." " bar" ")")))
(car thing) => FOO
(cdr thing) => BAR
But you have to be careful doing this. An incomplete form will cause
an error, and reader macros like "#." can cause *anything* to happen.
Thanks for your response. I put in the in-package statement, and loaded file..
I can't even define function from lisp interpreter.
[1]> (/(+ 2 2) (+ 3 2))
4/5
[2]> (defun domath() (/(+ 2 2) (+ 3 2)))
** - Continuable Error
INTERN("DOMATH"): #<PACKAGE EXT> is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
1. Break [3]>
the only thing I seem to be able to do is basic stuff?
"Chichen710" <··········@aol.com> wrote in message ··································@mb-cr.aol.com...
> Thanks for your response. I put in the in-package statement, and loaded file..
>
> I can't even define function from lisp interpreter.
>
> [1]> (/(+ 2 2) (+ 3 2))
> 4/5
> [2]> (defun domath() (/(+ 2 2) (+ 3 2)))
>
> ** - Continuable Error
> INTERN("DOMATH"): #<PACKAGE EXT> is locked
> If you continue (by typing 'continue'): Ignore the lock and proceed
> 1. Break [3]>
>
>
> the only thing I seem to be able to do is basic stuff?
It looks as if the default package at the prompt is the "EXT" package.
(It shouldn't be, but it is.)
If you type
(setq *package* (find-package "COMMON-LISP-USER"))
at the very first prompt, it should work.
It is unusual that *package* would be set incorrectly upon startup.
It would indicate a mis-configured setup. Are any errors or warnings
printed when you start?