From: Jeroen Valcke
Subject: Installing CMUCL on Linux
Date: 
Message-ID: <3B090F98.6E7D09EF@valcke.com>
Hello,

I am a Lisp newbie and up until now I did my lisp experimenting with
clisp on Linux. Lately I heard a lot about CMUCL and I want to give it a
shot. So I installed it.
But now when I type lisp at the prompt I get following message.

Tomsk:~$ lisp
Could not open file "/usr/lib/cmucl/lisp.core".
Maybe you should run cmuclconfig?
open: No such file or directory

So I run this cmuclconfig thinggie as root. This is what I get.

Tomsk:~# cmuclconfig
Welcome to cmuclconfig!

There is now a choice of cores to run: a small one or a
larger safe one: the following are installed, which do
you want to use as the normal lisp core?

Available cores:


Your choice:


There seem to be no cores available? How can I make such a core??? What
now?
I checked de cmucl manual didn't find anything on this though.
I'm sure this is something simple.
Any help appreciated.

-Jeroen-

From: Craig Brozefsky
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <87r8xirbei.fsf@piracy.red-bean.com>
Jeroen Valcke <······@valcke.com> writes:

> There seem to be no cores available? How can I make such a core??? What
> now?
> I checked de cmucl manual didn't find anything on this though.
> I'm sure this is something simple.
> Any help appreciated.

apt-get install cmucl-safe

or

apt-get install cmucl-small

also, you may want to do:

apt-get install cmucl-defsystem (depends on wether you you are in
unstable Debian or not)



-- 
Craig Brozefsky                             <·····@red-bean.com>
                                  http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
From: Jeroen Valcke
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <3B0A0CDA.B90054F@valcke.com>
Hey, thanks for your help, 

Craig Brozefsky wrote:
> 
> apt-get install cmucl-safe

Oke, I installed cmucl-safe and ran the cmuclconfig, seems fine now.

> apt-get install cmucl-defsystem 

Why would I need this package?

This is weird, when I typ this simple form (setq a 5) I get a warning!
*******
0] (setq a 5)
Warning: This variable is undefined:
  A
5

*******
Also when I type (help) at the lisp prompt I get an error, do I need to
install additional packages?

*******
* (help)
Warning: This function is undefined:
  HELP
Error in KERNEL:%COERCE-TO-FUNCTION:  the function HELP is undefined.
Restarts:
  0: [ABORT] Return to Top-Level.
Debug  (type H for help)
(KERNEL:%COERCE-TO-FUNCTION HELP)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer
exists:
  target:code/fdefinition.lisp.
*******
From: Raymond Wiker
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <86u22dol4r.fsf@raw.grenland.fast.no>
Jeroen Valcke <······@valcke.com> writes:

> Hey, thanks for your help, 
> 
> Craig Brozefsky wrote:
> > 
> > apt-get install cmucl-safe
> 
> Oke, I installed cmucl-safe and ran the cmuclconfig, seems fine now.
> 
> > apt-get install cmucl-defsystem 
> 
> Why would I need this package?
> 
> This is weird, when I typ this simple form (setq a 5) I get a warning!
> *******
> 0] (setq a 5)
> Warning: This variable is undefined:
>   A
> 5

        It's because you're trying to set an undeclared global
variable ("special variable", in Common Lisp terms). Try doing 

(defvar a 5)

        or 

(declaim (special a))
(setq a 5)

        Note: special variables are conventionally given names that
that start end end with "*" characters, e.g, *print-length*.

> > *******
> Also when I type (help) at the lisp prompt I get an error, do I need to
> install additional packages?

        What makes you think that there is a function called help?

        The error message you get ("Source file no longer exists")
tells you that CMUCL is unable to locate the source file
fdefinition.lisp. This is either because you have not installed the
source code, or because you have not told CMUCL where to find it.


-- 
Raymond Wiker
·············@fast.no
From: Jeroen Valcke
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <3B0A4312.67DDAB41@valcke.com>
Raymond Wiker wrote:
>         It's because you're trying to set an undeclared global
> variable ("special variable", in Common Lisp terms). 

Indeed, within a let it does work as expected, without warnings.
	* (let (a)
        	(setq a 5)
        	(print a))
	
	5
	5
	*

>         What makes you think that there is a function called help?

I get the following message when I start the program.

Tomsk:~$ lisp
CMU Common Lisp release x86-linux 2.5.2 18c+  2 May 2001 build 2173,
running on To
msk
Send questions to ··········@cons.org. and bug reports to the BTS and/or
cmucl-imp
@cons.org.
or to ········@debian.org
type (help) for help, (quit) to exit, and (demo) to see the demos
     ^^^^^^

Thanks!
From: Pierre R. Mai
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <87heydn62l.fsf@orion.bln.pmsf.de>
Jeroen Valcke <······@valcke.com> writes:

> > apt-get install cmucl-defsystem 
> 
> Why would I need this package?

You don't strictly need it to start working with CMU CL, but it does
provide an often used system-definition tool (equivalent to make),
which you'll likely want to start using once your applications grow
beyond the one source file stage.

> This is weird, when I typ this simple form (setq a 5) I get a warning!
> *******
> 0] (setq a 5)
> Warning: This variable is undefined:
>   A
> 5

This is correct, because there exists no binding for A that you could
modify with setq.  In this case, CMU CL will by default declare the
variable A special, modify it, and issue this warning.  You can modify
this behaviour by modifying the value of ext:*top-level-auto-declare*. 

In general though, only setq variables whose bindings you have
established either with a defvar/defparameter form (for special
variables), and/or an enclosing let form.  Sadly many beginners
introductions use (setq a 5) in preference to (defparameter a 5),
which would be the correct form to introduce new special global
variables.

> *******
> Also when I type (help) at the lisp prompt I get an error, do I need to
> install additional packages?
> 
> *******
> * (help)
> Warning: This function is undefined:
>   HELP
> Error in KERNEL:%COERCE-TO-FUNCTION:  the function HELP is undefined.

This seems like a packaging/setup error, though the HELP function was
never very helpful anyway, IMHO, so you're not missing much.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Jeroen Valcke
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <3B0A442D.9C9DDBB4@valcke.com>
"Pierre R. Mai" wrote:
> In general though, only setq variables whose bindings you have
> established either with a defvar/defparameter form (for special
> variables), and/or an enclosing let form.  Sadly many beginners
> introductions use (setq a 5) in preference to (defparameter a 5),
> which would be the correct form to introduce new special global
> variables.

Thanks for your helpful explanation of setq vs. defvar/defparameter.
It is true that most beginners introductions use setq. Also the fact
that I do get away with typing (setq a 5) in clisp made it even weirder.
I'll try to use defparameter where appropriote from now on.

-Jeroen-
From: Craig Brozefsky
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <87d791phu1.fsf@piracy.red-bean.com>
Jeroen Valcke <······@valcke.com> writes:

> Thanks for your helpful explanation of setq vs. defvar/defparameter.
> It is true that most beginners introductions use setq. Also the fact
> that I do get away with typing (setq a 5) in clisp made it even weirder.
> I'll try to use defparameter where appropriote from now on.

Also, when I tooling around at the REPL, I do

(setf foo 5)

That works.  It declared foo a sepcial variable for me.

-- 
Craig Brozefsky                             <·····@red-bean.com>
                                  http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
From: Pierre R. Mai
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <87u22dl42q.fsf@orion.bln.pmsf.de>
Craig Brozefsky <·····@red-bean.com> writes:

> Jeroen Valcke <······@valcke.com> writes:
> 
> > Thanks for your helpful explanation of setq vs. defvar/defparameter.
> > It is true that most beginners introductions use setq. Also the fact
> > that I do get away with typing (setq a 5) in clisp made it even weirder.
> > I'll try to use defparameter where appropriote from now on.
> 
> Also, when I tooling around at the REPL, I do
> 
> (setf foo 5)
> 
> That works.  It declared foo a sepcial variable for me.

(setf foo 5) is completely identical to (setq foo 5), and it works for
the same definition of working.  You can use ext:*top-level-auto-declare* 
to influence the actions that CMUCL takes on encountering such things:

*TOP-LEVEL-AUTO-DECLARE* is an external symbol in the EXTENSIONS package.
It is a special variable; its value is :WARN.
   WARN is an external symbol in the KEYWORD package.
   It is a constant; its value is :WARN.
Special documentation:
  This variable controls whether assignments to unknown variables at top-level
   (or in any other call to EVAL of SETQ) will implicitly declare the variable
   SPECIAL.  These values are meaningful:
     :WARN  -- Print a warning, but declare the variable special (the default.)
      T     -- Quietly declare the variable special.
      NIL   -- Never declare the variable, giving warnings on each use.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Pierre R. Mai
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <873d9xmlz3.fsf@orion.bln.pmsf.de>
Jeroen Valcke <······@valcke.com> writes:

> Thanks for your helpful explanation of setq vs. defvar/defparameter.
> It is true that most beginners introductions use setq. Also the fact
> that I do get away with typing (setq a 5) in clisp made it even weirder.
> I'll try to use defparameter where appropriote from now on.

Also take care to follow the advice by Raymond Wiker about enclosing
special variables by *, so that they don't clash with non-special
variables you want to use.  Read any introductory text on special
variables to understand the details.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Jeroen Valcke
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <IoxO6.3799$FL1.466376@afrodite.telenet-ops.be>
In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
<····@acm.org> wrote:

> Jeroen Valcke <······@valcke.com> writes:

> Also take care to follow the advice by Raymond Wiker about enclosing
> special variables by *, so that they don't clash with non-special
> variables you want to use.  

Why? I thought that enclosing 'global' vars with * was standard practice.

> Read any introductory text on special variables to understand the details.

Can you point me in the right direction for any such texts?

Thanks
-Jeroen-

-- 
Jeroen Valcke               ······@valcke.com   
ICQ# 30116911               Home page: http://www.valcke.com/jeroen
Phone +32(0)56 32 91 37     Mobile +32(0)486 88 21 26
It's not easy, being green    -Kermit the Frog
From: Pierre R. Mai
Subject: Re: Installing CMUCL on Linux
Date: 
Message-ID: <87bsolnmjn.fsf@orion.bln.pmsf.de>
"Jeroen Valcke" <······@valcke.com> writes:

> In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
> <····@acm.org> wrote:
> 
> > Jeroen Valcke <······@valcke.com> writes:
> 
> > Also take care to follow the advice by Raymond Wiker about enclosing
> > special variables by *, so that they don't clash with non-special
> > variables you want to use.  
> 
> Why? I thought that enclosing 'global' vars with * was standard practice.

Exactly.  I was just encouraging you to follow that standard
practice, in case you didn't know about it.  Actually the practice is
more precisely stated as enclosing _special_ (or dynamic) variables,
which don't actually have to have global bindings.  And in future
"editions" of Common Lisp, we might have global lexicals, and you
wouldn't have to enclose them either, since lexical scoping will
prevent clashes there.

> > Read any introductory text on special variables to understand the details.
> 
> Can you point me in the right direction for any such texts?

I think that most CL introductory texts contain such a treatment,
though it's been some time I looked at current textbooks, and hence
I've forgotten exact references, but IIRC then Winston & Horn's Lisp
(3rd edition) contains a whole chapter on special variables.  Paul
Graham's ANSI Common Lisp is bound to contain at least a couple of
paragraphs on special variables as well.  David B. Lamkins' Successful
Lisp discusses special variables as part of Chapter 8 (see
http://psg.com/~dlamkins/ for online access to Successful Lisp).

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: ······@honolulu.ilog.fr
Subject: Re: CMUCL top-level SETQ
Date: 
Message-ID: <9euc52$apf$1@honolulu.ilog.fr>
Pierre R. Mai <····@acm.org> wrote:

> Sadly many beginners
> introductions use (setq a 5) in preference to (defparameter a 5),
> which would be the correct form to introduce new special global
> variables.

But maybe the user does not want to introduce new special global
variables?

The benefit of Lisp's rapidly executing top-level loop is that the user
can program step by step. I often do things like

    (setq file (open "/tmp/foobar"))
    (setq line (read-line file))
    (setq n (length line))
    ...

even though afterwards the code will look more like

    (with-open-file (file ...)
      (loop
        (let ((line (read-line file nil nil nil)))
          ...

By automatically declaring top-level variables special, CMUCL is
forcing users to use these *asterisk* *names* for every temporary
result.(*) This does not make it easier to transform the step-by-step
protocol into a working function.

(*) I absolutely disrecommend having special variables without
asterisks or similar conventions. I once had a special variable called
'line' and then spent an hour of debugging obscure behaviour of code.

Just to see the effect, define a variable 'a' as non-special (I know,
you can't in CMUCL, but you can in CLISP), and a variable 'b' as
special, and observe the different combinations of lambda, defun and
these variables:

  (setq a 5)
  (defvar b "abc") 

  (defun foo (f a) (funcall f a))
  (foo (lambda (b) a) 'x)           ==> 5

  (defun foo (f b) (funcall f b))
  (foo (lambda (b) a) 'x)           ==> 5

  (defun foo (f a) (funcall f a))
  (foo (lambda (a) b) 'x)           ==> "abc"

  (defun foo (f b) (funcall f b))
  (foo (lambda (a) b) 'x)           ==> X


                    Bruno                     http://clisp.cons.org/~haible/
From: Kent M Pitman
Subject: Re: CMUCL top-level SETQ
Date: 
Message-ID: <sfwitilp5ay.fsf@world.std.com>
······@honolulu.ilog.fr writes:

> By automatically declaring top-level variables special, CMUCL is
> forcing users to use these *asterisk* *names* for every temporary
> result.(*) This does not make it easier to transform the step-by-step
> protocol into a working function.

Why don't you make a new setting for the option-variable controlling this
and only auto-declare the *'d variables?  Seems like that would hit most
users' needs.
From: Pierre R. Mai
Subject: Re: CMUCL top-level SETQ
Date: 
Message-ID: <87g0dpgn5z.fsf@orion.bln.pmsf.de>
······@honolulu.ilog.fr writes:

> Pierre R. Mai <····@acm.org> wrote:
> 
> > Sadly many beginners
> > introductions use (setq a 5) in preference to (defparameter a 5),
> > which would be the correct form to introduce new special global
> > variables.
> 
> But maybe the user does not want to introduce new special global
> variables?

You are free to change the documented option that controls this to
keep CMU CL from proclaiming the variable special, and just assuming
it is special on an instance by instance basis.  Still, the variable
is a special global variable, because CL doesn't know any other kind
of global variable (there are no global lexicals in CL).

> By automatically declaring top-level variables special, CMUCL is
> forcing users to use these *asterisk* *names* for every temporary
> result.(*) This does not make it easier to transform the step-by-step
> protocol into a working function.

Again, this is controlled by ext:*top-level-auto-declare*, so CMU CL
can be adjusted to other behaviour.  And indeed I personally do
recommend that one should put #\* around even temporary results.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Bruno Haible
Subject: Re: CMUCL top-level SETQ
Date: 
Message-ID: <9f3bn3$icr$1@honolulu.ilog.fr>
Pierre R. Mai <····@acm.org> wrote:

> Still, the variable
> is a special global variable, because CL doesn't know any other kind
> of global variable (there are no global lexicals in CL).

This is precisely the problem. 98% of the variables inside functions and
lambdas are lexically bound, yet it is impossible to create the same kind
of variable at top-level, with global scope. A special form DEFGLOBAL or
DEFLEXICAL is missing in CL.

                         Bruno                http://clisp.cons.org/~haible/