Forum: Ruby Re: Is Your Software Working A Little Too Predictably?

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
12aa0c72e4bebe3b2966574874b6fa7f?d=identicon&s=25 (Guest)
on 2006-03-20 03:31
(Received via mailing list)

Bernhard, Simon: I like the idea of reducing the pool of available
methods.  The test for arity is nice too, which could be done at the
start or as the pool is reduced, but I like my software to my work for
me sometimes and for the sake of clarity even if at the sake of
efficiency, hence rescue rather than testing first.  Although, it is
good to know why something has 'gone wrong' or to explicitly prevent
that too.

Joel: I had similar ideas for the purpose of constructing intelligent
autonomous networks of code...  Assume you have (untrained) monkeys at
keyboards at one end and hope to have something sensible at other given
enough decent filters, er DuckWeed?  (A little enviro joke for all you
ecologists and environmental engineers out there...  Any?)

Expect to see something like this in wacky (but good, useful---no really
this time... Hint, it'll do something other than p.) stuff soonish...

The more pressing need (or just simply what I referred to at the bottom
of that post) is for code to randomly 'rewrite' methods to point to
other methods.  Then one's code doesn't need to explicitly refer to
random_method and Test::Unit is automatically confused as soon as
include RandomMethodOrSimilar is dropped in.

It would be good to combine the reducing pool of methods into
DuckDebugging.  Another idea for DD is to change the number of
parameters, randomly or sequentially.

Oh and yeah, I didn't need that methods = self.methods line: I was
trying to make things obvious, but ended up being awfully redundant.


P.S. Excuse the lack of quoting below as ruby-talk > /dev/null due to
volume...  I just read it off the web presently.

Why stop there?


# On the theory that if something goes wrong, you should just
# try something else until you find something that works.
module DuckDebugging
  def method_missing(meth, *args, &block)
    m = methods
    meth2 = m[rand(m.size)]
    result = send(meth2, *args, &block)
  rescue => ex
    p [self, meth2, args, ex] if $DEBUG
    p [self, meth2, args] if $DEBUG

class Object
  include DuckDebugging

result = (now your program can be any batch of garbage
just enter words at random and you will get something)

p result
This topic is locked and can not be replied to.