[kepler-dev] planned kepler-1.0.0alpha5 release

Edward A. Lee eal at eecs.berkeley.edu
Wed Feb 23 09:29:39 PST 2005


I would suggest that if you want to instantiate arbitrary classes
at startup time, that you create a subclass of Attribute that
contains a single parameter, classNames, of type {string}
(array of strings) that in its constructor, creates an instance
of each of the specified classes.  Then put that attribute in
the configuration...

An alternative would be an attribute that loads something
from a user-specified file, such as one in
C:\Documents and Settings\eal\.ptolemyII\
(a directory that is already searched for the user library).

Edward

At 10:15 PM 2/22/2005 -0900, Matt Jones wrote:
>Hi Bertram,
>
>I was suggesting to Shawn exactly the kind of configuration mechanism that 
>you described.  The idea would be that user prefs would override defaults 
>and survive kepler upgrades, and that user-prefs would be bootstrapped by 
>copying the defaults into the users .kepler directory.
>So far we have a couple of configuration files in kepler, one of which is 
>in the traditional ptolemy "configuration", and one of which is 
>kepler-specific.  The ptolemy configuration file is quite a bit more 
>complicated to extend because it itself is a MOML file and is parsed using 
>the MOML parser, which requires a dynamically loadable class for every 
>configuration property.  So, for some of the simpler configuration 
>properties that we've simply wanted to record we have created a separate 
>config file (config.xml).  Its against this backdrop that we'd like to 
>create user-customizable configuation preferences, and allow users to 
>store their own ontologies.  A comprehensive solution needs to be 
>carefully designed to make it easier for us to extend and maintain the 
>kepler configuration and not complicate the already complex configuration 
>mechanisms we have in place.
>
>Regarding the ontologies, I think user-customizable ontologies would be 
>great, and Chad is working on a design for a GUI that allows the simpler 
>classification ontologies to be modified as part of the Kepler tree.
>More complex ontology editing I think is a difficult topic.  The sorts of 
>annotations that Shawn has proposed for data and actors are clearly needed 
>but are going to be difficult to compose even with an amazingly 
>well-conceived user interface (witness the difficulties with comprehending 
>simple ontologies with Growl).  I personally don't believe the Sparrow 
>language is suitable for exposure through the Kepler interface for the 
>ecological scientists and other scientists at whom we are targeting the 
>UI.   Do you have a user-clientele in mind that you think would embrace 
>Sparrow?  I don't think the ecologists will, but maybe there's another 
>group of users you have in mind.
>
>About the actors that were hidden: they were simply not classified in the 
>actor annotation file because they were deemed not-useful for the types of 
>workflows we have been targeting. I think this needs to be reviewed. We 
>can either add them into the ontology in the categories they belong, or 
>create one or more new categories to contain these 'advance features' that 
>should be less emphasized in the categorization.  We should really get 
>Laura involved in getting specific user feedback from our ecological 
>science testers about whether all actors should be included and if not, 
>which to exclude.  I think its valuable to simplify the list of choices to 
>include only those that are useful to a particular domain.  Because we 
>intend to support multiple ontologies that can change from domain to 
>domain, the list of actors that are relevant can also be customized 
>depending on the domain.  The actors still exist in Kepler, so workflows 
>that use them will still work fine -- they just don't show up in the tree 
>if they are not in the actor annotation file.  Shawn and Chad can probably 
>clarify the situation and correct any mistakes I might have made in 
>describing it.
>
>Matt
>
>Bertram Ludaescher wrote:
>
>>Shawn Bowers writes:
>> > Bertram Ludaescher wrote:
>> > > >  > On another note, we talked a bit on IRC a few days ago about 
>> some of the > >  > needed infrastructure within kepler to handle these 
>> changes.  One > >  > problem is that the only way to make an annotation, 
>> ontology change, or > >  > any other configuration in Kepler "last" is 
>> by checking in the changes > >  > to cvs.
>> > > > > I'm not sure I understand. Why can't there be a start-up sequence in
>> > > which the system looks for user-specific init/config files, after
>> > > loading the version specific ones? For example, XEmacs does something
>> > > like that on start-up: first load the "default configs" (corresponding
>> > > what would be found in the release/cvs) then look for the "user
>> > > configs", e.g., at the the place defined by an environment
>> > > variable (if it is defined), or if such isn't defined, then at a
>> > > "user location" such as ~/.keplerrc > > Yeah ... I don't think 
>> conceptually any of this is probably that > difficult; it's just that 
>> someone needs to implement it!
>> > > > > > I'm not sure what Ptolemy II does at start-up, but I wouldn't be
>> > > suprised if they'd let you do sth like that (and if they don't,
>> > > probably Kepler should do sth like that).
>> > > It's all just java code, so if we can change the base code, we're 
>> golden.
>>
>>Or (as just discussed ;-) maybe we can use some existing "start-up
>>hooks" of Ptolemy ...
>> > > shawn
>> > > > > > The big advantage of course would be that all user preferences,
>> > > configs, workflows, actors etc would "survive" an new Kepler install,
>> > > even if done "in-place".
>> > > > >  > This somewhat limits customization ... and is a larger 
>> issue > >  > that needs to be addressed.  Matt suggested using their 
>> approach in > >  > Morpho which involves copying files at startup, etc., 
>> which may be one > >  > way to do it.
>> > > > > I don't think copying is needed (see above)
>> > > > > Bertram
>> > > > >  > > >  > Shawn
>> > >  > > >  > > >  > > >  > Bertram Ludaescher wrote:
>> > >  > > Hi Matt:
>> > >  > > > >  > > A related question: I remember that at some point some 
>> Ptolemy actors
>> > >  > > were hidden (or otherwise disappeared from the Kepler actor tab). I
>> > >  > > assume they are still part of the Kepler distribution though, 
>> right?
>> > >  > > > >  > > Also: What are the plans for being able to edit actor 
>> annotations?
>> > >  > > (currently they seem to be "pseudo-hardwired", i.e., via some 
>> OWL-ishe
>> > >  > > files). As simple text-based form (just like the one for 
>> configuring
>> > >  > > ports or in fact one that links into that one) might do.
>> > >  > > > >  > > The ontology itself should be just a config file that 
>> can be changed
>> > >  > > via "Preferences" / "Options"..
>> > >  > > > >  > > Any comments?
>> > >  > > > >  > > Bertram
>> > >  > > > >  > > Matt Jones writes:
>> > >  > >  > Hi,
>> > >  > >  > > >  > >  > On our roadmap that we developed at the last 
>> Kepler meeting we said we > >  > >  > would try for an alpha 5 release 
>> by Feb 21 (see > >  > >  > 
>> http://kepler-project.org/Wiki.jsp?page=KeplerReleaseRoadmap&version=1).  
>>  > >  > >  >   That hasn't happened but is probably still useful.  I 
>> talked with Dan > >  > >  > today, and we thought it would be good to go 
>> ahead with a release to try > >  > >  > to get some of the bug fixes and 
>> improvements that we've completed now > >  > >  > out there in a more 
>> accessible format.  So Dan is planning on pulling > >  > >  > the CVS 
>> HEAD on Friday Feb 25 and creating the alpha5 installers 
>> then. > >  > >  > If you have anything you want included in this 
>> release, please check it > >  > >  > into CVS by Thursday the 24th, and 
>> please try not to check in any > >  > >  > experimental code that is 
>> likely to break the trunk (use a branch instead).
>> > >  > >  > > >  > >  > A revised roadmap is here:
>> > >  > >  > > >  > >  > 
>> http://kepler-project.org/Wiki.jsp?page=KeplerReleaseRoadmap
>> > >  > >  > > >  > >  > The main differences from the previous roadmap 
>> version are that: 1) the > >  > >  > documentation framework isn't 
>> complete so has been moved to alpha6, and > >  > >  > 2) the R 
>> improvements are ongoing and so have been extended to alpha6. 
>> I > >  > >  > also added links to the bug lists for each milestone.  The 
>> alpha 6 > >  > >  > release is slated for April 15th, 2005 (just prior 
>> to the SEEK and GEON > >  > >  > meetings and the Ptolemy/Kepler 
>> miniconference), and I think we should > >  > >  > try hard to make that 
>> deadline.
>> > >  > >  > > >  > >  > Cheers,
>> > >  > >  > Matt
>> > >  > >  > > >  > >  > -- > >  > >  > 
>> -------------------------------------------------------------------
>> > >  > >  > Matt 
>> Jones                                     jones at nceas.ucsb.edu
>> > >  > >  > http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 
>> 907-789-0496
>> > >  > >  > National Center for Ecological Analysis and Synthesis (NCEAS)
>> > >  > >  > University of California Santa Barbara
>> > >  > >  > Interested in ecological informatics? 
>> http://www.ecoinformatics.org
>> > >  > >  > 
>> -------------------------------------------------------------------
>> > >  > >  > _______________________________________________
>> > >  > >  > kepler-dev mailing list
>> > >  > >  > kepler-dev at ecoinformatics.org
>> > >  > >  > http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>> > >  > > > >  > > _______________________________________________
>> > >  > > kepler-dev mailing list
>> > >  > > kepler-dev at ecoinformatics.org
>> > >  > > http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>>
>
>_______________________________________________
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
>http://www.ecoinformatics.org/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
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  




More information about the Kepler-dev mailing list