Create a CapeCode Triquetrum product

[cxbrooks]

The Ptolemy group at Berkeley are developing Cape Code, which uses Accessors as proxies to interact with the IoT.

CapeCode uses Ptolemy II, which has the notion of configurations that presents to the user different sets of actors and other features.

It would be helpful if we could have a CapeCode configuration in Triquetrum. This would probably be a separate product that included a separate palette.

In Ptolemy II, the CapeCode configuration may be found in ptII/ptolemy/configs/capecode/.

CapeCode uses Nashorn, so Java 1.8 would be required.

Currently, to make this work, we would need to create a set of jar files that contain the Ptolemy classes.

The UI would need to be extended so that we have things like:

• Hierarchical models
• Hierarchical actor palettes
• Support for dragging in attributes
  • Textual Annotations in the model

[cxbrooks]

This is on hold because we need to use OSGi bundles for the PtII code because we are depending on bundle activation. The Tycho build uses a non-OSGi bundles for the PtII code because Tycho can only access bundles in Software Sites.

http://www.vogella.com/tutorials/EclipseTycho/article.html#tychotargetplatform says:

Tycho only supports Software Sites as locations. Directory, Installation and Feature are not supported and are ignored by the build process.

[cxbrooks]

Now that Erwin has fixed up the Triqiuetrum build using Tycho, we can build RCP images, so supporting CapeCode can proceed.

To get a list of which jar files are used by CapeCode

cd $PTII
make echo_jars JARS=CAPECODE_JNLP_JARS | grep .jar | awk -F \" '{print $2}' | sort | uniq | sed 's@../dists/ptII11.0.devel/jar_dist/@@'

See capecodeJars.txt

The list of packages that are used by the StockTick demo can be found by doing:

export JAVAFLAGS=-verbose
$PTII/bin/vergil $PTII/org/terraswarm/accessor/demo/StockTick/StockTick.xml >& /tmp/classes.txt
grep 'Loaded ' /tmp/classes.txt | awk '{print $2}' | sort | uniq | awk -F . '{ for(i=1;i<NF;i++) printf("%s.", $i); printf("\n")}' | sort | uniq > ~/tmp/packages.txt

See capecodePackages.txt

[cxbrooks]

Note that Cape Code is not a blocker for the Triquetrum First Release: 21st October 2016 #71

At first, because it would take awhile to get the CQs done, the Cape Code sources will not be checked in to the Eclipse Repo.

[cxbrooks]

One issue here is that the Cape Code configuration consists of a multiple Accessors, where each Accessor is an instance of org.terraswarm.accessor.jjs.JSAccessor, but has different values for the script parameter. It is not clear to me how we would create an Actor bundle that will support this.

http://wiki.eclipse.org/Triquetrum/Extending_Triquetrum#Creating_an_actor_bundle describes how to create an actor bundle where each actor is implemented by a Java class.

However, in Cape Code, we have multiple actors that each implement org.terraswarm.accessor.jjs.JSAccessor.

BTW - When $PTII/bin/vergil -capecode is run, there is an Accessors node in the actor tree view. When that node is opened, org/terraswarm/accessor/AccessorLibrary.java gets https://www.terraswarm.org/accessors/index.json which contains:

[
    "audio",
    "cameras",
    "devices",
    "gdp",
    "image",
    "net",
    "robotics",
    "geodesy",
    "services",
    "signals",
    "test",
    "utilities"
]

Each of the elements represents a directory, so https://www.terraswarm.org/accessors/audio/index.json is opened, which contains:

[
    "AudioCapture.js",
    "AudioPlayer.js",
    "ClipPlayer.js"
]

https://www.terraswarm.org/accessors/audio/AudioCapture.js is opened and passed to the accessorToMoML() method in org/terraswarm/accessor/JSAccessor.java, which returns MoML that looks like

<entity name="AudioCapture" class="org.terraswarm.accessor.jjs.JSAccessor">
  <property name="accessorSource" value="https://www.terraswarm.org/accessors/audio/AudioCapture.js"/>
  <input source="file:/Users/cxh/ptII/org/terraswarm/accessor/accessors/web/audio/AudioCapturePtDoc.xml"/>
  <property name="script" value="..."
  <property name="_tableauFactory" class="ptolemy.vergil.toolbox.TextEditorTableauFactory">
    <property name="attributeName" value="script"/>
    <property name="syntaxStyle" value="text/javascript"/>
  </property>
  <property name="script">
    <property name="style" class="ptolemy.actor.gui.style.NoteStyle">
      <property name="note" value="NOTE: To see the script, invoke Open Actor"/>
    </property>
  </property>
</entity>

So, what we need to do is modify the bundle activator to do the above access of the index.json files and instantiation.

[erwindl0]

Christopher, could you send me a concrete example of the capecode configuration of some accessors?

I think what you need is to be able to add multiple entries in the palette definition, based on a same underlying actor Java class, each with some different parameters/properties. And this is already possible in theory in Triquetrum. I.e. we can set properties on actors in the palette. But this has not yet been used/proven and may not be sufficient.

I looked around in ptII/ptolemy/configs/capecode/ but it seems the real accessor configuration info should come from :

<!-- Standard TerraSwarm accessors. -->
<entity name="Accessors" class="org.terraswarm.accessor.AccessorLibrary">
  <configure source="https://www.terraswarm.org/accessors"/>
</entity>

and I could not see the XML there that could show how an accessor actor is defined in a capecode configuration.

Or is this done based on what you describe above, i.e. there's some js/json files that get transformed by the JSAccessor actor code itself?

If the last part of your comment means that the palette is not known/defined upfront in a Vergil configuration, but is generated on the fly each time, reading the json/js file on the terraswarm URL, I can see several issues :

• What happens when you're working off-line? Can you only design capecode models when being on-line?
• Triquetrum does not support dynamically changing palettes yet. This should be technically feasible, but won't be available before Tuesday, the deadline for the newsletter...
• What is the "input" element for in the MOML fragment above? Is that only needed to include a help document for the actor? (which we don't support yet anyway in Triquetrum)

[cxbrooks]

Here's a zip file of the configuration. I created it by editing ptolemy/configs/test/configTest.tcl:

bash-3.2$ svn diff ptolemy/configs/test/configTest.tcl
Index: ptolemy/configs/test/configTest.tcl
===================================================================
--- ptolemy/configs/test/configTest.tcl (revision 75383)
+++ ptolemy/configs/test/configTest.tcl (working copy)
@@ -47,7 +47,7 @@

     set loader [[$parser getClass] getClassLoader]

-set URL [$loader getResource ptolemy/configs/ptiny/configuration.xml]
+set URL [$loader getResource ptolemy/configs/capecode/configuration.xml]
 puts "Checking [$URL toString]"
 set object [$parser {parse java.net.URL java.net.URL} $URL $URL]
 set configuration [java::cast ptolemy.kernel.CompositeEntity $object]
@@ -57,5 +57,7 @@
 set results [[java::cast ptolemy.actor.gui.Configuration $configuration] check]
 puts $results

+puts [$configuration exportMoML]
+
 # The list of filters is static, so we reset it
 java::call ptolemy.moml.MoMLParser setMoMLFilters [java::null]
bash-3.2$ 

and then running

$PTII/bin/ptjacl configTest.tcl >& ~/tmp/capeCodeConfiguration.xml

and then editing that file and removing some text from the beginning.

Here's the file:

capeCodeConfiguration.xml.zip

Below are some answers to your questions:

In Vergil, the palette is created when the Accessors tab in the actor palette is opened. Vergil has lazy evaluation of the elements in the actor palette. This means that startup is fast and if there are problems with a set of actors, they don't cause problems until you try to use them. If you search the actors for an actor by name, then each set of actors is opened as the search proceeds.

If you are working offline, then Cape Code looks in $PTII/org/terraswarm/accessor/accessors/web for the accessors. In fact, it looks there first and then looks at the website.

How the AccessorLibrary class works is that it looks for a index.json file that names directories that contain index.json files. These second-level index.json files name .js files that define the accessors. The accessor .js files are read in and then converted to MoML, which is then parsed and added to the configuration. I think we will want the bundle activator to do this parsing for us.

The input element causes the MoMLParser to read input from a file as if the contents of that file were present in the MoML.

Not getting this done by Tuesday is not a problem. I'm on holiday today.

In other news, I added org.terraswarm.accessor to osgi-2-0/. When I run mvn clean verify, the build fails for the following reasons.

1. The version of ptolemy.data.expr.Constants in osgi-2-0 is missing the nameToType(type) method. We need to figure out a policy about how to update existing files in the Ptolemy II bundles that have passed IP CQ. I propose that we bump the version numbers,make changes and then submit the changes to IPCQ. We need to refine and document how this is done.
2. io.vertx.core.AbstractVerticle is not found. This code uses Vert.x, I need to figure out how to require it in pom.xml
3. ptolemy.data.ImageToken and ptolemy.util.StringBufferExec are not present. We should consider adding these files to the bundles.

My idea is to get the above to compile and then work on the activator. I'm not going to get much done today.

[erwindl0]

I have a first hacked-together result, combining the triquetrum branch #189 with a capecode palette provider in https://github.com/erwindl0/triquetrum-capecode, a set of 3rdparty deps like jackson and netty and local hacks in ptII code...

The palette provider adds the BaseA.js test accessor to the Triquetrum palette.

Main purpose is to try to understand what it takes, the code or workspace setup is not OK at all for real usage.

Besides updating some ptII classes (as mentioned previously by Christopher as well), I see following issues that must be addressed, both in ptII Java code and in JavaScript files (at least these are things I am aware of at this moment, we may discover more...) :

Things that are not compatible with OSGi-based modularity :

• usage of $CLASSPATH in file/resource/module lookup code
• loading JavaScript and JSON files with locations relative to specific Java classes in the ptII package
• maintaining accessor/node modules in a single aggregated tree

I copied the files on some fixed local paths and changed the lookup code in some places to point there i.o. using $CLASSPATH-relative paths etc.

Triquetrum-specific issues for CapeCode :

• I have the impression that the BaseA accessor does not automatically get its extra inputs from the JavaScript :
  exports.setup = function () { this.input('in1'); console.log('base set up'); }
  Should the BaseA accessor get an 'in1' input port? For the moment it only has a 'script' input port and an 'error' output port. Is there some actor lifecycle method to invoke before rendering it in the editor?