[kepler-dev] Why I can't work: a plea for stability

Matt Jones jones at nceas.ucsb.edu
Thu Apr 20 19:12:09 PDT 2006

While there are some advantages of the idiosyncratic approach, there are 
also drawbacks.  Kepler has features, such as search across all actors 
and UI configurability, which are neither present in ptolemy not 
possible with ptolemy's current ad-hoc approach to actor management. 
Kepler definitely has some startup problems to overcome, but I am not 
particularly worried as we have discussed a very plausible mechanism to 
bypass the Moml parser altogether for the library and instead load actor 
proxies which will be much lighter weight than the instantiated moml 
components. This will save both time and memory and still allow our 
desired search and validation features.   So the startup speed problems 
will go away.  In terms of our centralised architectural philosophy, 
it'd be interesting to see how hard it will be to localize both Ptolemy 
and Kepler for say 5 or 6 languages, or customize the UI with completely 
different icon sets for different science communities, given the 
centralized versus non-centralized approaches in the 2 builds.  I think 
our centralization of UI configuration and other issues will ultimately 
be a major Kepler strength, not a weakness.  But its a strength because 
issues like localization are important to Kepler but seem to have been 
historically unimportant for ptolemy.

In terms of the build fragility, we've seen that breakage in both the 
kepler and the ptolemy trees is fairly regular -- I'd say its about 
50/50 in terms of whether its the Kepler tree or the ptolemy tree that 
causes a problem at any given time in the Kepler build.  I think the 
ptolemy folks don't see this much because of the effective use of 
autoconf in the ptolemy build, rather than some putatively superior 
coding philosophy.  Autoconf nicely hides many of the build problems and 
dependency problems from most ptolemy contributors.  Kepler would do 
well to emulate that approach.  The bottom line is that the HEAD of the 
development tree for both projects allows significant experimentation. 
I think one area that could be far better in Kepler is in our unit and 
system testing -- having better test coverage would allow experimental 
work to be more easily tested before it is checked in, avoiding these 
breakages in the first place.  Ptolemy does it right in this regard, but 
I think mainly because poor Christopher writes tons of (and the majority 
of) the tests.  Is there any estimate of the % of tests in the ptolemy 
tree written by cxh versus others?

After the Kepler 1.0 release we should seriously work out a new build 
that is more maintainable and less complex for Kepler.  I think 
continued discussions along these lines is profitable, but maybe less 
disruptive after the release.


Edward A. Lee wrote:
> Ptolemy has also gone through periods with many cooks in the kitchen,
> but there are certain strategies that seem to help quite a bit...
> One is to minimize centralized resources.  It seems that the icons
> and search mechanisms in Kepler both went the other way, adding both
> fragility and complexity (resulting in slower startup, for example).
> Perhaps these designs should be revisited?  One of the reasons that Ptolemy
> uses *Icon.xml files, for example, rather than something centralized
> is precisely to enable and encourage experimentation that doesn't
> break things for everyone else.  You can have your own idiosyncratic
> actor library without stepping on anyone's toes...
> Edward
> At 01:19 PM 4/20/2006, Dan Higgins wrote:
>>    I fully agree with your comments. I am worried that Kepler is way
>>too fragile for a project supposedly this near to release. I attribute
>>this to 'too many cooks in the kitchen', but that may just be the cost
>>of a distributed open-source project. In other words, I don't have a
>>good solution for the problem.
>>Christopher Brooks wrote:
>>>I'm not actually upset or anything, but I thought I'd give
>>>you an outsider's perspective.
>>>I'm one of the worst offenders here, since I know I broke the build
>>>yesterday which my diva related changes.  I had things working
>>>in one tree, but was not able to test because of a problem in
>>>my other tree on another machine.
>>>Basically, I thought on my other tree I had broken something
>>>and spend several hours tracking down the problem as being that
>>>some geon actors were removed, but geon.xml was not updated.
>>>It took more time than necessary because I upgraded Eclipse
>>>and did a reinstall of ptII and kepler sources so I could
>>>be sure.  It also took more time because the error message
>>>was a NullPointerException and I had not seen this sort
>>>of error before.
>>>Now, I'm facing problems with Eclipse again?
>>>I'm seeing errors about cipres PAUPInfer class?
>>>It does not build in Eclipse, so I excluded it, and
>>>then I had to remove some files from actors
>>>and then trash ~/.kepler and run ant buildkarlib
>>>I eventually did all that stuff and now I was able to work.
>>>A couple of comments:
>>>1) We all, (me especially) need to be more careful about not breaking
>>>the build and Kepler in general
>>>2) Kepler needs to be restructured so that it does not require the
>>>entire library to be present and working at startup.  Ptolemy II does
>>>this so as to avoid problems like PAUPInfer.  I don't know what this
>>>class does, and since I'm not using it, I shouldn't care.  This would
>>>help start up time.  I think that this might possibly be worth
>>>considering implementing before 1.0.
>>>3) The Eclipse instructions are very complex.  We were never able to
>>>help Sivagowri Swaminathan <sivagowri at hotmail.com> to his or my
>>>satisfaction.  BTW - Under Eclipse 3.2.0 (rc1), with java 1.5.0_06,
>>>the svg icons are not visible for me?  Not sure why.
>>>4) The limitation about being able to run only one Kepler because
>>>of the database is troubling.  I'm running on a shared Windows
>>>server.  If I wanted to use Kepler in a class and have students
>>>run on this server, would I be able to?
>>>Anyway, those are some random thoughts.  As I said, I'm not
>>>at all upset about these issues, and I really enjoy contributing
>>>and collaborating with you all.  I think Kepler is pretty slick,
>>>I like what you've done with Ptolemy and appreciate you putting
>>>up with Ptolemy's (and my) ideosyncracies.
>>>Kepler-dev mailing list
>>>Kepler-dev at ecoinformatics.org
>>Dan Higgins                                  higgins at nceas.ucsb.edu
>>http://www.nceas.ucsb.edu/    Ph: 805-893-5127
>>National Center for Ecological Analysis and Synthesis (NCEAS) Marine 
>>Science Building - Room 3405
>>Santa Barbara, CA 93195
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
> ------------
> Edward A. Lee
> Professor, Chair of the EE Division, Associate Chair of EECS
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

Matt Jones                                   Ph: 907-789-0496
jones at nceas.ucsb.edu                    SIP #: 1-747-626-7082
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara     http://www.nceas.ucsb.edu/ecoinformatics

More information about the Kepler-dev mailing list