<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 6:49 PM, Greg Hendershott <span dir="ltr">&lt;<a href="mailto:greghendershott@gmail.com" target="_blank">greghendershott@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">DrRacket: In the bottom pane (opened by View | Show Log), there&#39;s an<br>
edit control where you can tweak the levels for each logger (including<br>
the default logger). The default &quot;error debug@GC debug@PLaneT&quot; uses<br>
level &#39;error for the default logger and level &#39;debug for the loggers<br>
named GC land PLaneT. You can change interactively.<br>
<br>
XREPL: You can use its &quot;,log &lt;level&gt;&quot; command. But it&#39;s only for the<br>
default logger. You can&#39;t tweak other, named loggers added in 5.3.1.<br>
(I&#39;d submitted a PR to add this awhile back [1]. I didn&#39;t know about<br>
DrRacket&#39;s level@logger syntax at the time, and used a different<br>
style. I&#39;m realizing now maybe that&#39;s (part of) why the PR hasn&#39;t been<br>
accepted.)<br></blockquote><div><br></div><div>Thanks for the info.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

However do you mean you&#39;d like the test code itself to change the<br>
level programmatically and re-run the test? I think you&#39;re saying the<br>
levels are an attribute of a _receiver_, and you can&#39;t<br>
(programmatically) change levels for the receivers that DrRacket or<br>
XREPL are using, because those are private and not accessible to your<br>
code. So you&#39;d need the test code to make its own receiver (and I<br>
guess expect the user to &quot;turn off&quot; the default receiver provided by<br>
DrR or XREPL otherwise some dupes will be displayed)?<br></blockquote><div><br></div><div>Yes, that&#39;s what I eventually figured out (in the gist link).<br><br>It&#39;s less simple than I thought at first, but simpler than I thought at second.<br>

The asynchronicity makes things a little harder to deal with (you essentially <br>need to use the logger for all the messages you want to output, otherwise<br>it can become gibberish), but is also a nice feature to let the main program <br>

run smoothly.<br><br></div><div>Their parameterizability is also very nice, as it allows to completely shut up <br>one thread while letting the other shout, even though they use the same <br>procedures.<br><br></div><div>

I&#39;m glad I took the step from `displayln&#39; ;)<br></div><div><br></div><div>Laurent<br></div></div><br></div></div>