[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