Following up, in sort of a roundabout way, to my other post abour
conditions/signals/restarts, etc...
I suppose this is more of a style question or a philosophy question...
I'm working on some code to do testing of other code.
The breakdown of the code separates running of the tests from
presentation of the results (a good thing, IMHO). One "problem" with
that is that one cannot do any reassuring "the tests are running" output
during the processing of a list of tests.
My initial solution to this "problem" is just to signal that a test is
being run. I don't care what 'signal' returns, I'm just using it to let
any other code that cares have a chance to know what is going on.
My question(s) are:
a) Is this an abuse of the Condition system?
b) Even if (eq (answer '|a)|) nil), is there a better way to do this?
Thanks,
-D'gou
Doug Philips <····@mac.com> writes:
> Following up, in sort of a roundabout way, to my other post abour
> conditions/signals/restarts, etc...
>
>
> I suppose this is more of a style question or a philosophy question...
>
> I'm working on some code to do testing of other code. The breakdown
> of the code separates running of the tests from presentation of the
> results (a good thing, IMHO). One "problem" with that is that one
> cannot do any reassuring "the tests are running" output during the
> processing of a list of tests.
>
>
> My initial solution to this "problem" is just to signal that a test
> is being run. I don't care what 'signal' returns, I'm just using it
> to let any other code that cares have a chance to know what is going
> on.
>
>
> My question(s) are:
> a) Is this an abuse of the Condition system?
> b) Even if (eq (answer '|a)|) nil), is there a better way to do this?
I think it's a righteous use of conditions. In fact I think I'll add
that to my own test framework when I get a chance.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Doug Philips <····@mac.com> wrote in message news:<················@mac.com>...
> Following up, in sort of a roundabout way, to my other post abour
> conditions/signals/restarts, etc...
>
> I suppose this is more of a style question or a philosophy question...
>
> I'm working on some code to do testing of other code.
> The breakdown of the code separates running of the tests from
> presentation of the results (a good thing, IMHO). One "problem" with
> that is that one cannot do any reassuring "the tests are running" output
> during the processing of a list of tests.
>
> My initial solution to this "problem" is just to signal that a test is
> being run. I don't care what 'signal' returns, I'm just using it to let
> any other code that cares have a chance to know what is going on.
>
> My question(s) are:
> a) Is this an abuse of the Condition system?
> b) Even if (eq (answer '|a)|) nil), is there a better way to do this?
You probably don't need all the flexibility of the condition system to
hook two closely related modules together so that one provides status
about its execution to the other.
Therefore you can just do this with straight callbacks: pass down a
closure as an argument to the ``run tests'' logic, and have it invoke
the closure in between tests. The closure can print something on
standard output, drive a GUI, or whatever.
Conditions can be seen as a generalization of callbacks, when you
can't have such a tight coupling because the handling is scattered
through the program. You don't know where the handling code is, and
more than one destination is eligible. Conditions are classified into
a hierarchy; restarts are identified by symbols. Handlers can shadow
each other, inspect conditions and decline and so forth. All of this
is done without passing down any explicit context.
In article <················@mac.com>, Doug Philips <····@mac.com> wrote:
>Following up, in sort of a roundabout way, to my other post abour
>conditions/signals/restarts, etc...
>
>I suppose this is more of a style question or a philosophy question...
>
>I'm working on some code to do testing of other code.
>The breakdown of the code separates running of the tests from
>presentation of the results (a good thing, IMHO). One "problem" with
>that is that one cannot do any reassuring "the tests are running" output
>during the processing of a list of tests.
>
>My initial solution to this "problem" is just to signal that a test is
>being run. I don't care what 'signal' returns, I'm just using it to let
>any other code that cares have a chance to know what is going on.
>
>My question(s) are:
> a) Is this an abuse of the Condition system?
> b) Even if (eq (answer '|a)|) nil), is there a better way to do this?
Sounds like a clever solution.
I'd probably either pass in a function that can be called to report
progress (so a test harness that wants to be silent would pass in a
function that does nothing), or bind a special variable to such a
function. But your solution is more flexible because there can be multiple
handlers that all get to know about it.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> In article <················@mac.com>, Doug Philips <····@mac.com> wrote:
> >Following up, in sort of a roundabout way, to my other post abour
> >conditions/signals/restarts, etc...
> >
> >I suppose this is more of a style question or a philosophy question...
> >
> >I'm working on some code to do testing of other code.
> >The breakdown of the code separates running of the tests from
> >presentation of the results (a good thing, IMHO). One "problem" with
> >that is that one cannot do any reassuring "the tests are running" output
> >during the processing of a list of tests.
> >
> >My initial solution to this "problem" is just to signal that a test is
> >being run. I don't care what 'signal' returns, I'm just using it to let
> >any other code that cares have a chance to know what is going on.
> >
> >My question(s) are:
> > a) Is this an abuse of the Condition system?
> > b) Even if (eq (answer '|a)|) nil), is there a better way to do this?
>
> Sounds like a clever solution.
>
> I'd probably either pass in a function that can be called to report
> progress (so a test harness that wants to be silent would pass in a
> function that does nothing), or bind a special variable to such a
> function. But your solution is more flexible because there can be multiple
> handlers that all get to know about it.
Isn't binding a special variable to hold a reporting function
basically a poor man's version of the condition system? That is, isn't
that pretty much what HANDLER-BIND does under the covers, except with
some extra type dispatching foo? (I mostly ask just to make sure my
recently acquired understanding of the condition system is correct.)
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
>Barry Margolin <··············@level3.com> writes:
>> I'd probably either pass in a function that can be called to report
>> progress (so a test harness that wants to be silent would pass in a
>> function that does nothing), or bind a special variable to such a
>> function. But your solution is more flexible because there can be multiple
>> handlers that all get to know about it.
>
>Isn't binding a special variable to hold a reporting function
>basically a poor man's version of the condition system? That is, isn't
>that pretty much what HANDLER-BIND does under the covers, except with
>some extra type dispatching foo? (I mostly ask just to make sure my
>recently acquired understanding of the condition system is correct.)
You could say that about just about *any* feature of the language that
involves dynamic binding: handlers, restarts, unwind-protect, etc.
The differences are that they each address different needs, and offer
different ways of searching and matching that are appropriate for those
needs. In the case of a reporting function, it doesn't seem like most of
the features of handlers are needed: will there be subtypes of the
condition so that you might have specific and general handlers, do you need
the condition search to find multiple handlers, etc.?
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.