https://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362009-04-15T00:56:47ZEcoinformatics RedmineKepler - Bug #3985: Types resolved to unacceptable typeshttps://projects.ecoinformatics.org/ecoinfo/issues/3985?journal_id=134272009-04-15T00:56:47ZOliver Soongsoong@nceas.ucsb.edu
<ul></ul><p>This bug is slightly more fun. Change the SDF Director to allow disconnected graphs, delete the relation, then run it. It should work. Now rehook the actors and now it should run as expected. Save the file, close it, and reopen. The bug is back (or never went away, or the cached data that seems to allow things to work has been cleared, or something similar).</p> Kepler - Bug #3985: Types resolved to unacceptable typeshttps://projects.ecoinformatics.org/ecoinfo/issues/3985?journal_id=134282009-05-04T23:39:03ZChristopher Brookscxh@eecs.berkeley.edu
<ul></ul><p>I downloaded this from<br /><a class="external" href="http://www.nceas.ucsb.edu/~soong/kepler/Unacceptable%20Types%20Problem.xml">http://www.nceas.ucsb.edu/~soong/kepler/Unacceptable%20Types%20Problem.xml</a><br />and am uploading it so that we have a copy with the bug (urls are notorious<br />for changing).</p>
<p>It looks like an R problem. When I run this, I get:</p>
<p>ptolemy.actor.TypeConflictException: Types resolved to unacceptable types in .Unacceptable Types Problem due to the following inequalities:<br /> (ptolemy.actor.TypedIOPort {.Unacceptable Types Problem.RExpression.irisdf}, unknown) <= (ptolemy.actor.TypedIOPort {.Unacceptable Types Problem.RExpression2.irisdf}, unknown)</p>
<pre><code>at ptolemy.actor.TypedCompositeActor.resolveTypes(TypedCompositeActor.java:324)<br /> at ptolemy.actor.Manager.resolveTypes(Manager.java:1058)<br /> at ptolemy.actor.Manager.preinitializeAndResolveTypes(Manager.java:940)<br /> at ptolemy.actor.Manager.initialize(Manager.java:601)<br /> at ptolemy.actor.Manager.execute(Manager.java:338)<br /> at ptolemy.actor.Manager.run(Manager.java:1109)<br /> at ptolemy.actor.Manager$3.run(Manager.java:1150)</code></pre>
<p>If I explicitly set the type of the irisdf port to integer, then the model runs.</p>
<p>I'm not sure if this is a bug, does R actually propagate types?</p> Kepler - Bug #3985: Types resolved to unacceptable typeshttps://projects.ecoinformatics.org/ecoinfo/issues/3985?journal_id=134292009-05-05T16:50:04ZOliver Soongsoong@nceas.ucsb.edu
<ul></ul><p>It seems like the error is thrown before R even runs, in which case it probably wouldn't be a problem with R itself. R does have its own types, which the R actor converts to Ptolemy types. Since the Expression actor also works with undeclared types, there is something in particular about the R actor that the type resolution code doesn't seem to like. Although explicitly specifying the type will work, it's clearly not necessary from a user's perspective (why do Expressions work but RExpressions not) and it imposes constraints on the code users are able to run. This problem doesn't happen every time two R actors are connected, either. I might be able to help more if I knew more about unknown <= unknown, since presumably type = type is allowable.</p>
<p>In playing around a little more, if I set the two port types to int, run the workflow, then set the port types to be blank (unknown?) and change the code to be irisdf <- "1", the token will be converted to a number on output. Setting the output port explicitly to a string will cause another type error that claims the input port is an int type. Ke/Pt is throwing an exception based on outdated information on undeclared types, which is also what the workaround in comment 1 relies upon.</p> Kepler - Bug #3985: Types resolved to unacceptable typeshttps://projects.ecoinformatics.org/ecoinfo/issues/3985?journal_id=134302009-08-12T18:27:28Zben leinfelderleinfelder@nceas.ucsb.edu
<ul></ul><p>from the RExpression actor we won't "know" the type of the port until the R script executes and we're emitting/reading to or from the port.<br />Christopher - <br />Why does the type lattice not allow two ports that are resolved to "unknown" to be connected and the model to be run? Can we change that?</p> Kepler - Bug #3985: Types resolved to unacceptable typeshttps://projects.ecoinformatics.org/ecoinfo/issues/3985?journal_id=134312009-08-12T19:39:02Zben leinfelderleinfelder@nceas.ucsb.edu
<ul></ul><p>Added a check during preinitialize() that will find unknown-to-unknown connections and set the RExpression unknown-typed output port to "general" so that the type check passes.</p> Kepler - Bug #3985: Types resolved to unacceptable typeshttps://projects.ecoinformatics.org/ecoinfo/issues/3985?journal_id=134322013-03-27T21:25:12ZRedmine Admin
<ul></ul><p>Original Bugzilla ID was 3985</p>