chicken-janitors
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-janitors] #702: macro expansion time category specification


From: Chicken Trac
Subject: Re: [Chicken-janitors] #702: macro expansion time category specification filter for log5scm
Date: Fri, 23 Sep 2011 13:40:24 -0000

#702: macro expansion time category specification filter for log5scm
--------------------------------+-------------------------------------------
  Reporter:  syn                |       Owner:  certainty
      Type:  enhancement        |      Status:  new      
  Priority:  not urgent at all  |   Milestone:  4.8.0    
 Component:  extensions         |     Version:  4.7.x    
Resolution:                     |    Keywords:  log5scm  
--------------------------------+-------------------------------------------
Description changed by syn:

Old description:

> The attached patch adds support for defining a category specification
> that's matched against at macro expansion time. If it matches, the
> {{{log-for}}} macro will expand to {{{(void)}}} and thus not generate any
> runtime overhead. The specification is passed through the environment
> variable {{{LOG5SCM_CAT_SPEC}}}. To implement this feature it was
> necessary to split the log5scm module into two modules (log5scm-lolevel
> and log5scm) so that the category spec matching code can be used both at
> macro expansion and run time.
>
> For example, consider this program:
>
> {{{
> (use posix log5scm)
>
> (define-category foo)
> (define-category bar)
> (define-category baz)
>
> (start-sender main
>               (port-sender (current-output-port))
>               (category bar))
>
> (log-for (foo) (begin (sleep 2) "some expensive foo bar"))
> (log-for (bar) "some bar")
> }}}
>
> Even though we only have a sender that's interested in log messages of
> the category bar the program will wait for 2 seconds because senders may
> change at runtime. The (sleep 2) is contrived of course, imagine building
> some elaborate data structure for debugging puproses there instead. Now
> invoking this program with {{{LOG5SCM_CAT_SPEC=bar}}} will completely
> eliminate the {{{(log-for (foo) ...)}}} call (well, replace it with
> {{{(void)}}} in fact). This can be useful for stripping debug messages
> completely from a compiled program by passing something like
> {{{LOG5SCM_CAT_SPEC='(not debug)'}}}.

New description:

 The attached patch adds support for defining a category specification
 that's matched against at macro expansion time. If it matches, the {{{log-
 for}}} macro will expand to {{{(void)}}} and thus not generate any runtime
 overhead. The specification is passed through the environment variable
 {{{LOG5SCM_CAT_SPEC}}}. To implement this feature it was necessary to
 split the log5scm module into two modules (log5scm-lolevel and log5scm) so
 that the category spec matching code can be used both at macro expansion
 and run time.

 For example, consider this program:

 {{{
 (use posix log5scm)

 (define-category foo)
 (define-category bar)

 (start-sender main
               (port-sender (current-output-port))
               (category bar))

 (log-for (foo) (begin (sleep 2) "some expensive foo bar"))
 (log-for (bar) "some bar")
 }}}

 Even though we only have a sender that's interested in log messages of the
 category bar the program will wait for 2 seconds because senders may
 change at runtime. The (sleep 2) is contrived of course, imagine building
 some elaborate data structure for debugging puproses there instead. Now
 invoking this program with {{{LOG5SCM_CAT_SPEC=bar}}} will completely
 eliminate the {{{(log-for (foo) ...)}}} call (well, replace it with
 {{{(void)}}} in fact). This can be useful for stripping debug messages
 completely from a compiled program by passing something like
 {{{LOG5SCM_CAT_SPEC='(not debug)'}}}.

--

-- 
Ticket URL: <http://bugs.call-cc.org/ticket/702#comment:1>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]