Ecoinformatics Redmine: Marten Lohstrohhttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362015-08-14T23:07:28ZEcoinformatics Redmine
Redmine Kepler - Bug #5722: Check for problems with sanitized RecordToken labelshttps://projects.ecoinformatics.org/ecoinfo/issues/5722#change-222392015-08-14T23:07:28ZMarten Lohstrohmarten@eecs.berkeley.edu
<p>Daniel Crawl wrote:</p>
<blockquote>
<p>Derik's test workflow expressionOrderedRecordTokenTest.kar is still failing.</p>
</blockquote>
<p>I reviewed the test case. It contains the following expression:</p>
<pre>
[1Day of Week1 = {"Mon", "Tue"}, 2Rain Fall2 = {3, 7}]
</pre>
<p>Arbitrary strings as labels are allowed, but unless they are valid Java identifiers (and these are not), they must be surrounded by quotation marks.<br />In Ptolemy II (svn trunk), the following expression parses just fine:</p>
<pre>
["1Day of Week1" = {"Mon", "Tue"}, "2Rain Fall2" = {3, 7}]
</pre>
<p>In Kepler 2.4, however, it fails.</p> Kepler - Bug #6629 (Closed): type resolution problem when using RecordAssemblerhttps://projects.ecoinformatics.org/ecoinfo/issues/6629#change-219222015-02-03T10:09:08ZMarten Lohstrohmarten@eecs.berkeley.edu
<p>The arbitrary order in which Mogensen's algorithm resolves type constraints seemed to trigger non-deterministic type errors due to an error in ParseTreeTypeInference.visitMethodCallNode(). Changes were made in revision 71540 and the supplied model now runs without errors.</p> Kepler - 4.00 hours (Bug #6629 (Closed): type resolution problem when using RecordAssembler)https://projects.ecoinformatics.org/ecoinfo/projects/kepler-12/time_entries?issue_id=66292015-02-03T10:09:08ZMarten Lohstrohmarten@eecs.berkeley.eduKepler - Bug #5722: Check for problems with sanitized RecordToken labelshttps://projects.ecoinformatics.org/ecoinfo/issues/5722#change-203872013-04-24T19:55:16ZMarten Lohstrohmarten@eecs.berkeley.edu
<p>Arbitrary string are allowed as record labels as of rev. 66121; the expression language is adapted to make this possible. The change is backward compatible because strings that qualify as valid Java identifiers are still allowed to be used without quoting them e.g., {a=1, b=2} is still accepted, but now {"a"=1, "b "=2} is accepted too. The only thing which should be mentioned that does not extend to the use of arbitrary strings as record labels, is the dot notation to retrieve fields e.g., {a=1,b=2}.a works, but {"a"=1, "b "=2}."b " does not work. This is not a problem because the dot notation is only a shorthand for the get() method, so {"a"=1, "b "=2}.get("b ") works fine. Quotes within quotes must be escaped e.g., {a=1, "b "=2, "_c\"!"=3}.get("_c\"!") yields the value 3.</p>
<p>One additional problem that has been solved is the following: because arbitrary strings include the use of periods, and periods are not allowed in port names (because it makes their identifier ambiguous), therefore RecordAssembler and RecordDisassembler now use the display name of ports (which has no formatting restrictions) to construct their types. Note that the display name is used instead of name only if it is actually defined.</p> Kepler - Bug #5722: Check for problems with sanitized RecordToken labelshttps://projects.ecoinformatics.org/ecoinfo/issues/5722#change-197972013-01-23T23:38:06ZMarten Lohstrohmarten@eecs.berkeley.edu
<p>If certain strings are unacceptable as labels because the parser cannot deal with them, then the only right behavior for records is to reject such labels (as was established by changeset 64633). The problem is that actors like RecordDisassembler and RecordAssembler use a number of complex type constraints that tie port names to labels in RecordTypes. Bluntly renaming labels results in undesired behavior and unexpected typing problems. Because the the sanitation mapping is not invertible, the original port names can no longer function as proper identifiers. E.g., what kind of record should a RecordAssembler with two inputs "a b" and "a_b" produce? And how can RecordDisassembler ensure that its input record has two distinct fields that correspond two its two outputs "c d" and "c_d"? Errors like these would be trapped by RecordType as it requires labels to be unique, but the resulting errors are not very friendly, and the solution as a whole is not very elegant.</p>
<p>If we want to allow record labels that are equally expressive as port names, the expression language needs to be adapted. This is a task that requires some careful thought. I don't have time to look into this right now, but I will look do so by the end of February and come up with a proposal / candidate implementation.</p>