[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[triquetrum-dev] Triquetrum Status
|
Erwin and I met via Google Hangout, below are some details.
The next call will be on Tuesday, May 17 at 9:30am Pacific. Email me if
you want an invitation and are willing to use Google Plus. If someone
feels strongly, we could try another tool, I'm not wedded to Google
Hangouts.
Today, we prioritized the open CQs with regard to which packages are
fairly stable and which are likely to change. Our intention is to
freeze the CQs at the end of May. If the IP team is at EclipseCon
France in June, then Erwin will meet with them to confirm that the CQs
can be handled by the October 21 release date.
We went through the open issues at
https://github.com/eclipse/triquetrum/issues and added a few to the
Triquetrum Science2016Release milestone (See
https://github.com/eclipse/triquetrum/milestones/Science2016Release). We
created an OxygenMilestone, which is where we can move issues that will
not be addressed in time for the Science 2016 Release in October.
We discussed how to grow the Triquetrum community and our current plan
is to work with the Eclipse Layout Kernel (https://www.eclipse.org/elk/)
group. Erwin will attempt to meet with them at EclipseCon France.
We had a wide ranging conversation about various Eclipse workflow
efforts. My take on this is that there are many tools out there, most
use just one model of computation. An advantage of Ptolemy II is that
discuss how to compose different models of computation. Tool integration
between these tools is not of interest to me, but could be a money maker
for the right company. Tool interchange formats was a research topic
in my department, see the work of Alessandro Pinto. A good overview
from 2005 maybe found at
http://virtualhost.cs.columbia.edu/~luca/research/hybrid_hscc2005.pdf.
The idea of using a tool like ICE to execute different tools is
interesting. A long time ago, we had a model of computation called
"Design Flow Management", which was like a visual make command, where
actors invoked subprocesses that passed file handles around. This sort
of thing could be done with Kahn Process Networks, where each actor is a
separate thread.
_Christopher
--
Christopher Brooks, PMP University of California
Academic Program Manager & Software Engineer US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm Berkeley, CA 94720-1774
cxh@xxxxxxxxxxxxxxxxx, 707.332.0670 (Office: 545Q Cory)
