.
FRDCSA | internal codebases | Code Monkey
Homepage

[Project image]
Code Monkey

Architecture Diagram: GIF
Code: GitHub

Jump to: Project Description | Parent Description | Capabilities

Project Description

As a sign of the progress of our systems, we now have more or less a need for an "automated programmer" (or Debian maintainer). This is because, much in the same way that CMU's gaze estimator builds on their stable platform for Active Appearance Models which accurately model head position, we now have a large architecture for manipulating and working on packages. This allows us to mount a "code-monkey", i.e. gives us the setting in which to develop tools which can be applied to improving what already exists in terms of automated methods for dealing with code. Therefore the code-monkey system is appropriate. It fits in naturally with the existing hierarchy - radar predator architect boss (code-monkey).

Capabilities

  • Write something that can show typical usages of particular functions by analyzing the source - code-monkey!
    ("completed" "106214")
  • The self introspecting AI might be the same thing as code-monkey, ir the latter could derive from it.
  • Estimate which phrases belong to certain projects (I guess naive bayes sort of already does this, but we could employ nounphrase or maximum common substring, etc. Indeed many algorithms will have specific places of application and architect could work with perform and code-monkey to implement that.)
  • code-monkey should do more code generation. Right now boss framework is a very simple instance of that.
  • code-monkey can detect functions in a file and guess which libraries to include.
  • KELY for code-monkey
  • I could work on getting code-monkey working.
  • Then we annotate the relevant information in each case, code-monkey learns this.
  • code-monkey can detect functions in a file and guess which libraries to include.
  • Add object renaming capabilities to code-monkey's refactorings.
  • We could make code-monkey interactive and dialog with the user about what to do.
  • Hobbit/code-monkey should use reduction from working examples.
  • Obviously, code-monkey should use Devel::Refactor
  • code-monkey see Object::PerlDesignPatterns
  • code-monkey, see Object::PerlDesignPatterns
  • code-monkey should conduct a dialog with the user to determine what they want to write, so on and so forth.
  • code-monkey should run code benchmarks and suggest refactorings.
  • Estimate which phrases belong to certain projects (I guess naive bayes sort of already does this, but we could employ nounphrase or maximum common substring, etc. Indeed many algorithms will have specific places of application and architect could work with perform and code-monkey to implement that.)
  • Create a standard set of things that happen whenever new functionality is requested, including pattern matching searches and feedback from implementation programs like code-monkey and architect.
  • As part of code-monkey, write a script that lists all the significant functions in my systems and helps me to document them
  • For code-monkey, log the types of programming mistakes that we are making, that other people find. Create a database of such programming mistakes (invariably containing many itself), and use this to begin implementing autotests for these mistakes, in your code and in others.
  • A demo of code-monkey
  • code-monkey can do automated refactoring of libraries based on perhaps similarity of functions.
  • Need to convert all my documentation for perl modules to POD, and also, maybe make this conversion part of code-monkey


This page is part of the FWeb package.
Last updated Sat Oct 26 16:50:58 EDT 2019 .