From: Braisted, J. <bra...@ti...> - 2005-10-31 17:04:13
|
Hi Vu, Eleanor, and others, Here are a few items: 1.) ANT Build Script Vu, could you send out a build.xml that includes targets for your 'org.tigr.microarray.mev.r' package for testing? Thanks. (Let me know if you don't get this through the mailing list. I was having some problems and I suspect that it was because of using the 'daily digest' option for delivery.) 2.) Script and Developer Docs We discussed setting up an area for the xml and possibly a separate area for documentation. I don't see a very good solution used by other projects but I'm open to suggestions. The 'DocManager' that SF offers only handles html and text format. Some projects put documentation into a file release. It might be possible to bundle developer documentation into a zip but we would want to separate it from the full mev release area. Some projects seem to have ANT build files in CVS for versioning. In some cases this is just in the root directory but I think we can add a script folder that contains the script. =20 3.) SVM state saving issues (response to Eleanor's SVM message below): Alex Sturn made the classification and training viewers extend the SVMResultViewer which basically holds the components and data and has some abstract methods that the other viewers (for rendering or building the output String). It's not a bad design given that the two viewers are so similar but the layering probably makes state saving cumbersome. =3D=3D=3D=3D=3D One option might be to make these simple JTables. I can't work on redoing these but if you want to wrap or extend my generic TableViewer (...gui.helpers.TableViewer...) it has a constructor that can take the header and the 2D array of Strings. TableViewer(String [] headerNames, Object [][] data)=20 If you extend TableViewer you can use the default constructor and build the result string array and header in the constructor. TableViewer will handle the IViewer interface. The header can be limited to the column headers. Currently it contains all of the parameters. These are captured in the SVMData object in SVMGUI and can be dropped under a 'General Info' node rather than in the viewer header. John -----Original Message----- From: Eleanor Howe [mailto:ele...@ji...]=20 Sent: Friday, October 28, 2005 5:57 PM To: Braisted, John Subject: SVM Hey John,=20 You mentioned last night that SVM needs to be worked on. Is that something you've considered doing? Or should I plan on doing it myself if it needs done? I ask because I'm running into brick walls in trying to get it to save state with the method I'm using. If the ResultPanel viewers weren't so weird I'd be fine. I'm tempted to turn them into generic JPanels just to make my life easier. =20 Eleanor |
From: Braisted, J. <bra...@ti...> - 2005-10-31 22:24:27
|
Here's a proposal: I can start the ball rolling and create a 'build_scripts' folder in the root directory of cvs. I'll add my current build.xml (basic 3.1) which Vu, then Wendy and Eleanor can update in turn.=20 If we follow an order we will have build script versions that follow the software updates that have already happened or are about to happen. 1.) I'll start with the 3.1 basic script -> 3.1 base 2.) Vu can update the script to add or modify targets for r -> + r connectivity //looks like the code is already in CVS and his current build.xml should be ready to commit. 3.) Eleanor and Wendy updates... I'm not sure if these=20 script updates are actually one but it seems like it=20 should build on Vu's script and might just be modification to a few targets. -> + Wendy's updates //loaders -> + Eleanor's alterations for state saving=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D **I'm not going to do anything until I get feedback on this so let me know what you think. Once we decide to do this or something like it, we just send a zip by secure ftp to the project area and ask the admins to unzip it. Whoever does this should try to make sure that the base build.xml corresponds to the basic 3.1 so that we are starting in the right place. Thanks, John -----Original Message----- From: Eleanor Howe [mailto:ele...@ji...]=20 Sent: Monday, October 31, 2005 2:16 PM To: Braisted, John Cc: iVu; mev...@li... Subject: RE: SVM .... etc. I agree that a folder for the build scripts is a good idea. When I release my changes to MeV I'll be sure to update the script.=20 I'll go ahead and try using a JTable for the SVM classification and training viewers. They contain a lot of duplicate data and I don't think they need to be as complex as they are. Eleanor On Mon, 31 Oct 2005, Braisted, John wrote: > Hi Vu, Eleanor, and others, >=20 > Here are a few items: >=20 > 1.) ANT Build Script >=20 > Vu, could you send out a build.xml that includes targets for your=20 > 'org.tigr.microarray.mev.r' package for testing? Thanks. > (Let me know if you don't get this through the mailing list. > I was having some problems and I suspect that it was because of using=20 > the 'daily digest' option for delivery.) >=20 > 2.) Script and Developer Docs >=20 > We discussed setting up an area for the xml and possibly a separate=20 > area for documentation. I don't see a very good solution used by=20 > other projects but I'm open to suggestions. >=20 > The 'DocManager' that SF offers only handles html and text format. > Some projects put documentation into a file release. It might be=20 > possible to bundle developer documentation into a zip but we would=20 > want to separate it from the full mev release area. >=20 > Some projects seem to have ANT build files in CVS for versioning. > In some cases this is just in the root directory but I think we can=20 > add a script folder that contains the script. >=20 > =20 > 3.) SVM state saving issues (response to Eleanor's SVM message below): >=20 > Alex Sturn made the classification and training viewers extend the=20 > SVMResultViewer which basically holds the components and data and has=20 > some abstract methods that the other viewers (for rendering or=20 > building the output String). It's not a bad design given that the two > viewers are so similar but the layering probably makes state saving=20 > cumbersome. >=20 > =3D=3D=3D=3D=3D >=20 > One option might be to make these simple JTables. I can't work on=20 > redoing these but if you want to wrap or extend my generic TableViewer > (...gui.helpers.TableViewer...) it has a constructor that can take the > header and the 2D array of Strings. >=20 > TableViewer(String [] headerNames, Object [][] data) >=20 > If you extend TableViewer you can use the default constructor and=20 > build the result string array and header in the constructor. =20 > TableViewer will handle the IViewer interface. >=20 > The header can be limited to the column headers. Currently it=20 > contains all of the parameters. These are captured in the SVMData=20 > object in SVMGUI and can be dropped under a 'General Info' node rather > than in the viewer header. >=20 > John >=20 >=20 > -----Original Message----- > From: Eleanor Howe [mailto:ele...@ji...] > Sent: Friday, October 28, 2005 5:57 PM > To: Braisted, John > Subject: SVM >=20 >=20 > Hey John, >=20 > You mentioned last night that SVM needs to be worked on. Is that=20 > something you've considered doing? Or should I plan on doing it=20 > myself if it needs done? I ask because I'm running into brick walls=20 > in trying to get it to save state with the method I'm using. If the=20 > ResultPanel viewers weren't so weird I'd be fine. I'm tempted to turn=20 > them into generic JPanels just to make my life easier. >=20 > Eleanor >=20 |
From: Eleanor H. <ele...@ji...> - 2005-10-31 19:16:36
|
I agree that a folder for the build scripts is a good idea. When I release my changes to MeV I'll be sure to update the script. I'll go ahead and try using a JTable for the SVM classification and training viewers. They contain a lot of duplicate data and I don't think they need to be as complex as they are. Eleanor On Mon, 31 Oct 2005, Braisted, John wrote: > Hi Vu, Eleanor, and others, > > Here are a few items: > > 1.) ANT Build Script > > Vu, could you send out a build.xml that includes targets for your > 'org.tigr.microarray.mev.r' package for testing? Thanks. > (Let me know if you don't get this through the mailing list. > I was having some problems and I suspect that it was because > of using the 'daily digest' option for delivery.) > > 2.) Script and Developer Docs > > We discussed setting up an area for the xml and possibly a > separate area for documentation. I don't see a very good solution > used by other projects but I'm open to suggestions. > > The 'DocManager' that SF offers only handles html and text format. > Some projects put documentation into a file release. It might > be possible to bundle developer documentation into a zip but we > would want to separate it from the full mev release area. > > Some projects seem to have ANT build files in CVS for versioning. > In some cases this is just in the root directory but I think we > can add a script folder that contains the script. > > > 3.) SVM state saving issues (response to Eleanor's SVM message below): > > Alex Sturn made the classification and training viewers > extend the SVMResultViewer which basically holds the components and data > and has > some abstract methods that the other viewers (for rendering or building > the > output String). It's not a bad design given that the two viewers are > so similar but the layering probably makes state saving cumbersome. > > ===== > > One option might be to make these simple JTables. I can't work on > redoing > these but if you want to wrap or extend my generic TableViewer > (...gui.helpers.TableViewer...) it has a constructor that can take the > header > and the 2D array of Strings. > > TableViewer(String [] headerNames, Object [][] data) > > If you extend TableViewer you can use the default constructor and build > the result string array and header in the constructor. TableViewer will > handle > the IViewer interface. > > The header can be limited to the column headers. Currently it contains > all of the parameters. These are captured in the SVMData object in > SVMGUI and > can be dropped under a 'General Info' node rather than in the viewer > header. > > John > > > -----Original Message----- > From: Eleanor Howe [mailto:ele...@ji...] > Sent: Friday, October 28, 2005 5:57 PM > To: Braisted, John > Subject: SVM > > > Hey John, > > You mentioned last night that SVM needs to be worked on. Is that > something you've considered doing? Or should I plan on doing it myself > if it needs done? I ask because I'm running into brick walls in trying > to get it to save state with the method I'm using. If the ResultPanel > viewers weren't so weird I'd be fine. I'm tempted to turn them into > generic JPanels just to make my life easier. > > Eleanor > |