Hi Marc,
About updating from Jython 2.2 to 2.5.1, there is
http://bugs.jython.org/issue1814. My comment to that bug was:
BTW - For Kepler/Ptolemy, I changed calls like:
new PyJavaInstance(attribute)
to
PyJavaType.wrapJavaObject(attribute)
I have no idea if this is correct, but the Ptolemy tests passed.
Adding something to the Jython Wiki would be great.
As it stands, the PythonScript actor can import Jython code from a
separate file by having the user edit the text widget in the actor. It
would not be that hard to get that import from a PortParameter. I would
not have time to implement anything like that though, I have deadlines
at the end of November. So, it would be fairly easy to write actors in
Jython.
To me, it sounds like you are proposing porting more of the PythonActor
into Jython. This sees fairly straightforward, but a bit of a mind
bender. Ptolemy II has an execution semantics that expects that actors
implement the Executable interface. Much of the code expects that
TypedCompositeActors contain Actors and the Actors have methods like
preinitialize(), initialize(), fire(), postfire(), wrapup(). These are
all Java interfaces, classes and methods. So, for your actors to be
called, the Java execution engine needs to have a way to call Java code
that then in turn calls the Jython code that you have written. Thus,
I'm not sure if porting more of the PythonActor into Jython would have a
pay off.
Writing Jython that is read by an actor similar to the PythonScript
actor would seem to be fairly straightforward. The Jython user writes
methods in Jython, Ptolemy runs the PythonScript actor that reads those
methods.
An alternative would be to embed the Ptolemy II execution engine in
Jython and make calls from Jython to execute a model. Writing Jython
actors would still need something like PythonScript.
I updated
https://kepler-project.org/developers/reference/python-and-kepler with a
couple of links in the External Resources section that point to third
parties that I believe have interfaced to the C version of Python using
external actors. This is yet another way of doing the job. I'm
resistant to shipping releases with interfaces to C code because of the
complexity in getting JNI or JNA to work on multiple platforms and 32 or
64 bits. However, interfacing to C code does have value sometimes.
Scala looks pretty interesting to me, I've been meaning to look further
into Scala. One side idea I've been thinking of is to generate Scala
from Ptolemy models, but I'm not sure if that is practical.
_Christopher
On 11/5/11 1:54 PM, J. Marc Edwards wrote:
Christopher, Alan, Josh:
OK...this is important enough to me that I wanted to include Alan
Kennedy and Josh Juneau into your response. Christopher, many thanks
for your effort to upgrade Kepler 2.2 to Jython 2.5.2. However, I'd
like to have a little more *_due diligence discussion_* before putting
it to rest.
I'm also pasting below Alan Kennedy's response to my earlier query to
address the Jython 2.2 to 2.5.2 incompatibilities.
My interpretation of Alan's response containing the term
*_"documentation"_* seems to imply less of a problem and more of an
explanation. *_Alan?_*
From this perspective, as a Kepler w/Jython 2.5.2 user, I certainly
need to understand what seemed to be deemed an issue in being able to
upgrade to Jython 2.5.2 due to the backward incompatibility
(particularly as it related to *PyJavaInstance*), to you being able to
fairly easily upgrade after all. Why did you not run into an issue
with *PyJavaInstance* in Jython 2.5.2? *_Are we missing some
functionality that users need to be aware of?_*
_Back to my original intent of Eclipse IDE-based development of actors
in Kepler/Ptolemy using Jython._ In a purely technical context, I am
more comfortable using Jython than I am Java. Based upon my questions
to the Jython User's Group, I suspect that Alan and Josh are rolling
their eyes at this comment! JThis is my primary motivation behind
wanting to standardize on developing Python actors in Jython for
Kepler. My company, Nimbis Services, is also standardizing on the
Jython Django web framework, and we're thinking very hard about when
we will begin a full evaluation of Scala (a JVM functional programming
language).
I am thinking that all I need to do is to take the Ptolemy PythonActor
source code and take a look at the Java code for that actor and recode
the actor in Jython (Let's call this new actor JythonActor) from
within Eclipse. I'd like a suggestion from Josh or Alan regarding
architecturally how they would address the following issue:
Using a Jython package, or function call, or interface (probably not
applicable in Jython), have the newly coded JythonActor call the
externally developed "functional core" of the Python script that would
effectively "customize" the PythonActor according to the Jython
script's behavior. This way I would only develop my Jython script
packages and then integrate these into the newly coded JythonActor
through say a port parameter. Better yet, how about some sort of XML
import solution that would identify the Jython code that "decorates"
the JythonActor's functionality. I need a good suggestion on how to
do this elegantly such that it looks like someone with serious
programming skills thought it through and not kluge code from a chip
designer.
At present, the PythonActor solution is not integrated into the full
functional Eclipse-based JVM flow due to the Java implementation. I
have become far too reliant upon debugging my Jython code through the
Eclipse IDE and the interpretive nature of Jython to not have this
working flawlessly.
Please let me know what each you think of my JythonActor approach.
Alan, Josh...Christopher is particularly interested in addressing
Jython licensing issues. I get the gist of what he is after here, but
I have simply not been part of any of this, so I have to defer to kind
attention on this subject.
Kind regards, Marc
------------------------------------------------------------------------
*[J. Marc]*
*> OK...please connect me with one of the Jython 2.2 to 2.5
developers. I *
*> will then work with them to determine how we could most effectively *
*> migrate Kepler 2.2 from Jython 2.2 to Jython 2.5.2.*
*>*
*> I will be working with one of the Kepler/Ptolemy II developers on
this *
*> migration.*
**
*This issue with PyJavaInstance when upgrading from 2.2 to 2.5 seems
to be a common enough issue that it requires documentation.*
**
*I'm not going to get to it immediately myself, so I've created an
issue on the issue tracker for it, if anyone feels like taking that up.*
**
*http://bugs.jython.org/issue1814*
**
*Regards,*
**
*Alan.*
------------------------------------------------------------------------
_J. Marc Edwards, Lead Architect_
/Semiconductor Design Portals/
*Nimbis Services, Inc.*
Cell - (919) 345-1021
Fax - (919) 882-8602
Skype - (919) 747-3775
jmarcedwa...@gmail.com
marc.edwa...@nimbisservices.com
*From:*Christopher Brooks [mailto:c...@eecs.berkeley.edu]
*Sent:* Saturday, November 05, 2011 2:59 PM
*To:* marc.edwa...@nimbisservices.com
*Cc:* J. Marc Edwards; kepler-users@kepler-project.org
*Subject:* Re: [kepler-users] Python execution within the Kepler
Python actor...
Hi Marc,
I updated Jython to 2.5.2, it was not that hard, updating the license
files took the most time.
I have a few of misgivings about Jython that might be good lessons for
Ptolemy and Kepler:
* Sadly, ptII/lib/jython.jar went from about 1Mb to 10Mb. Does this
mean that Jython-2.5.2 is 10 times better than Jython-2.2.1?
If jython is supposed to be a scripting language, then why is it so large?
This seems to be a common trend where nice small languages get more
and more features.
As an aside about Perl, see
Is Perl Better Than a Randomly Generated Programming Language? at
http://developers.slashdot.org/story/11/10/27/213231/is-perl-better-than-a-randomly-generated-programming-language
For comparison purposes, Ptolemy's ptsupport.jar is 3.5Mb and a
standalone Ptolemy demo including the GUI is 6.5Mb in jars.
Lesson: we need to keep an eye on code bloat and be able to deploy
small run times.
* Another issue with Jython-2.5.2 is that because they removed
org.python.core.PyJavaInstance some time after Jython-2.2.1, they
should have released Jython-2.5.2 as Jython-3.x. Most projects bump
up the major version number when there are incompatibilities.
Lesson: Ptolemy bumps up the major version number with each ~yearly
release. Ptolemy has backward compatibility filters. We do sometimes
remove old code, but only with major versions.
* The Jython license situation is a mess.
http://www.jython.org/license.html lists these licenses
- The Python Software Foundation License Version 2, which according to
Wikipedia is a BSD-style license
- The Jython-2.0 and 2.1 license, which is similar to a BSD-style license
- The JPython 1.1.x license, which is similar to BSD-style license
The software ships with these licenses in the LICENSE.txt file.
However, LICENSE_CPython.txt and LICENSE_Apache.txt are included.
There is no mention as to what code actually uses those licenses.
LICENSE_CPython.txt includes four copyrights:
- Python Software Foundation License Version 2
- BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
- CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
- CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2
The last three look similar to BSD, but have various requirements.
I'll submit a bug report to Jython to get them to update their site.
Lesson: I'm not sure how Ptolemy and Kepler can avoid a similar
complexity issue. I've been working on updating our license file and
we have a way to determine what licenses are used by a particular
configuration.
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII8.0/copyright.htm
lists 7 licenses used by Ptiny, a small configuration of Ptolemy II.
One of those 7 is the Jython-2.2.1 license, which is similar to the
Jython-2.5.2 license.
The Kepler configuration of Ptolemy II uses 15 licenses in the Ptolemy
II code.
_Christopher
On 11/5/11 9:15 AM, J. Marc Edwards wrote:
Christopher:
I suspect that I can simply code an entire actor extending the
respective classes directly in Jython.
That is what I am thinking. Please let me know what you think of this
strategy.
Of course, while I do this, I want to migrate a Kepler development
tree to use Jython 2.5.2, which I will need your assistance in completing.
Let's talk on the phone on Monday.
Regards, Marc
_J. Marc Edwards, Lead Architect_
/Semiconductor Design Portals/
*Nimbis Services, Inc.*
Cell - (919) 345-1021
Fax - (919) 882-8602
Skype - (919) 747-3775
jmarcedwa...@gmail.com <mailto:jmarcedwa...@gmail.com>
marc.edwa...@nimbisservices.com <mailto:marc.edwa...@nimbisservices.com>
*From:*Christopher Brooks [mailto:c...@eecs.berkeley.edu]
*Sent:* Friday, November 04, 2011 9:00 PM
*To:* marc.edwa...@nimbisservices.com
<mailto:marc.edwa...@nimbisservices.com>
*Cc:* kepler-users@kepler-project.org
<mailto:kepler-users@kepler-project.org>
*Subject:* Re: [kepler-users] Python execution within the Kepler
Python actor...
Hi Marc,
On 11/4/11 2:09 PM, J. Marc Edwards wrote:
I need a little help in integrating my Jython/Python code into the
Python actor.
When I double-click on the Python actor in the PythonDialogExample, a
window with the Python code appears. I can of course edit the code
from within this window. However, I want to perform my code
development and editing from within my Eclipse environment from my
Kepler development build.
I don't know that much about Python, but I believe that you could use
the Python import facility to find imports.
I just added text to the Kepler Jython page about this, see:
https://kepler-project.org/developers/reference/python-and-kepler#how-jython-finds-imports
Note that I found a few other references on the web, included what
appears to be people who are using the full version of Python (not
Jython) with Kepler.
When I "open the actor", the beginning of the file has some Javadoc as
well as what appear to be some unmatched XML elements (<p>), along
with some matching XML element tags (</pre>) (does this correspond to
some pre-fire method?).
When you open the actor, you are seeing the Java code that implements
the PythonActor. The <p> tags are html tags used in the javadoc
comments of the Java file. All of the instances of the PythonActor
share the same Java code, but may have different Python code.
After this all of the Java code for the actor follows with the
standard initialize(), stop(), stopFire(), preinitialize(),
terminate(), etc, methods.
I do see in the Java code where there is a PythonScript method that
accepts a CompositeEntity where a script template is provided where I
am supposing a long Python string in the script.setExpression is defined.
However, what I would like to do is simply include my Jython module
within my Kepler build and debug my Jython code in connection with my
overall workflow.
Can someone tell me how to go about achieving this objective?
It looks like Jython uses sys.path to find imports. I included a
Ptolemy II model that opens in the devel version of Kepler that lists
the contents of sys.path. For further information about sys.path, see
http://jythonpodcast.hostjava.net/jythonbook/en/1.0/ModulesPackages.html
_Christopher
Thanks, Marc
--
J. Marc Edwards
Lead Architect - Semiconductor Design Portals
Nimbis Services, Inc.
Skype: (919) 747-3775
Cell: (919) 345-1021
Fax: (919) 882-8602
marc.edwa...@nimbisservices.com <mailto:marc.edwa...@nimbisservices.com>
www.nimbisservices.com <http://www.nimbisservices.com>
_______________________________________________
Kepler-users mailing list
Kepler-users@kepler-project.org <mailto:Kepler-users@kepler-project.org>
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
--
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
--
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
--
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
_______________________________________________
Kepler-users mailing list
Kepler-users@kepler-project.org
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
