VSL Meeting 2/15/2010

  • Everyone read SVN book on merging and branching
  • Do not check in derived files into repository (esp. big binaries)
    • once checked in, there forever
  • Everyone read paper on KLEE
  • Tim to speak in SIG-SYS on Accuracy
  • BigRational
    • create factory to deal with BigRational, BigInteger in consistent way: flyweight, static operations
    • util.number
    • class Numbers
    • methods to produce BigIntegers and BigRationals
    • operations that mix the two???

VSL Meeting 2/20/08

Present
Siegel, Moelius, Wei, Xu
Secretary
Siegel
  • I pointed out existence of Wiki and told everyone to use it freely
  • I will set up a cron job to automatically check out code and run javadoc on it each night. The resulting javadoc pages will get posted on the web site http://vsl.cis.udel.edu/developer/mover. To do this I will require the code to compile.
  • every module should have a Makefile so that just calling "make" will do whatever needs to be done for compilation.
  • We went over current architecture of Mover
  • I gave a demo of the DfsSearcher
  • Jiaqiang gave a presentation on the mir interfaces. The following issues arose:
    • integer types: is it necessary to have all of them, or could we just have one intRange type. Problem is that MPI has predefined datatypes for byte, short, int, long, etc., these datatypes have different "sizeOf"s, etc., so if we wish to reason (and check properties of) those kinds of things we need to represent them in the model somehow.
    • should we use BigIntegers to represent the bounds for the IntRange type? Should we use BigIntegers for values? Etc.
    • Do we even need to store the field name (Strings) in the mir StructTypeIF? Currently these are being used to determine equality of two struct types: if the fields names differ, they are considered different types, even if the fields type sequences are the same.
    • ExpressionIF needs to have a method int numOperands. Also, what kind of exceptions should be thrown for bad arguments to methods like getOperand
    • there didn't appear to be any way to create a process local variable.
    • Sam is going to edit the MutableMirIF interface to his liking and let us know when he has done it so we can review it.

VSL Meeting 3/19/08

Present
Moelius, Wei, Xu
Secretary
Moelius
  • There did not seem to be any significant Symbolic package type-related issues to discuss. However, we noted that the Symbolic package takes the view that a ``type'' is a collection of operations, more so than a collection of values. This is evidenced by the fact that Integer and IEEEFloat do not have associated parameters.
  • We agreed that MIR pointer-types should not mention the type of the referenced value. This is to avoid having to introduce names and/or declarations for types in MIR, which would become necessary, e.g., in the context of recursive data-structures. Not having to introduce these things helps to keep the language simple.
  • We agreed that every MIR value should know its type (e.g., be obtainable via a method call). This will be necessary, e.g., in implementing MPI_Recv to ensure that a receive buffer is of appropriate type.
  • We agreed that MIR should have an array type which includes the length of the array. We did not reach a consensus on whether MIR should have an array type which omits the length of the array. Of relevance, are the following questions.
    • For the person writing the Mover evaluation package (i.e., the code that executes a MIR model), what operations might he want to perform on MIR types?
    • What are the role of types in MIR? (As noted above, in the Symbolic package, it is more to denote a collection of operations, than a collection of values.)

VSL Meeting 3/7/2012

Present
Siegel, Zirkel, McClory
Secretary
Siegel