The core of ptII is BSD 3-clause. Over the time,
so other packages have crept in to the ptiny
configuration, though they are not required to run
a small version of ptolemy.
There are a couple of minor licensing issues that
would need to be addressed.
The short answer is that
the Ptiny configuration, run by running $PTII/bin/vergil
-ptiny or by running the Mac OS X Ptiny.app
or by running the Windows "vergil -ptiny"
executable uses only the Ptolemy copyright
above, AElfred, Audio, BrowserLauncher, Colt , ExtensionFileFilter, Matlab _expression_ Actor
and Jython. Audio, Colt,
Matlab _expression_ actor and Jython are all used
by actors specific to those packages.
AElfred is not BSD-3, it has a somewhat custom
license, see http://saxon.sourceforge.net/aelfred.html.
AElfred is used for parsing and would be hard to
avoid. The ptII repo includes a copy of AElfred.
This would be the biggest issue.
Audio, Colt, Matlab _expression_ actor and Jython
are used by actors and not required at runtime and
are not an issue.
BrowserLauncher is used to open a web browser and
could be avoided - not an issue.
ExtensionFileFilter is trivial and could be
avoided - not an issue.
Right, sorry about the misstep about
openness. Over time my works seems to
have moved away from newsgroups and large
public mailing lists to smaller lists with
smaller communities. I'm fine with having
the conversation be public.
The control issue is not a huge issue, and
it certainly has come up in the past.
Just something to watch for is all.
Part of my email really was about reusing
the code in the ptII core. These would be
the classes in the kernel, actor,
actor.lib and other packages. We don't
have to reuse this code, but making these
classes available could be a win. The
issue is that proving that the code is not
encumbered and getting assignments of
copyright could be tricky, but is doable.
I'll post to the forum momentarily.
_Christopher
On 6/9/15 8:39 AM, Jay Jay Billings
wrote:
Christopher,
Thanks for the letter. Its great
to meet you. I went ahead and
CC'ed the Science Working Group
list on this since it has turned
into a technical discussion.
Setting up meetings is OK to do in
private, but we need to keep
technical discussions in the open.
I absolutely love the name
Triquetrum. I'm an astrophysicist,
so I know it well.
I am very glad to hear that you
are joining the Foundation. That
is really great.
I wanted to address the issues of
openness and access that you bring
up. First, Eclipse projects are
required to use the Eclipse
infrastructure, even from the the
very beginning, and to have all
lists, forums, and bug reports out
in the open. Repositories can be
on either Eclipse.org servers or
Github and most new projects are
using the latter. Private
communication can happen of
course, but the largest part of
the discussion must be public. We
will find a very cold reception
from the community if we are not
open.
As far as access to the code goes,
the only people who will have commit
privileges will be people working on
the project, which will most likely
be only the people on this list. All
contributions from other sources
will have to pass through a
contribution mechanism such as a
pull request or bug report, which
requires review by committers and
the IP team. So, I wouldn't worry
about updates to the core from the
perspective of outside developers.
Actual project committers might
change things in the code
contributed from Ptolemy, - 'Ptolemy
core' - but that's their job. Most
likely we will have our own parts of
the project - even our own
high-level cores - that we are
developing though. For example, I
most likely won't be working on any
pieces of Triquetrum contributed
from Ptolemy because ICE doesn't use
them and I don't know how they work;
I'll be working on the service layer
and any workflow components above it
that directly relate to ICE, like
our Item and ItemManager
infrastructure if I add that as part
of the initial contribution.
I was very interested in the last
part of your email about the
different pieces of Ptolemy and how
it works. I think it will be easier
to list these components of the
initial contribution and others on
our Forum, so I started a thread. (I
personally have trouble reviewing
this kind of thing over email.)
June 18th,
17:00 GMT would work for me.
14:00 is a little early, but
doable if necessary.
Let me know if you want me to
host the call. We have
ReadyTalk, which provided toll
free numbers and app sharing
if we want it.
A quick introduction about me
might be helpful: I'm a
software engineer, I've worked
on Ptolemy II for many years.
I've met Erwin and Matt in
person. I'm hoping to see the
Ptolemy code evolve and be
useful in the future, so
having an Eclipse project
seems like a good idea. One
of my minor concerns is about
control over making changes to
the core. The core has not
changed that much over the
years, but it has evolved.
We've worked hard to keep
backward compatibility and
have a good test suite, so the
changes have been fairly easy
to manage. However, we see
Ptolemy II as a research
laboratory and sometimes it is
necessary to make changes.
We've rarely had branches and
strongly encourage the head to
always be working.
Edward is the primary author
of Ptolemy II and actively
involved in the day-to-day
development. Edward is taking
a year long sabbatical to work
on software, but he has
encouraged me to represent him
in this effort while keeping
him in the loop. Edward and I
both use Eclipse as a software
development tool, though we
have not done much coding
using Eclipse classes.
A few words/a reminder about
the triquetrum might be in
order. The triquetrum is the
device the Mr. Ptolemy is
holding below. The triquetrum
is an instrument for
astronomical observations, it
predates the astrolabe. I
like the idea of the
triquetrum because it reminds
me of model-view-controller.
The short name "triq" is
fairly unique and could be
used for a product. The name
evokes the tricycle, which
could be bad, but I don't
mind. Edward owns have http://triquetrum.org.
We are offering this name for
use for this project.
I can also host a mailing list
if we want that. We could
either use the triquetrum list
I have set up or we could
start another list. I see the
value in not having a list
because it is more apparent
who is getting the email. I
have websites that allow me to
set up a wiki as well. I'm
guessing we can eventually use
something at the Eclipse site,
but if we want non-public
infrastructure, I can provide
it.
I submitted the Eclipse
Membership agreement to the
University of California
Business Contracts for us to
join the Eclipse project.
This could take many months to
complete. If necessary, I
could join as an individual.
In Ptolemy II, we have the
notion of configurations. The
Ptiny configuration is a
small, useful configuration
with a minimum of third party
licenses. Ptiny includes the
kernel, common polymorphic
actors, common models of
computation and Vergil, the
UI. Vergil is AWT and is what
we are looking at replacing
with something that is more
based on Eclipse.
The Ptolemy II source code is
primarily BSD, so contributing
it should not be that
difficult. We've done a
reasonably good job managing
the licenses, the dependencies
in the core are fairly
straightforward. A tricky
part could be tracking down
certain contributors and
getting an assignment of
copyright. Fortunately, the
core is fairly stable and not
that many people have worked
on it.
Hallvard Trætteberg created
some OSGi modules that use the
core Ptolemy II classes. One
issue that we ran in to is
that Ptolemy II uses the class
path to add actors, thus we
don't always know in advance
the class names of all the
actors that are to be used in
a system. I believe that this
is a bit contrary to how OSGi
works, where OSGi expects to
know all the dependencies in
advance. There are
workarounds to this though.
_Christopher
On 6/9/15 4:56 AM,
Erwin de Ley wrote:
Great, thanks Jay.
We can/should indeed
discuss the
relationship with ICE
and SAW (and the DAWN
workbench?).
I was thinking to
include this under
"expectations"/requirements
in a second call.
The first call could
focus on the global
ideas as
needed/relevant to
have a good project
proposal and how that
fits in the Science
IWG.
But the more info we
have from the start,
the better!
cheers
erwin
Jay Jay Billings
schreef op 09/06/2015
om 13:15:
Erwin,
That time
works for me.
It would
also be useful to
discuss the
relationship of this
project to ICE since
I see ICE as one of
its clients. We
should also add an
item to the agenda
to review Sandia's
requirements with
SAW.
First of all let
me introduce
Prof. Edward Lee
and Christopher
Brooks, from UC
Berkeley.
They are the
project leads of
the Ptolemy II
framework, which
we've been using
for many years
now in
Passerelle, and
which will also
be integrated in
Triquetrum.
They will also
be involved in
Triquetrum (in
fact they even
"donated" the
project name!),
for which I want
to thank them!
Based on the
previous
email-exchanges,
it would seem
that we should
plan our first
call on
Thursday, June
18th.
I could be
available either
around 14h or
17h UTC/GMT with
a preference for
17h.
Can you check if
this is feasible
for (most of)
you?
The agenda could
be :
- quick intro of
everyone
- overview of
the project
proposal and the
three proposed
lines of work in
triquetrum
- position of
the project in
the Science IWG,
interactions
with e.g.
dawnsci and viz
- some initial
technical and
design
choices/constraints
- initial code
drop
In a second
call, after
everyone has had
some time for
reflection, I
would like to
discuss
contributions,
roles,
expectations.
Please don't
hesitate if you
have any
remarks/suggestions/...
--
Met
vriendelijke
groeten - Bien
à vous - Kind
regards
Erwin
De Ley
iSencia
Belgium
Voorhavenlaan
31 bus 11
B-9000
Gent
www.isencia.be
--
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)
--
Jay Jay Billings
Oak Ridge National
Laboratory
Twitter Handle:
@jayjaybillings
--
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)
--
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)
--
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)