[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.
Matt
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:
>
>>Christopher,
>> 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.
>>
>>Dan
>>
>>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.
>>>
>>>_Christopher
>>>_______________________________________________
>>>Kepler-dev mailing list
>>>Kepler-dev at ecoinformatics.org
>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>
>>>
>>
>>
>>--
>>*******************************************************************
>>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
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
> ------------
> 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