I expect the answer to this question to be obvious, so I apologize in
advance; I did look through everything I could think of but found
nothing. The message that has been bugging me is very terse, and that
doesn't help.
Why do I get the following message:
; Converted F.
when running the following code (using CMUCL):
(flet () (defun f ()))
I get a lot of these messages and I'd be happy to get rid of them,
either by adjusting my code or with some muffling directive. It happens
in a part of my program that I need to run fast, and output to the
console is a major slowdown. I wouldn't want to just disable output
since I still need the occasional useful error message, warning, and
possible output by F.
On a related note, where should I look for documentation on that kind of
messages, as well as warning and error messages? I've asked before, but
got no reply; please tell me even if it's very obvious; I did do my
research before asking. Is there nothing like a list of error messages
with explanations? I understand the veteran Lisper doesn't need that,
but the poor newbie I am is often clueless when facing some messages.
Philippe Lorin <············@gmail.com> wrote:
+---------------
| Why do I get the following message:
| ; Converted F.
| when running the following code (using CMUCL):
| (flet () (defun f ()))
+---------------
See "cmcul/src/compiler/ir1tran.lisp". It's a compiler note that
conversion from lambda form to IR1 form [an internal representation]
has been done. [I think...]
+---------------
| I get a lot of these messages and I'd be happy to get rid of them,
+---------------
This should do it:
(setf *compile-print* nil)
But be warned that that will turn off a *lot* of useful information...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
| This should do it:
|
| (setf *compile-print* nil)
|
| But be warned that that will turn off a *lot* of useful information...
Thank you, this will get me some relief :) .
However, I can't get *COMPILE-PRINT* to work with a LET (to keep the
loss of useful information local); when I try the following:
(let ((common-lisp:*compile-print* nil))
(flet ()
(defun f ())
common-lisp:*compile-print*)) ; paranoia
I get this:
> ; Converted F.
>
> NIL
Meanwhile, if I use SETF, it works. It's probably me misunderstanding
LET and special variables (again)... What wrong assumptions am I making?
PS: Just in case, the code using SETF:
(setf common-lisp:*compile-print* nil)
> NIL
(flet () (defun f()))
> F
(setf common-lisp:*compile-print* t)
> T
(flet () (defun f()))
> ; Converted F.
>
> F
Philippe Lorin wrote:
> However, I can't get *COMPILE-PRINT* to work with a LET (to keep the
> loss of useful information local); when I try the following:
>
> (let ((common-lisp:*compile-print* nil))
> (flet ()
> (defun f ())
> common-lisp:*compile-print*)) ; paranoia
*compile-print* affects compiling, but the LET is set up as part of the
evaluation of the form.
Maybe your Lisp implementation has a COMPILER-LET that will do the
trick here? My guess is that whereas LET establishes the binding too
late (the code is processed already and being evaluated), COMPILER-LET
may do it too early (the code is being macroexpanded; not yet subject
to the transformations that print the ``Converted F'').
Philippe Lorin <············@gmail.com> writes:
>
> Rob Warnock wrote:
> | This should do it:
> |
> | (setf *compile-print* nil)
> |
> | But be warned that that will turn off a *lot* of useful information...
>
> Thank you, this will get me some relief :) .
>
> However, I can't get *COMPILE-PRINT* to work with a LET (to keep the
> loss of useful information local); when I try the following:
>
> (let ((common-lisp:*compile-print* nil))
> (flet ()
> (defun f ())
> common-lisp:*compile-print*)) ; paranoia
The reason this isn't working is that the warnings are being produced at
a different time than the execution of the form. One of the more
compilcated things about lisp is getting a handle on the different times
when things actually happen. Unfortunately, I don't have a good
reference to a discussion of that.
Can somebody else help?
There are several interesting "times" when things happen in Lisp.
Read time: When the forms are processed by the lisp reader
Compile time: When code is being compiled by the compiler
Load time: When a source or binary file is loaded.
Execute time: When forms are executed.
Macroexpand time: The time when macros expand. This will usually
happen during compile or execution time depending
on whether the code is compiled or interpreted.
There is implementation leeway on how
macroexpansion interleaves with other processing.
> Meanwhile, if I use SETF, it works. It's probably me misunderstanding
> LET and special variables (again)... What wrong assumptions am I making?
No. It has nothing to do with LET, which is normally what one would
want to use to bind special variables. It is the more subtle issue of
the LET binding not coming into effect until the code is executed, but
the warning happening at compile time. In other words, the binding of
the special variable in the code that is being compiled doesn't affect
the compile-time environment. It only affects the run-time environment.
--
Thomas A. Russ, USC/Information Sciences Institute
Philippe Lorin wrote:
> However, I can't get *COMPILE-PRINT* to work with a LET (to keep the
> loss of useful information local);
After further investigation, I think the thing that I do not get is when
*COMPILE-PRINT* is used, be it at evaluation time, compilation time or
whatever. Don't bother answering, it's up to me to go and study that
topic, which I've managed to avoid until now.
Philippe Lorin <············@gmail.com> writes:
>
> I expect the answer to this question to be obvious, so I apologize in
> advance; I did look through everything I could think of but found
> nothing. The message that has been bugging me is very terse, and that
> doesn't help.
>
> Why do I get the following message:
> ; Converted F.
>
> when running the following code (using CMUCL):
> (flet () (defun f ()))
>
> I get a lot of these messages and I'd be happy to get rid of them,
> either by adjusting my code or with some muffling directive. It happens
> in a part of my program that I need to run fast, and output to the
> console is a major slowdown.
Huh? Are you generating this code on the fly at runtime? You would
normally only get a message like this during the compilation phase of
processing the file and its assorted definitions.
If you compile the file and then load the compiled binary, you shouldn't
see any such messages at all.
> I wouldn't want to just disable output
> since I still need the occasional useful error message, warning, and
> possible output by F.
I am also just a little bit curious about your use of the global
function definition forms inside and FLET. Are you doing that because
you want to have some shared, private functions for a group of related
definitions? I mean is it more something like
(flet (...)
(defun f ...)
(defun g ...))
that you are doing? Otherwise it doesn't really make any sense to put
the FLET outside of global definition forms.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Philippe Lorin <············@gmail.com> writes:
>>I get a lot of these messages and I'd be happy to get rid of them,
>>either by adjusting my code or with some muffling directive. It happens
>>in a part of my program that I need to run fast, and output to the
>>console is a major slowdown.
>
> Huh? Are you generating this code on the fly at runtime? You would
> normally only get a message like this during the compilation phase of
> processing the file and its assorted definitions.
Yes, the code with the FLET is generated and run at runtime. It's for a
program where the user can write code that will be used immediately by
the program. This was one of my motivations for choosing Lisp over other
languages, incidentally.
> I am also just a little bit curious about your use of the global
> function definition forms inside and FLET. Are you doing that because
> you want to have some shared, private functions for a group of related
> definitions? I mean is it more something like
>
> (flet (...)
> (defun f ...)
> (defun g ...))
>
> that you are doing? Otherwise it doesn't really make any sense to put
> the FLET outside of global definition forms.
Yes, I want a private function to be shared by several other functions.
If you want to know the details, here is a stripped-down version of the
function that uses the FLET; it won't work by itself of course, but it
may give you an idea of what I am doing:
(defun get-custom-functions (object)
(eval
(let ((*package* (find-package :user-code)))
(read-from-string (concatenate 'string
"(flet ((utility-function (x) (do-stuff-with x)))
(declare (ignorable #'utility-function))
(defun custom-function-1 ()
(warn \"No custom-function-1 defined.\"))
(defun custom-function-2 ()
(warn \"No custom-function-2 defined.\"))"
(custom-code object)
" (list #'custom-function-1 #'custom-function-2))")))))
CUSTOM-CODE is supposed to contain definitions of CUSTOM-FUNCTION-1 and
-2. The FLET is supposed to allow CUSTOM-CODE to use UTILITY-FUNCTION.
Now I am wondering why I didn't make UTILITY-FUNCTION a "regular"
function. There's the obvious desire to show how it is only to be used
by CUSTOM-CODE, but seing how it leads to some obfuscated code, I think
I'll have to consider getting rid of that FLET thing.
Anyway, writing that function was fun :)
Philippe Lorin <············@gmail.com> writes:
> (defun get-custom-functions (object)
> (eval
> (let ((*package* (find-package :user-code)))
> (read-from-string (concatenate 'string
> "(flet ((utility-function (x) (do-stuff-with x)))
> (declare (ignorable #'utility-function))
> (defun custom-function-1 ()
> (warn \"No custom-function-1 defined.\"))
> (defun custom-function-2 ()
> (warn \"No custom-function-2 defined.\"))"
> (custom-code object)
> " (list #'custom-function-1 #'custom-function-2))")))))
I would rather have custom-code generate a s-expression, and write it as:
(defun get-custom-functions (object)
(handler-case
(eval
`(let ((*package* (find-package :user-code)))
(flet ((utility-function (x) (do-stuff-with x)))
(declare (ignorable #'utility-function))
(defun custom-function-1 ()
(warn "No custom-function-1 defined."))
(defun custom-function-2 ()
(warn "No custom-function-2 defined."))
,(custom-code object)
(list #'custom-function-1 #'custom-function-2))))
(error (err)
(format *error-output* "~&Cannot compile custom code:")
(describe err *error-output*)
nil)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Pascal Bourguignon wrote:
> I would rather have custom-code generate a s-expression, and write it as:
>
> (defun get-custom-functions (object)
> (handler-case
> (eval
> `(let ((*package* (find-package :user-code)))
> (flet ((utility-function (x) (do-stuff-with x)))
> (declare (ignorable #'utility-function))
> (defun custom-function-1 ()
> (warn "No custom-function-1 defined."))
> (defun custom-function-2 ()
> (warn "No custom-function-2 defined."))
> ,(custom-code object)
> (list #'custom-function-1 #'custom-function-2))))
> (error (err)
> (format *error-output* "~&Cannot compile custom code:")
> (describe err *error-output*)
> nil)))
I need to keep a copy of the code exactly as the user entered it,
keeping the comments and formatting; this is what CUSTOM-CODE holds.
With this in mind, I don't think it would be better to convert
CUSTOM-CODE to a sexp before using it, because that's already what this
code does, and this code is run only if CUSTOM-CODE has changed.
Plus, I need the symbols in the string to be interned in :USER-CODE, so
(I believe) I would have to prefix all of them if I wrote it the way you
propose (though you didn't; I assume you assumed it was not necessary;
if there is another reason please tell me), or maybe use IN-PACKAGE
around the FLET (not sure how); that would be ugly.
Philippe Lorin <············@gmail.com> writes:
> Pascal Bourguignon wrote:
>> I would rather have custom-code generate a s-expression, and write it as:
>> (defun get-custom-functions (object)
>> (handler-case
>> (eval
>> `(let ((*package* (find-package :user-code)))
>> (flet ((utility-function (x) (do-stuff-with x)))
>> (declare (ignorable #'utility-function))
>> (defun custom-function-1 ()
>> (warn "No custom-function-1 defined."))
>> (defun custom-function-2 ()
>> (warn "No custom-function-2 defined."))
>> ,(custom-code object)
>> (list #'custom-function-1 #'custom-function-2))))
>> (error (err)
>> (format *error-output* "~&Cannot compile custom code:")
>> (describe err *error-output*)
>> nil)))
>
> I need to keep a copy of the code exactly as the user entered it,
> keeping the comments and formatting; this is what CUSTOM-CODE
> holds. With this in mind, I don't think it would be better to convert
> CUSTOM-CODE to a sexp before using it, because that's already what
> this code does, and this code is run only if CUSTOM-CODE has changed.
>
> Plus, I need the symbols in the string to be interned in :USER-CODE,
> so (I believe) I would have to prefix all of them if I wrote it the
> way you propose (though you didn't; I assume you assumed it was not
> necessary; if there is another reason please tell me), or maybe use
> IN-PACKAGE around the FLET (not sure how); that would be ugly.
The main idea is that you need to check the user input more
throughoutly than read-from-string anyways: custom-code would have
parsed already the string into a valid s-expression.
You have to be careful with the time where *package* is used. If you
need for example utility-function to be intered in user-code then
you're right, [but you could write:
(eval `(flet ((user-code::utility-function ...)) ...)) ]
But note that:
(defpackage :user-code (:use :cl))
(defpackage :p1 (:use :cl))
(in-package :p1)
(eval
(let ((*package* (find-package :user-code)))
(read-from-string "(defparameter up (intern \"EX\"))")))
will intern user-code::up and p1::ex
P1[5]> (find-symbol "UP" :user-code)
USER-CODE::UP ;
:INTERNAL
P1[6]> (find-symbol "EX" :user-code)
NIL ;
NIL
P1[7]> (find-symbol "EX" :p1)
EX ;
:INTERNAL
P1[8]>
So perhaps you'll need (let ((*package* (find-package :user-code))) ...) both
outside of the string and inside of the string.
--
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
Pascal Bourguignon wrote:
> The main idea is that you need to check the user input more
> throughoutly than read-from-string anyways: custom-code would have
> parsed already the string into a valid s-expression.
I don't understand. If CUSTOM-CODE were a sexp, that sexp would have
been obtained through READ-FROM-STRING in exactly the same way it is
used in the original code; or are you suggesting some other way? Or is
the idea to isolate errors that belong to CUSTOM-CODE than those
belonging to the rest of the string?
> But note that:
>
> (defpackage :user-code (:use :cl))
> (defpackage :p1 (:use :cl))
> (in-package :p1)
> (eval
> (let ((*package* (find-package :user-code)))
> (read-from-string "(defparameter up (intern \"EX\"))")))
>
> will intern user-code::up and p1::ex
Wow, I hadn't thought of that, thanks. I'll add a LET *PACKAGE* in the
string right now.
Philippe Lorin <············@gmail.com> writes:
> Pascal Bourguignon wrote:
>> The main idea is that you need to check the user input more
>> throughoutly than read-from-string anyways: custom-code would have
>> parsed already the string into a valid s-expression.
>
> I don't understand. If CUSTOM-CODE were a sexp, that sexp would have
> been obtained through READ-FROM-STRING in exactly the same way it is
> used in the original code; or are you suggesting some other way? Or is
> the idea to isolate errors that belong to CUSTOM-CODE than those
> belonging to the rest of the string?
When you use read-from-string, depending on the source of the string
you must be more or less careful.
When the input is a string literal in your program, you can use it directly.
When the input is from a "user", you must be extra-careful. For example,
you start with (let ((*read-eval* nil)) ...)
you may have to set also the *read-base*, *read-default-float-format*
and *read-supress*.
In any case, it is worthwhile to catch errors on the read
s-expressions (missing parentheses, etc) closer to the user
interaction function, to let the user correct his input.
And it's easy to come with some more restrictive specfications where
you'd have to parse the input yourself anyways intead of using
read-from-string.
>> But note that:
>> (defpackage :user-code (:use :cl))
>> (defpackage :p1 (:use :cl))
>> (in-package :p1)
>> (eval
>> (let ((*package* (find-package :user-code)))
>> (read-from-string "(defparameter up (intern \"EX\"))")))
>> will intern user-code::up and p1::ex
>
> Wow, I hadn't thought of that, thanks. I'll add a LET *PACKAGE* in the
> string right now.
--
"This machine is a piece of GAGH! I need dual Opteron 850
processors if I am to do battle with this code!"