<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Beth Latronico asked me to forward on the following about this
issue.<br>
<br>
Beth writes:<br>
<blockquote type="cite">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We
ran into a similar problem trying to build an actor which
reads information in JSON from a web page and outputs a
RecordToken. Here’s a summary of the discussion and a sample
model in case this is helpful for your situation!<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Actor:
ptolemy.actor.lib.conversions.JSONToRecord<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Test
model:
ptolemy.actor.lib.conversions.test.auto.JSONToRecord1.xml<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ideally
we wanted to be able to set the type of the output to a
RecordType including all of the fields and types of those
fields (vs. an empty Record), so that we could use the
RecordDisassembler. However, since the type solver only runs
once and runs during preinitialize(), this means we need to
get the type information somehow ahead of time, and that the
type signature cannot change during execution. (It’s OK if
the data changes). <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">For
some web data streams, this seems OK – the type signature is
always the same – so we pull some sample data in
preinitialize() to determine the type, and then check the type
signature in fire() to make sure it has not changed. This
assumes that we know the URL of the data source, the URL
remains fixed and that sample data is available before the
model executes.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">For
other web data streams, the type signature changes. Here we
currently set the output port type to an empty record so at
least the type solver knows it’s a record, but then we can’t
connect this output to a RecordDisassembler – it would throw
an exception when the model is executed. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Token
value = new RecordToken();<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">output.setTypeEquals(value.getType());<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So,
we’re debating on whether 1) these two cases should be split
into different actors, and 2) if it’s appropriate to use
RecordDisassembler or should we create some new actors that
can handle loosely-typed records.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Also
like you mentioned for objects, JSON is fairly close to a
Ptolemy record, but like Java types, the JSON types are not
exactly the same as Ptolemy types. (For example, it looks
possible that JSON arrays could contain mixed types in the
same array). We don’t have a good solution for that yet…
right now we are just extracting Ptolemy types and hoping for
the best. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Unfortunately
there are more questions than answers at the moment, but hope
the discussion highlights some of the issues!<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Best,<o:p></o:p></span></p>
<span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Beth</span></blockquote>
Marten Lohstroh suggested that we could have a flag that when set
required strict typing. Certain actors could record the type
information in a manner similar to how the Test actor works. The
Test actor has a shared parameter called "trainingMode". When
trainingMode is true, the known good results of the TestActor is
recorded. In a similar manner, certain actors could record the type
information when trainingMode was set to true.<br>
<br>
<br>
_Christopher<br>
<br>
On 4/2/12 6:05 PM, Edward A. Lee wrote:
<blockquote cite="mid:4F7A4CF4.2050006@eecs.berkeley.edu"
type="cite">
<br>
Ptolemy II is statically typed, so after a model is
preinitialized,
<br>
the types of all ports must be known. The type system is described
in
<br>
chapter 5 of this document:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-29.html">http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-29.html</a>
<br>
<br>
and also in this paper:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://chess.eecs.berkeley.edu/pubs/665.html">http://chess.eecs.berkeley.edu/pubs/665.html</a>
<br>
<br>
For Record types, the most general record type is the empty record
type.
<br>
That is, a record type {fieldName = double}, for example, is also
<br>
an instance of {}, the empty record type. Moreover, a record of
<br>
type {a = int, b = double} is also an instance of {a = int}.
<br>
<br>
So, for example, if you know that your output record will contain
<br>
a field named "a" of type "int", then you can force the output
type
<br>
to be {a = int} (right click on the actor, select Configure Ports,
<br>
and enter "{a = int}" in the type field). As long as there is
actually
<br>
such a field, in the record, this will work. But if you run the
model
<br>
and there is no such field, I believe you will get a run-time type
<br>
error (which is probably what you want).
<br>
<br>
Edward
<br>
<br>
<br>
On 4/2/12 1:51 PM, Hogan, D. (GE Energy) wrote:
<br>
<blockquote type="cite">I have an actor that uses the structure of
a file generated at runtime
<br>
to create an output record. The actor is working, but I have a
few
<br>
questions on ObjectToRecord since it is similar.
<br>
<br>
In ObjectToRecord, it does not change the type and lists it as
fixme.
<br>
The documentation for RecordType mentions using
setTypeAtMost(new
<br>
RecordType(new String[0], new Type[0])) when you want to specify
a
<br>
record without specifying the fields. Should I use that? Is
there a
<br>
better way to specify it is a record and the field names/types
are
<br>
discovered at runtime? Since unknown matches that type
constraint, what
<br>
is the best way to handle this?
<br>
<br>
ObjectToRecord doesn't try to convert between standard Java
types and
<br>
Ptolemy types. I noticed there is a
<br>
ptolemy.data.expr.ConversionUtilities, but it looks limited to
the
<br>
expression language needs. Is there another conversion in
Kepler?
<br>
<br>
_______________________________________________
<br>
Kepler-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kepler-dev@kepler-project.org">Kepler-dev@kepler-project.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev">http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev</a>
<br>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Christopher Brooks, PMP University of California
CHESS Executive Director US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774
ph: 510.643.9841 (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670 </pre>
</body>
</html>