[kepler-users] A few changes

Edward A. Lee eal at eecs.berkeley.edu
Tue Dec 7 17:59:54 PST 2010


All,

I am checking in a few changes, one of which (the LineReader actor)
is not completely backward compatible. Executive summary:

  - Fixed a bug in LineReader (slightly changing behavior)
  - Added CSVReader, which reads comma-separated value files
  - Fixed a bug with OrderedRecordToken.

1) LineReader used to produce output on its endOfFile port
    in its postfire() method. This is incorrect. No actor should
    produce output in postfire(). I've corrected this so that the
    output is produced in fire(). The output will be true in the
    same firing where the last line is produced on the output
    port. Thus, in SDF, you can connect the endOfFile port to
    a Stop actor, and the model will stop executing after
    processing the last line in the file.

2) Added CSVReader, a subclass of LineReader. This actor reads
    comma-separated-value (CSV) files, like those exported from
    Excel. The output is a Record of strings. The first line of
    the file is assumed to be the names of the fields. The actor
    also supports tab and semicolon separators, and in fact any
    separator that you like.

3) Fixed (at least temporarily) a very subtle bug with
    OrderedRecordToken. Specifically, if an OrderedRecordToken
    was inserted into an ArrayToken, then the ordering would
    be lost, and it would become a RecordToken. My fix was to
    modify the convert() method of RecordToken so that if the
    original token is an OrderedRecordToken, then the converted
    one is too. That is, in the Expression Evaluator we used to
    get:

 >> {[a=1, b=2]}
{{a = 1, b = 2}}

    Now we get:

 >> {[a=1, b=2]}
{[a = 1, b = 2]}

    Notice that in the second case the square brackets (which
    indicate an OrderedRecordToken) are preserved, whereas
    in the former case they are turned into curly braces.

The last of these fixes raises a puzzling question.
When Ben Leinfelder created OrderedRecordToken, he did not
modify the type system. That is, to the type system, an
OrderedRecordToken is indistinguishable from a RecordToken.
I'm not sure this is correct...  Thoughts about this?

I have added tests for all of the above.

Edward

-------------- next part --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 330 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20101207/65d1a7c7/attachment.vcf>


More information about the Kepler-users mailing list