Personal tools
You are here: Home
Log in


Forgot your password?
New user?
 

Modified items

All recently modified items, latest first.
Re: moving to jdk 1.6 by Derik Barseghian, last updated: Jan 28, 2009 12:20 PM
I also like the idea of the build somehow doing the right thing for different versions. Are there enough developers on OSes that cannot use 1.6 that this is a reason to wait? Christopher, is there a reason to need Eclipse itself be running beneath 1.6? On my mac I launch Eclipse with my system default, 1.5, and then from within Eclipse change to 1.6  (via the two Eclipse => Preferences... => Java => Compiler and Installed JREs menus), and Kepler seems to build and run fine. My system details: nceas-macbook05:presentations derik$ uname -a Darwin nceas-macbook05.msi.ucsb.edu 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 nceas-macbook05:presentations derik$ java -version java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)
Re: build system usability issues by Daniel Crawl, last updated: Jan 28, 2009 11:23 AM
  OK, I've split Kepler.java. I've tested it with both kepler-trunk and kepler-1.0. Let me know if you have problems. I noticed that 'ant update' does not update build-area/, so be sure to update that directory to get all my changes.   Previously David Welker wrote: Hi Daniel, I think your proposal is a good one. You can invoke your initializations from org.kepler.loader.Kepler.main(). I think the general problem you have identified through your additions to Kepler might still be useful to discuss. I was thinking of calling a build team meeting. At this point though, I am going to hold off because I think your solution solves this problem for the time being and it may not pop up again. David  
internationalization of documentation and Kepler by Matthew Jones, last updated: Jan 28, 2009 10:17 AM
Kepler documentation is very useful to new users getting a handle on the system and its capabilities.  It would be very useful to have the documentation translated into a variety of languages.  For example, we know of collaborators in Japan and Taiwan who are actively using Kepler and for whom translated documentation would be welcome. Makoto Oba and Akiko Ogawa have led the way with a Japanese version of the Kepler Getting Started Guide , which I have linked into the docuentation web page.  I think other language versions of at least the Getting Started Guide could seriously improve Kepler's accessibility to international users.  Should we actively pursue a set of volunteers to undertake translations?  For that matter, should we consider the need for an internationalized version of the Kepler user interface that can be translated to work in different locales? Matt
internationalization of documentation and Kepler by Matthew Jones, last updated: Jan 28, 2009 10:17 AM
Re: moving to jdk 1.6 by Christopher Brooks, last updated: Jan 28, 2009 02:18 AM
Java 1.6 was not working with Eclipse on the Mac, see http://chess.eecs.berkeley.edu/ptexternal/wiki/Main/Mac#Eclipse1_6 So, we should probably not require Java 1.6 until someone verifies that it will work on the Mac with Eclipse. However, it would be nice if the build could handle different versions of Java, perhaps by just copying the appropriate file or else by having two directories, one that contains the file in question for Java 1.5 and different directory that contains the appropriate file for Java 1.6.  BTW - I think someone totally lost it at Sun when they introduced that lack of backward compatibility.  By and large, Java is quite backward compatible, this is by far the worst mistake they've made in this area to date.
Distributed Master-Slave Controller by Development Account, last updated: Jan 27, 2009 11:58 AM
Master-Slave Distributed Execution framework in Kepler is to facilitate Kepler users to harness the power of multiple computing nodes to accomplish computations that would be difficult, time-consuming, or impossible to accomplish on a single node.
review and revise the new web content by Matthew Jones, last updated: Jan 26, 2009 03:51 PM
Re: review and revise the new web content by Timothy McPhillips, last updated: Jan 26, 2009 03:51 PM
I've reviewed and revised the content on the following 4 pages.  I think they are in pretty good shape now. https://dev.kepler-project.org/users/features https://dev.kepler-project.org/users/sample-workflows https://dev.kepler-project.org/users/faq https://dev.kepler-project.org/developers/faq The following pages appear to need significant revision due to changes in the build system and repository layout.  I think we should postpone releasing these until the Build & Release team has a chance to update them:   https://dev.kepler-project.org/developers/reference/adding-a-new-java-actor-to-kepler-a-quick-tutorial   https://dev.kepler-project.org/developers/reference/adding-new-classes-jars-to-kepler     Tim  
Re: Collaboration tools by Matthew Jones, last updated: Jan 26, 2009 01:20 PM
As many of you know, we have been shifting some of the discussion of specific topics in Kepler development to our new forum software that is part of the emerging Kepler collaboration portal (https://dev.kepler-project.org/developers/kepler-development-forum).  The posts to these fora are available as a combined RSS feed and as individual RSS feeds. However, we've also had requests to the postings via email, so we have set up a new email gateway for all of the combined forum posts.   If you subscribe to the mailing list 'kepler-forum@kepler-project.org' then you will get a copy of each forum posting as it is made in the forum, along with a link to the post so that you can easily navigate to it and reply.  This is not a bi-directional gateway -- you can not post back to the mailing list.  To reply to the forum thread, you must go to the forum site and respond there, but the link makes this just one click away. You can subscribe to the email gateway here: https://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-forum/
Management by Development Account, last updated: Jan 26, 2009 12:09 PM
About Us by Development Account, last updated: Jan 23, 2009 05:11 PM
Re: proposed additions to provenance framework stores by Shawn Bowers, last updated: Jan 22, 2009 01:31 PM
Thanks Derik. I think this is very interesting. One thing that you did not mention, which to me seems like an essential, if not the most important aspect of tracking and reporting provenance information to a scientist is data lineage. In particular, data lineage refers to the data and processes that contributed to the creation of some output data product.  Tracking and reporting lineage information is extremely useful for determining if a workflow result is "correct" or can be "trusted". For example, determining the quality of a result may depend on whether (from a scientists perspective, e.g.) the input data used or the steps (algorithms/actors) involved in generating a data item are "appropriate/trusted". Another important use of data lineage information is to find those results that were derived from a particular data product, e.g., in cases where the input data was later found to contain errors, etc.   In many Kepler workflows, not all input data and not all actors are used in the derivation of an output -- and so determining data lineage requires more than reporting which actors were in a workflow, or what their input and output was.  Another potential source of confusion that may arise is that "data lineage" is typically used synonymously with provenance. This is the case in very broad fields including the archival/digital-library community, the database community, and also in the scientific workflow community.  In these areas, "provenance" typically refers to the processing history associated with some object/result -- where the interest is typically in understanding the provenance of an object (i.e., provenance refers to the lineage of a data item).  In both scientific workflows and in the database community, information surrounding runtime information that is not directly linked to lineage is often referred to generally as "logging" information.   Within the scientific workflow community in particular, you might want to check out the first provenance challenge.   This is now a bit old, but it describes a scientific workflow and a set of questions that are typically asked w.r.t. a run of the workflow (most of which are based on lineage information; a small number are based on general metadata of data items). Other approaches, such as the Open Provenance Model (OPM), which is being developed as a standard model for representing provenance information within scientific workflows, also places a primary emphasis on lineage. 
proposed additions to provenance framework stores by Derik Barseghian, last updated: Jan 22, 2009 01:29 PM
Re: moving to jdk 1.6 by David Welker, last updated: Jan 21, 2009 07:32 PM
Hi Derik, Thank you for your attention to this issue. One problem with requring 1.6 is that is not available for certain versions of Mac OS X (10.4 and earlier). As you know, as soon as we move to 1.6 in the DBConnection class, I believe that 1.5 will no longer work. I personally would be inclined to require the move to Java 1.6, but then I am certainly not someone who would be negatively affected by such a move in any way. What I would like to hear are objections from anyone, whether on the build and release team or not, to requiring 1.6. I think people are hesitant. I know that someone in our group is in fact running a slightly older Mac and they cannot use 1.6...
Re: moving to jdk 1.6 by Derik Barseghian, last updated: Jan 21, 2009 06:57 PM
Could someone on the build and release team let me know your thoughts on this? In a call today it was mentioned it's possible to do the kind of table sorting and filtering I'd like to do in the Workflow Run Manager with 1.5 -- maybe just with standard api, or by rolling my own, or by using something like the lgpl swingx . I can do that, but if there's nothing holding us back from requiring 1.6, I'd rather leverage it than write more code or include another jar in Kepler. And of course we'd presumably (hopefully!) reap additional benefits from the new language features. My particular case for moving to 1.6 is weak, but I'd like to hear others thinking on this. Are there reasons to stay with 1.5? Is there a timeframe for moving to 1.6? As I mention in the previous post I've been trying it for a little bit now and haven't noticed any issues, but perhaps I have overlooked something(s)... Thanks.
Re: review and revise the new web content by Matthew Jones, last updated: Jan 20, 2009 05:36 PM
To recap from today's call, we set a deadline of next Tuesday (January 27) to complete these changes.  To facilitate this, I've created a new page in the site where we can track our progress:  Review and Editing for site migration .  Note that several of my pages have been marked as 'DONE' or 'REPLACED'.  Please update your entries as you finish with the edits on each page.  Thanks. Matt
Workflow sharing features in Kepler by Matthew Jones, last updated: Jan 20, 2009 04:17 PM
Several projects seem to be working on infrastructure for workflow sharing in Kepler.  This interest group is an attempt to bring these people together to find common ground on how to build infrastructure for Kepler.  I thought I would list several known projects to initiate the discussions, and where possible we've linked in design documents to the workflow sharing interest group page. REAP: Developing mechanisms for packaging workflow runs and their run history in KAR files, building GUIs to share these through the Kepler Workflow Repository (http://library.kepler-project.org), and building GUI tools for reporting and run management that help manage outputs in a presentable manner. myExperiment: a general-purpose workflow repository.  We may be able to expose Kepler KAR workflows here with modest changes. CAMERA: rumored to be working on workflow sharing via the web  -- hopefull y more details to follow Hydrant: web-based portal for uploading and sharing workflows, and also can execute workflows   I'm sure there are others.  It would be great to see current plans for all of these projects and others posted to the Workflow Sharing Interest Group .  
Workflow sharing features in Kepler by Matthew Jones, last updated: Jan 20, 2009 04:16 PM
Workflow Sharing Interest Group by Matthew Jones, last updated: Jan 20, 2009 03:54 PM
Re: build system usability issues by David Welker, last updated: Jan 16, 2009 01:33 PM
Hi Daniel, I think your proposal is a good one. You can invoke your initializations from org.kepler.loader.Kepler.main(). I think the general problem you have identified through your additions to Kepler might still be useful to discuss. I was thinking of calling a build team meeting. At this point though, I am going to hold off because I think your solution solves this problem for the time being and it may not pop up again. David
 
« Previous 20 items Next 20 items » 1 … 25 26 27 28 29 30 31 … 46