[kepler-users] A few changes

[Edward A. Lee]

Hi Ben,

I'm inclined to think that we should just replace RecordToken with 
OrderedRecordToken. In theory, this change is valid, since RecordToken
makes no assurance of any order (not even natural order).

The downside of this is that merging two records becomes much more
complicated. The RecordUpdater actor, for example, would need to
be able to control the order...

Edward


On 12/7/10 6:25 PM, ben leinfelder wrote:
> Hi Edward,
> I know we discussed this a bit in terms of comparing RecordTokens with OrderedRecordTokens but I don't believe it was completely resolved. The motivation behind OrderedRecordToken was to preserve a given order of the labels rather than having them [re]ordered naturally. (Perhaps reading a tabular CSV file (your change #2) into OrderedRecordTokens illustrates the utility of maintaining that column order?). I believe an OrderedRecordToken can only be considered a RecordToken if the former happens to have it's labels in natural order, otherwise they are not equivalent. Preserving the label order when OrderedRecordTokens are contained in an ArrayToken seems entirely appropriate. I haven't looked at your change, but shouldn't the convert() method in OrderedRecordToken be responsible for this behavior rather than the method in RecordToken? I seem to recall being able to keep RecordToken from explicitly referencing OrderedRecordToken - a coup for OO/inheritance.
> Thanks for catching that!
> -ben
>
> On Dec 7, 2010, at 5:59 PM, Edward A. Lee wrote:
>
>>
>> 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
>>
>> <eal.vcf>_______________________________________________
>> Kepler-users mailing list
>> Kepler-users at kepler-project.org
>> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
-------------- 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/20101209/bfa1a67c/attachment.vcf>