Lisp HUG Maillist Archive

declaim'ing compiler options

I'm RTFM'ing the CLHS and I don't get it.

After I run this test:

(declaim (optimize (debug 0) (safety 0) (speed 3) (space 0)))

(defun hello ()
  (print 'hello))

the compiler still prints in the output window this:

;;; Safety = 0, Speed = 0, Space = 0, Float = 1, Interruptible = 0
;;; Compilation speed = 1, Debug = 3, Fixnum safety = 3
;;; Source level debugging is on 
;;; Source file recording is  on 
;;; Cross referencing is on
; (TOP-LEVEL-FORM 1)
; HELLO

(i.e. high debug, low speed - the settings I had before I began)

I seem able to affect the compile options only by ^X^E'ing the declamation.

I've tried the same thing with proclaim, with the same result

(eval-when (:compile-toplevel :load-toplevel :execute)
  (proclaim '(optimize (debug 3) (safety 0) (speed 0) (space 0))))


(defun hello ()
  (print 'hello))

I want to write a .lisp file (a pseudo make-file) that contains compile-file's 
for a bunch of other stuff, and that begins by setting the compile options to 
what I want.

(I happen to be working with LWL 4.4.5)

suggestions / clarifications?
thanks
pt

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


Re: declaim'ing compiler options

Unable to parse email body. Email id is 4169

Re: declaim'ing compiler options

On July 19, 2005 03:29 pm, Martin Simmons wrote:
....
>   pt> (eval-when (:compile-toplevel :load-toplevel :execute)
>   pt>   (proclaim '(optimize (debug 3) (safety 0) (speed 0) (space 0))))
....
> The messages printed by compile-file show the state at the start of the
> file, because it sees the declamation, so you are probably doing the right
> thing already.

But, there's still something that I don't grok.

If I eval the proclaim in the listener (or explicitly with ^X^E), the changed 
compiler settings "stick" (I see them at the next compile).

In contrast, if I don't eval the proclaim explicitly and then compile the file 
2 times in a row, the compiler messages are the same, i.e. the changed 
settings have not stuck.

The way I understood the CLHS is that the eval-when proclaim version (at 
least) would make the settings "globally" - which I thought would have the 
same effect as the explicit eval'ing of the proclaim.

pt

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


Re: declaim'ing compiler options

Unable to parse email body. Email id is 4183

Updated at: 2020-12-10 08:51 UTC