harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] Proposal for "first-order obvious logic" project
Date Tue, 01 Apr 2008 16:07:21 GMT
On the 0x419 day of Apache Harmony Alexei Fedotov wrote:
> Tim, all,
> 
> While it would really great to have 100% API implemented, I broke into
> a sweat when imagined that the quality of our code base may drop in
> result of this approach, if it would not be properly supported with
> tests. This especially concerns sophisticated NotImplementedException
> implementation which is vulenrable to errors.
> 
> I come with an idea how we can handle it. I suggest investing into
> automatic tool which would parse bytecode of our methods, make a
> control flow graph and create sets of input parameters which would
> cover all branches in the code. Then we can run methods with given
> parameters and record resulting exceptions or objects (for
> non-serializable objects some hash function such as toString() may be
> recorded). Finally we can generate a test which would check that the
> method produces the recorded result for the set of parameters.
> 
> Using this approach we get a test suite with 100% branch coverage and
> 100% pass rate. Providing this as an argument we would beat those who
> might think that "first-order obvious logic" does not give us
> compatible and fully tested implementation.
> 
> If creating a control flow graph would be to too complex for an
> applying student, generating typical corner parameters (such as
> objects created by a default constructor) would give us 100% method
> coverage quickly.
> 
> Thanks!
> 
> :-)

funny, huh? I know the guy, who tried to do almost the same. Covering
all branches is impossible, of course, but for simple methods it could
work. That is how you get input data for tests. Golden values are
obtained from RI runs.

Bad, bad joke.

> On Tue, Apr 1, 2008 at 11:12 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > There are a number of interesting student projects being proposed at the
> >  moment, and I'd like to add another one for everyone's consideration.
> >
> >  It struck me this morning that since we have virtually got the entire
> >  platform working well, the remaining pieces could be deduced pretty well
> >  by simply describing the expected behaviour using the first-order
> >  'obvious logic' principle.
> >
> >  Using this principle we would simply write rules for the missing pieces,
> >  and implement an inference engine to evaluate these rules to complete
> >  the functionality.  While the rules can be written in any language, I'd
> >  suggest a good candidate would be the new 'actor participation rules
> >  intermediate language 1', and evaluate them using the Java obvious
> >  knowledge engine.
> >
> >  As an example of the rules we would need:
> >
> >    *drag and drop support*  Just implement drag.  After all, once you
> >  are dragging something the only option you have is to drop it.  That
> >  would be an obvious rule.
> >
> >    *rich text format support*  Just implement poor text support and
> >  invest in compounding instruments code.  After a few years the
> >  compounding effect will make the text increasing richer.
> >
> >    *not implemented exception*  Obviously the user's application doesn't
> >  want to see this exception.  Rather than throw the exception instrospect
> >  the stack and just return an object that will pass the application's
> >  validation checks instead.
> >
> >  I'm unwilling to mentor the project after today, but if anyone else
> >  wants to pick up the 'first-order obvious logic' (FOOL) project, writing
> >  code in 'actor participation rule intermediate language 1' (APRIL1) for
> >  the 'Java obvious knowledge engine' (JOKE) -- then I'd be facinated to
> >  see how well it works!
> >
> >  For more information see  http://tinyurl.com/395w9a
> >
> >  Regards,
> >  Tim
> >
> >
> 
> 
> 
> -- 
> With best regards,
> Alexei
> 

-- 
Egor Pasko


Mime
View raw message