harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [general] Proposal for "first-order obvious logic" project
Date Wed, 02 Apr 2008 10:53:10 GMT
On Wed, Apr 2, 2008 at 12:11 AM, Alexei Fedotov
<alexei.fedotov@gmail.com> wrote:
> The most funny thing about that guy is that he sold that to the management. :-)

Haha, I love this one. *O*

Thanks,
xiaofeng

>
>
>  On 01 Apr 2008 20:07:21 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
>  > 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
>  >
>  >
>
>
>
>  --
>  With best regards,
>  Alexei
>



-- 
http://xiao-feng.blogspot.com

Mime
View raw message