[kepler-dev] NIL token
Christopher Brooks
cxh at eecs.berkeley.edu
Wed Mar 29 13:47:08 PST 2006
Hi Jing,
Thanks for the stack trace. I am tied up with getting Ptolemy II
ready shipping, so time is short. Also, I wanted Edward to see the
stack trace. If I had a small test, I could check it in to the tree.
Yep, I should start up kepler . . .
The problem is that TypeLattice.compare() returning
either CPO.HIGHER or CPO.INCOMPARABLE.
protected void _checkType(Token token) throws IllegalActionException {
int compare = TypeLattice.compare(token.getType(), _resolvedType);
if ((compare == CPO.HIGHER) || (compare == CPO.INCOMPARABLE)) {
throw new IllegalActionException(this,
Line 741: "Run-time type checking failed. Token " + token
+ " with type " + token.getType()
+ " is incompatible with port type: "
+ getType().toString());
}
}
One hack would be to modify the code so that we check to see
if the Token is nil before calling TypeLattice.compare().
This seems a bit brute force and would require changing at least
112 calls to TypeLattice.compare() in the Ptolemy tree.
Another idea would be for each Token to have its own NIL token.
This seems inelegant.
Perhaps the NIL token needs to have a getType() method that returns
something that the type lattice will properly type check. A NIL
token is the univesal token, it can be used anywhere.
Modifying ptolemy.data.Token so it redefines getType might work:
/** A token that represents a missing value.
* Null or missing tokens are common in analytical systems
* like R and SAS where they are used to handle sparsely populated data
* sources. In database parlance, missing tokens are sometimes called
* null tokens. Since null is a Java keyword, we use the term "nil".
* The toString() method on a nil token returns the string "nil".
*/
public static final Token NIL = new Token() {
/** Return the type of this token.
* @return BaseType.UNKNOWN;
*/
public Type getType() {
return BaseType.UNKNOWN;
}
};
However, I think we need to instead add a new type, which is the
type that is specific to NIL. This type is in some ways in
comparable, but operations such as add can be performed on it.
TypeLattice.compare() would need to be modified so if one
of the arguments is the newly defind NIL type, then it returns
ptolemy.graph.CPO.SAME.
This seems like a scary change that could affect performance.
If you can send me a small test case that I can add to the Ptolemy
tree, I can see about hacking something in.
Comments?
_Christopher
--------
Hi, Christopher:
The test workflow is alreay in
kepler/workflows/test/test-eml-missing-value-field.xml. You may run it and
to see what will happen. The stack trace is:
ptolemy.kernel.util.IllegalActionException: Run-time type checking failed.
Token nil with type general is incompatible with port type: double
in .test-eml-missing-value-field.Missing Value.Column2
at ptolemy.actor.TypedIOPort._checkType(TypedIOPort.java:741)
at ptolemy.actor.TypedIOPort.send(TypedIOPort.java:463)
at
org.ecoinformatics.seek.datasource.eml.eml2.Eml200OutputTypeField.fire(Eml2
00OutputTypeField.java:103)
at
org.ecoinformatics.seek.datasource.eml.eml2.Eml200DataSource.fire(Eml200Dat
aSource.java:552)
at ptolemy.actor.AtomicActor.iterate(AtomicActor.java:309)
at
ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.
java:170)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:331)
at ptolemy.actor.Manager.iterate(Manager.java:613)
at ptolemy.actor.Manager.execute(Manager.java:322)
at ptolemy.actor.Manager.run(Manager.java:985)
at ptolemy.actor.Manager$3.run(Manager.java:1026)
Thanks,
Jing
Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101
On Wed, 29 Mar 2006, Christopher Brooks wrote:
> Date: Wed, 29 Mar 2006 11:04:25 -0800
> From: Christopher Brooks <cxh at eecs.berkeley.edu>
> To: Jing Tao <tao at nceas.ucsb.edu>
> Cc: kepler-dev at ecoinformatics.org
> Subject: Re: [kepler-dev] NIL token
>
> Hi Jing,
>
> Good question, I was afraid there might be issues surrounding
> Nil tokens and types. My previous design had nil-ness being a
> property of the token, so we had a DoubleToken that was of
> type double and was nil. Now we have just one token which is nil.
>
> Can you construct a small model that has a similar failure?
>
> Also, what's the stack trace of the current failure?
> Perhaps where the types are being checked needs to be updated to
> handle nilness
>
> _Christopher
>
> --------
>
> hi, Christopher:
>
> According to the changes you made in ptolemy about nil token, I made t
he
> changes in kepler for missing value too.
>
> Since currently we only have one public static variable NIL in Token c
lass
> (NIL is a generic type and there is no any other nil in sub token
> classes), I think every missing value element should be replaced by th
e
> NIL token no matter what the data type it is. But when I run the workf
low
> test, I got some error:
>
> Workflow workflows/test/test-ecogrid-eml-gce-data.xml FAILED:
> [java] ptolemy.kernel.util.IllegalActionException: Run-time type check
ing
> failed. Token nil with type general is
> incompatible with port type: int
>
> So it seems the NIL token is not compatible to int port type. Did I mi
ss
> something? How can I make the NIL token to compatible int port type?
>
> Thanks,
>
> Jing
>
> Jing Tao
> National Center for Ecological
> Analysis and Synthesis (NCEAS)
> 735 State St. Suite 204
> Santa Barbara, CA 93101
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-d
ev
> --------
>
>
--------
More information about the Kepler-dev
mailing list