[kepler-dev] kepler build broken due to changes with ptolemy's port and relation getWidth() function
Edward A. Lee
eal at eecs.berkeley.edu
Tue Nov 4 07:58:42 PST 2008
All,
I apologize for the disruption to the Kepler project for breaking
the build... I want to assure you that this is a rare event.
We put high priority on backward compatibility. Bert is struggling
with a very difficult challenge (which will not only improve
functionality, but also performance). But he should have been checking
his changes against the Kepler tree... We'll make sure any such
kernel changes are so checked...
Edward
David Welker wrote:
> Hi Matt,
>
> I think it is important that we track improvements in a lot of the
> software we depend on. That doesn't mean that we need to work against
> the trunk of that software.
>
> We should treat Ptolemy like any other dependency. We should upgrade it
> when we have a compelling reason to do so rather than allowing
> incremental changed in Ptolemy to break Kepler. There really is very
> little gained and much lost by wasting developer time keeping these two
> projects synchronized in real time as opposed to periodically when we
> have a compelling reason to do so.
>
> This is a case in point. The feature that was added to Ptolemy and which
> ended up sucking up Kepler developer time with unnecessary errors was
> nothing more than the decision to have a particular method throw an
> exception that it did not previously. Clearly, such changes incremental
> changes to Ptolemy are probably in fact very important in the long run.
> In the short run, these are not exactly critical features that we should
> allow to break Kepler or waste the time of our developers.
>
> David
>
>> Thanks, Christopher, for fixing those things.
>>
>> This discussion obviously brings up the age-old discussion of whether
>> Kepler should build against a release point in ptII or the head of
>> ptII. I think our new strategy for modularization argues that we
>> should be building against specific component versions and keeping
>> those updated as needed. Although its useful to be able to specify a
>> specific release point in ptolemy and reliably build against it, I
>> think we also need to be sure we are tracking the improvements in
>> ptolemy and moving our standard build forward to new ptolemy release
>> points as bugs are fixed and new features are incorporated. We'll
>> need to consider this in the new build system as it matures.
>>
>> Matt
>>
>> On Mon, Nov 3, 2008 at 11:59 AM, Christopher Brooks
>> <cxh at eecs.berkeley.edu <mailto:cxh at eecs.berkeley.edu>> wrote:
>>
>> Hi Tristan,
>> Ok, there were only a few places to fix the calls to getWidth(),
>> which
>> I did. Kepler now runs for me.
>>
>> We considered not changing getWidth(), but it just seemed wrong to
>> have it not throw an IllegalActionException. This is the hazard of
>> modifying preexisting code - things break.
>>
>> The bug that is being fixed is at
>> https://chess.eecs.berkeley.edu/bugzilla/show_bug.cgi?id=164
>>
>> _Christopher
>>
>>
>> Christopher Brooks wrote:
>>
>> Hi Tristan,
>> Sorry about the lossage, it looks like the Kepler automatic
>> build is
>> erroneously reporting that the build works properly.
>>
>> I started fixing build problems, but I'm not sure how many
>> problems
>> there are. My write access to the kepler tree seems to be
>> disabled, so
>> I can't check in my changes right now. It could be something
>> simple
>> on my end.
>>
>> I've cc'd Bert Rodiers, who is responsible for the width
>> inference work.
>> The width inference work is important because it fixes a long
>> standing
>> usability issue surround multiport composite actors.
>>
>> Bert, could you check out the svn head Kepler head and build
>> it against
>> the latest ptII head and get a sense of how many changes are
>> required
>> to update Kepler? The instructions are at
>> http://www.kepler-project.org/Wiki.jsp?page=DevelopmentForKepler
>> I suggest building with Eclipse even though building with
>> Eclipse is
>> somewhat complex as the Eclipse build will tell you the total
>> number of
>> errors, but "ant -k run-dev" halts at the first error.
>>
>> Also, can someone look at the Kepler automatic build and see
>> why it
>> is not reporting failures like:
>> compile-dev:
>> [javac] Compiling 972 source files to
>> c:\tmp\cxh\src\kepler\build\classes
>> [javac]
>>
>> c:\tmp\cxh\src\kepler\build\src\org\ecoinformatics\seek\gis\gdal\GDALTranslateActor.java:131:
>>
>> unre
>> ported exception ptolemy.kernel.util.IllegalActionException;
>> must be caught or declared to be thrown
>> [javac] "input width was" +
>> inputFilename.getWidth());
>>
>> [javac] ^
>> [javac] Note: Some input files use or override a deprecated
>> API.
>>
>> _Christopher
>>
>> Tristan King wrote:
>>
>> I reverted both kepler and ptolemy back to the day before
>> the change to ptolemy (which from the logs seems to be the
>> 20th of Nov). I tried to just put ptolemy back to that
>> date, but there seems to be other changes to kepler that
>> depend on future ptolemy code.
>>
>> so from the command line i did:
>>
>> cd $PTII && svn switch
>> svn+ssh://source.eecs.berkeley.edu/home/svn/chess/ptII/trunk
>> <http://source.eecs.berkeley.edu/home/svn/chess/ptII/trunk>
>> <http://source.eecs.berkeley.edu/home/svn/chess/ptII/trunk>
>> -r {2008-10-20}
>>
>> which resulted in ptolemy revision 50844. Then:
>>
>> cd $KEPLER && svn switch
>> https://code.kepler-project.org/code/kepler/trunk -r
>> {2008-10-20}
>>
>> which gave kepler revision 8114. After that "ant
>> full-clean ptolemy jar" finished succsessfully.
>>
>> The kepler/ptolemy guys may be able to find more recent
>> revisions that work, I've wasted too much of the day
>> playing with this already and need to get onto some real
>> work :).
>>
>> Hope this helps
>> -Tristan
>>
>> On Mon, Nov 3, 2008 at 2:06 PM, <Peter.Fitch at csiro.au> wrote:
>>
>> Hi Tristan,
>>
>> Good to know. Do you know which versions of kepler and
>> ptolemy
>> currently compile?
>>
>> Cheers
>> Peter
>>
>>
>> On 3/11/08 2:48 PM, "Tristan King"
>> <tristan.king at jcu.edu.au <mailto:tristan.king at jcu.edu.au>
>> <mailto:tristan.king at jcu.edu.au
>> <mailto:tristan.king at jcu.edu.au>>> wrote:
>>
>> Hi all,
>>
>> Just thought i'd let everyone know that kepler no
>> longer compiles
>> against the current trunk of ptolemy.
>>
>> I think this brings up a bit of an issue. Is the plan
>> with the
>> kepler trunk to always compile against the ptolemy
>> trunk? If not,
>> then the INSTALL.TXT file should probably be updated to
>> specify the
>> revision to use, or maybe ptolemy should be pulled down
>> by svn
>> external when pulling down kepler (I think this may
>> have been
>> discussed tho, and was decided to not be a good idea, I
>> don't
>> remember why). an svn external would make sure every
>> kepler
>> developer is working with the same revision of ptolemy,
>> and since
>> you can specify a specific revision for the external,
>> someone could
>> be responsible for integration of new ptolemy revisions
>> into kepler
>> and avoid problems like this one.
>>
>> Peter Fitch
>> Group Leader, Predicting and Reporting Technologies
>> CSIRO Land and Water
>>
>> Clunies Ross Street
>> Black Mountain ACT.
>>
>> Telephone: +61 (0)2 6246 5763
>> Facsimile: +61 (0)2 6246 5800
>>
>>
>>
>>
>> -- Tristan King
>> Research Officer,
>> eResearch Centre
>> James Cook University, Townsville Qld 4811
>> Australia
>>
>> Phone: +61747816902
>> E-mail: tristan.king at jcu.edu.au
>> <mailto:tristan.king at jcu.edu.au>
>> <mailto:tristan.king at jcu.edu.au
>> <mailto:tristan.king at jcu.edu.au>> www:
>> http://eresearch.jcu.edu.au
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> <mailto:Kepler-dev at ecoinformatics.org>
>>
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> <mailto:Kepler-dev at ecoinformatics.org>
>>
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org <mailto:Kepler-dev at ecoinformatics.org>
>>
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Matthew B. Jones
>> Director of Informatics Research and Development
>> National Center for Ecological Analysis and Synthesis (NCEAS)
>> UC Santa Barbara
>> jones at nceas.ucsb.edu <mailto:jones at nceas.ucsb.edu>
>> Ph: 1-907-523-1960
>> http://www.nceas.ucsb.edu/ecoinfo
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 351 bytes
Desc: not available
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20081104/063d8aeb/attachment.vcf>
More information about the Kepler-dev
mailing list