[developers] [spr38460] time() macro in Allegro CL breaks in run-time images
oe at ifi.uio.no
Tue Aug 30 23:29:47 CEST 2011
hi again, duane,
our application is a development environment for (large) grammars of
natural languages (see 'http://www.delph-in.net/lkb'). our software is a
compiler of sorts for a specialized description language, where it has
been customary for ages to wrap the loading (and 'compilation') of a
complete grammar into a time(). the main point here is to give the
grammar developer some feedback on resource usage. for example,
they might be alerted to a sudden increase in memory consumption,
caused by a change in their grammar---which could be good to know
during development (of the grammar). it would not be a very big deal
for us to give up this functionality (but it would be a real pain to have
time() suddenly signal an error in run-time images).
however, time() is part of ANSI Common Lisp with no obvious links
to the compiler (or other non-ANSI elements of ACL known to not be
available in run-time images). hence, it would seem surprising to me
to not have it around.
note that this use of time() is actually unrelated to my earlier query
about excl::time-a-funcall(). this latter function is used internally in
our system to 'profile' the execution of a grammar, and it would be a
crippling loss not to be able to programmatically measure resource
usage at run-time.
i hope this is the kind of information you were looking for?
On Tue, Aug 30, 2011 at 23:02, Duane Rettig <duane at franz.com> wrote:
>>> thanks for the proposed work-around, duane! i have confirmed that it
>>> works for our application to redefine cl:time() when i create a run-time
>>> imagine, so i cannot say we are desperate for an official patch :-).
> Thanks for the update. We're considering how to fix this for our next
> version; we're actually not all agreed that it should be allowed in a
> runtime, but we do have an idea floating around to allow some keywords
> in the time macro so that you can choose whether the compiler will be
> used or not. I'm more inclined to use the keyword approach than to
> exclude time from runtime images.
> Those arguing for removing time from the runtime (similarly to how we
> remove all profiler activity) say that the spec implies that the time
> macro is a development and tuning agent, and should thus be considered
> for leaving out of runtimes. Since you are using it in your runtime,
> perhaps you can explain your usage, so that we have another data point
> to consider how the time macro might be used as a part of the runtime
> image (as opposed to timing it or tuning its performance).
More information about the developers