[kepler-dev] kepler build broken due to changes with ptolemy's port and relation getWidth() function

[Christopher Brooks]

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> -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>> 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> www: 
>> http://eresearch.jcu.edu.au
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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