Madhu writes: > Helu > * "Denis Papathanasiou" <[EMAIL PROTECTED]> : > > | I'm profiling an application, and since I don't know where to look, I > | start by calling (profile:profile-all). > | > | After the app has run a bit, I run (profile:report-time) on one of the > | functions, and it works, i.e. I get a report as expected. > | > | But when I try to map (profile:report-time) across all the functions > | being profiled (as defined in profile:*timed-functions*), I get this, > | and I'm not sure why: > | > | * (mapcar #'(lambda (fn-name) (profile:report-time fn-name)) > | profile:*timed-functions*) > | > | ; Note: Variable FN-NAME defined but never used. > | > | > | Error in FWRAPPERS:FIND-FWRAPPER: the function FN-NAME is undefined. > | [Condition of type UNDEFINED-FUNCTION] > | > | profile:*timed-functions* does contain a list of functions, and if I > | try any of those one at a time in (profile:report-time), it works. > | > | So why is the mapping problematic? > > PROFILE:PROFILE-TIME is a Macro. > > * (macroexpand-1 '(profile:report-time fn-name)) > > => (PROFILE::%REPORT-TIMES '(FN-NAME)) > > i.e. it ends up looking for #'FN-NAME and so it is not to be used > programatically. In this respect it is similar to the TRACE/UNTRACE
We could add that we can of course attain the desired effects by using the macro expansion, which in this case is simple: (mapcar (lambda (fn-name) (profile::%report-times fn-name)) But of course we cannot expect it to continue to work with a different release of the profiler, since we have the *double* *hint* "::%" ;-) But if there is no report-times* function doing the equivalent of the macro, then it's all we can do. -- __Pascal Bourguignon__ http://www.informatimago.com/
