Todo list sorted in approximate order of importance.

Add your name/initials to an item when you are actively working on it.
When the task is complete, move it to the bottom of the file.

Longer-term issues
      
  - Add switch (--enable-globals or --enable-static-variables) to allow
    instrumentation of static fields (Java's name for global variables).
    Possibly have it take an argument indicating which fields to
    include/ignore.

  - Add --exception switch to allow instrumentation of exceptions

  - Consider choosing a new file representation that would be both more
    compact and faster to read and write.  For instance, there is no need
    to repeatedly print the names of variables, nor to represent numbers as
    ASCII printed representations.  The major benefit might be smaller
    dtrace files, but another benefit would be less time on file I/O and on
    parsing/unparsing.

  - Java 1.5 defines a new code attribute: Local Variable Type Table.
    I think this is there to help debuggers handle local variable that are
    generic (it only appears on methods with generics).  Unfortunately, this
    attribute is not supported by BCEL.  For now we are just removing it
    (because something we are doing makes it inconsistent).  A better 
    solution would be to update it correctly.

  - Implement --linked-lists option.
    This is low-priority, because it's obscure.  In Java, people shouldn't
    be writing this kind of code anyway.

Completed Tasks (add new ones at the top)

  - Add dtrace goal files (perhaps limited to some reasonable number
    of lines) to the regression tests.  This will allow us to see
    more quickly when a Chicory change causes dtrace diffs.
    (possibly wait for dtrace-diff)
    [etf] 8/9/05: Completed.

  - Add new option to Chicory to only output a given percentage of all
    observed records.  This will permit faster execution on large
    programs.
    [etf] 8/1/05: Completed.  See --trace-percent=<integer> flag.  Method entries/exits
    are excluded in pairs to avoid nonce mismatch issues in Daikon.

  - Related to outputting getter methods, add a flag to Chicory to indicate
    whether private variables/fields should ever be output.  Don't do this
    until we do output getter methods, or Daikon's output will become very
    uninformative:  right now, the usefulness of Daikon's output depends
    heavily on producing properties over private variables.
    [etf] 8/1/05: Completed. See --std-vis flag.

  - Currently, the DaikonVariableInfo trees are created at the same time as the decls info is ouptut.
    This should be changed so that the trees are created first, then used to print out the decls info (similar
    to how the DTraceWriter uses the DaikonVariableInfo objects to traverse the tree).
    Tree creation should be done in the RootInfo constructor, making the trees immutable.
    Will need to add fields in DaikonVariableInfo such as (declsShouldIgnore, dTraceShouldIgnore) so that,
    for instance, dtrace traversal doesn't print the static final primitive variable that the declwriter would.
    [etf] 8/1/05: Complete
    
  - Produce output not merely about the concrete representation of a data
    structure, but also about its abstract state, by creating new synthetic
    variables whose values come from the results of calling pure
    (non-side-effecting) methods.  For example, if we have
      class Point {
        double x;
        double y;
        double rho() { return Math.sqrt(x*x+y*y); }
        double theta() { return Math.atan2(x, y); }
      }
    then we could imagine reporting properties such as 
    "myPoint.theta() < 6.28".  There are existing purity analyses that we
    could use to determine which methods are safe to call; reusing such an
    analysis could make this extension pretty easy.
    [etf] 8/1/05: Completed.  See --purity-file switches in documentation.

  - Write a new dtrace-diff program in Java.  There is probably already
    Java code that can read a dtrace file.  The diff should be very
    simple at that point.
    [Sandra]

  - Add a Java 5.0 test to the test suite.   This will checkout not
    only Chicory, but annotate as well.  Carlos suggested the files
    in ~jhp/tmp/bst.tar
    [etf] 5/31/05: Added BinaryTree test under $inv/tests/daikon-tests.

  - Implement online mode 
    [etf]
    5/30/05: This has been implemented.  Online mode, which is invoked with the
    --daikon-online switch, behaves similary to the --daikon switch.  With the --daikon
    switch, Chicory outputs a dtrace file which Daikon reads.  With the
    --daikon-online switch, Chicory and Daikon communicate directly via a
    socket.

  - Daikon output is handled via StreamRedirectThread.  Daikon writes
    out progress indications that are designed to write over one
    another.  They are all on separate lines when run through Chicory.
    Run Daikon standalone and through Chicory to see the difference.
    [etf] 
    5/6/05: I fixed this by reading the stream in byte by byte
    (as opposed to line by line) and flushing after each one.  Thus,
    carriage returns will appear how they are intended to.  This is a
    little inefficient, but more correct.

  - Restructure code so we don't calculate the same thing on each
    method entry/exit, but just once when processing the class.  This
    is not so much an optimization as a code cleanup so if we change,
    for instance, what variables are instrumented or their order we
    only have to change it in one place.
    [etf]
    5/6/05: The DeclWriter now creates a tree data structure
    representing the traversal pattern.  Each node is a subtype of
    DaikonInfo.  The DTraceWriter traverses this tree to print a
    program point.  Overall, a much better solution than how we were
    doing it before.
  
  - Fix issue which occurs when classfile does not include line number
    information.  Dtrace/decls info should be syntactically correct.
    Currently, dtrace exit points do not have corresponding declarations
    (different, invalid line numbers)
    5/6/05 [etf] I fixed this about a month ago, with only one
    lingering issue: if there are multiple return statements on the
    same line, they often show up as different line number points in
    the decls/dtrace file (but do not cause any sort of crash)
  
 - Fix problem in which we force class initialization with calls to
    Field.get(null) (for static fields)
  4/7/05 [etf]: I remedied this in the following way:
  1.  all calls to class.ForName have the initialization parameter set to false
  2.  we are VERY careful about static fields.  the behavior is:
  	  a. for hardcoded static final primitives (from constant pool), we print these in the decls file
  	     by LOOKING UP the hardcoded constant value which was stored during the transform stage
  	  b. for all other types of statics:  First CHECK IF THE CLASS HAS BEEN INITIALIZED.  if it has,
  	  proceed as normal.  if it has not, return NonsensicalValue.  We determine if classes have been
  	  initialized by adding code to the <clinit> method (or creating it if it doesn't exist) which
  	  basically says "I'm initialized" to the rest of the system.

  - Fix --ppt-omit-pattern and --ppt-select-pattern to work on each
    ppt point name rather than only on class names.  I think this means
    we should consider a class instrumented if any of its methods
    match.  I think this change should be largely back compatible with 
    their current usage.
    [etf]
    
    4/3/0 [etf]: I have checked in a change which makes these switches
    work.  Please refer to the Daikon manual for detailed information
    about how it works.  In a nutshell, the commands work by checking
    each regex against the class name, method name, AND program point
    name, and "matching" if any of these match.
    
  - Fix bug which occurs for unnamed packages:
    For instance, if Bug.java is the following file:

	public class Bug {
    	Bug(int n) {
    	}
    	public static void main(String[] args) {
        	Bug b = new Bug(0);
    	}
	}

     Then "java daikon.Chicory --daikon Bug" dies with:

     Exception in thread "main" java.lang.Error: No dot in function name Bug(int)
        at daikon.PptName.<init>(PptName.java:78)

     Adding "package bug;" to the front of the file fixes the error.
     
     march 8, 2005, etf - made minor correction to jhp's fix of the same bug
     (removed extra space in the string)

  - Add a simple test of chicory to the tests that are performed on
    the build itself (before it is copied to the website).

    Feb 13 2005, jhp - a flame test is added to the 
    test-staged-dist target in $inv/Makefile

  - Primitives are at least sometimes printing as hashcodes rather than
    as their primitive values.  See diffs in $inv/tests/daikon-tests/fib.

    Feb 11 2005, jhp - Static primitives were printed as hashcodes.  There
    was a bug in the static code similar to the ones previously fixed
    in the normal field code.  Fixed in the same way.

  - Cleanup directory structure in $inv/chicory,  remove JDI based files
  
    Feb 07 2005 jhp - Moved everything actually used to the single
    directory $inv/daikon/chicory.  Chicory.java itself was placed in
    the directly in $inv/daikon.
    
  - Support DDTRACELIMIT and DDTRACELIMITTERMINATE environment variables
    just as dfej does.  This is partially in Runtime right now, but
    we need to call the proper methods when writing so it fully
    works.
    [etf]
    
    feb 16 2005 etf - Implemented this and tested it
    
  - Fix the output/err stream redirection to flush on each line feed
    so we see results in real time.
    2/9/05: fixed this by using BufferedInput and PrintStream

  - Static variables are not named correctly when a class with
    a static variable is referenced from another class. [sjl]
    fixed 2/10/05 

  - ChicoryPremain.jar and BCEL were not properly included in the
    release distribution file [jhp]

    Feb 10 2005 jhp - Added ChicoryPremain.jar and the BCEL code.  Also
    update daikon.jar to be a valid java agent for Chicory so users don't
    need ChicoryPremain.
    
  - variables declared as Object whose actual type is Number or
    Boolean will print their values as a Number or boolean and
    not as a hashcode.  We need to distinguish between these
    and objects used as wrapper internally (as Eric originally
    planned) so that these print as hashcodes and not numbers/booleans.
    Another approach would be to look at the declared type of the variable.
    If the declared type is primitive, Integer, etc, then the real value
    should be printed.  IF the declared type is Object or something else,
    then the hash code should be printed.  This problem can be reproduced
    in the StackAr example (though not in the StackAr regression test).
    It would be good to fix this so that the examples we ship work.

    Another interesting solution would be to accept floating point
    values as a valid hashcode in Daikon (note that integer values
    work fine right now).  
    
    2/10/05 etf: dTraceWriter.getValue now changes primitives to 
    PrimitiveWrappers.  printValue now correctly prints PrimitiveWrappers

  - Switch over the regression tests to chicory, leaving dfej as a
    user option.  Check in the changed goal files.

    2/18/05 MDE: Jeff already did this, I believe.


 LocalWords:  BCEL jhp dist inv diffs hashcodes JDI java daikon DDTRACELIMIT
 LocalWords:  DDTRACELIMITTERMINATE etf feb BufferedInput PrintStream sjl MDE
 LocalWords:  ChicoryPremain hashcode StackAr dTraceWriter getValue printValue
 LocalWords:  PrimitiveWrappers ppt dtrace
