Minutes
Attendees: Joanne Bogart, Toby Burnett, Johann Cohen Tanugi, Richard Dubois, Riccardo Giannitrapani, Navid Golpayegani, Heather Kelly
MRStudio Current Status
As discussed in April, the tagging and application running are now available in MRStudio. Through his interactions with Joanne on Linux, there have been a number of fixes, including the multiple building of a packagelike xmlUtil. Riccardo sees that the HEAD is left untagged and will check on Joanne item #2 on the wishlist (see below ), and then tag v0r6. This version could be considered a beta release for people to start using.
Items that are on the To Do List:
- VS2005 Support
- CMTPATH file that allows user to specify CMTPATH, right now this must be done through a full configuration file
- Doxygen Generation
FOX Toolkit
Johann gave an update on his troubles with FRED and Fox. http://www.slac.stanford.edu/~cohen/testFRED.txt It worked on the norics but not on RHEL4.
Riccardo has provided a script for building Fox to Navid and Joanne. He would like to make this generally available to those who cannot use his distributed build. The windows builds are fairly standardized, so we expect no issues on that platform. Apparently, the build does depend on the system and may pull in system extensions that are apparently available on Riccardo's system, but not available on other systems.
Riccardo has updated MRStudio to use a more recent version of Fox: 1.6.19. FRED uses a version like 1.2.x, Johann reports trouble even recompiling this version with a more recent version of the compiler. Riccardo will update FRED to use this more recent version of FOX and that may fix Johann's troubles. Johann suggests that since Fox's interface has changed, there may be required modifications to FRED to move to Fox 1.6.19.
SCons Migration
Due to the change in directory structure, as Navid points out, there is no rational way to have a single version of MRStudio that handles both CMT and SCons. Instead, Riccardo will get a fully functional version of MRStudio using CMT and then work will proceed on the next generation of MRStudio that works with SCons.
Riccardo asked to look at our current use of SCons and then report back on his anticipated modifcations to get a version of MRStudio to work with it. Navid pointed Riccardo to the Confluence pages:
Tagging Convention
We discussed our suggested new tagging convention: <package>_v000-000-000
Riccardo asked why we wanted the package name to be included. Navid provided a clear answer:
There were two factors in this new convention. First we wanted something that was sortable, hence the v000-000-000. The need for the <package>_ is due to our move to SCons and our new mechanism to check out the code. See the minutes from our CVS conversation during Core Week. In particular, when checking out a package, we need to avoid any confusion between a tag v5 on the Likelihood package and a v5 on astro, for instance.
MRStudio already has been generalized to handle any alphanumeric combination in the tags. Riccardo will check to see if underscores are handled as well. He does not expect this to cause any big problems.
VS2005
This remains on Riccardo's To Do list. He has his own mechanism for generating VS2003 files. First Riccardo needs to install VS2005 Express Edition (as recommended by Toby). Then he can try calling the PyCMT scripts from MRStudio. Before diving into this, Riccardo will fix take care of any remaining Linux issues for the MRStudio beta release. Riccardo then asked whether SCons handles VS2005 solution file generation. The answer is no, not by default. We continue to hope that through Tracy's study of SCons and using parts of PyCMT we will be able to provide our own way to build the solution files. Toby also noted that we need a way to create solutions that include all the dependent packages as well. It is not immediately clear how this will work with SCons.
Joanne's MRStudio WishList
We went briefly over Joanne's wishlist (see below). Joanne specified that number one and two were the most important, the rest were not necessary for a MRStudio beta release. Number one relates to running the debugger, Riccardo stated Marco had written that part for MRvcmt. Riccardo will be seeing Marco soon and will discuss with him the possibility of just taking his code from MRvcmt and using it within MRStudio. As for the second item, Riccardo thought he had fix the tagging so that the release.notes and requirements file were updated. Joanne has tried the HEAD of MRStiudio and does see an opportunity to edit the release.notes. Riccardo will check on this and patch as necessary.
Agenda Items
Current MRStudio status
In April we had agreed that MRStudio's gui should be updated to include tagging and running applications - is that now available?
Latest version is v0r5 in CVS? There are other fixes on the HEAD
What was the result from Joanne's feedback?
Provide users the ability to compile fox toolkit themselves, if the one Riccardo provides does not work
xmlUtil was rebuilding multiple times but ultimately finished.
Joanne's WishList
Visual Studio 2005 support
MRvcmt is considered frozen - is it possible to get MRStudio working with Toby's PyCMT scripts?
Change to Tagging Convention
Changes to our tagging convention. <package>_v000-000-000
Would it be easier to implement <package>_v000r000p000 ? As it seems Riccardo has already updated MRStudio HEAD to handle any alphanumeric combination.
SCons
Removing tag directory [We're not using CMT to do checkout directly in MRStudio but removing this directory may result in a major revision to MRStudio - how much?]
Allow CMT and SCons to be used side-by-side for some period of time (~6months)
Method to communicate ext lib locations that over-ride the default in the externals.scons
Handling multiple CMTPATHs is TBD
Wish List
1. Ability to run a program in debugger.
With just a button push MRvcmt will bring up gdb inside an emacs session. Source is visible and all necessary context is preserved. This is an essential function!
2. Tagging. The last time I tried it, I was able to make the tag but MRStudio did not give me a chance to edit release.notes nor did it update the version in the CMT requirements file [The second one may not
be necessary in the SCons-based system.]
3. Ability to spawn terminal window in the context of a package.
Actually, since the SCons system will be much better about managing context
than CMT, maybe there isn't much to do here.
Then this one, less important but annoying and probably easy to fix:
4. Change compiler specification from 'GCC' to 'gcc'. Using capitals for
this is very strange for the typical Linux/unix user. Just about
everyone will get it wrong the first time.
And even lesser things, which are largely a matter of taste and can
wait until the integration with the SCons system is done.
5. As new functions are added to MRStudio, it's most important to get them into some menu because icons by themselves can be obscure. Also displaying every icon in a toolbar can take up a lot of space.
6. Font in upper frame (with tabs for requirements, release.notes, mainpage.h) is unnecessarily large. The font used in the lower frame looks great: compact but very readable. Why not use it in both frames?
7. The cvs status command for MRvcmt only outputs information for the requirements file. MRStudio outputs information for all files.
I'm not sure what's more appropriate and useful (I didn't even know this command existed in MRvcmt!).
8. More configurability of appearance (e.g., ability to suppress toolbars) would be nice.
9. Ability to clear the output window
FRED Problems
Johann reported a problem with FRED a few weeks ago. Riccardo thought this was fixed some time ago with Navid's help. Perhaps we know more today? Here is Johann's original email:
I logged on rhel4-32.slac.stanford.edu, following Navid's advice, in order to test the behavior of FRED on such a system. Launching Gleam fails to open FRED, with the following error :
/afs/slac.stanford.edu/g/glast/ground/GLAST_EXT/rhel4_gcc34/Fred/v0r99/redist/i686-linux/fox12.so: /afs/slac.stanford.edu/g/glast/ground/GLAST_EXT/rhel4_gcc34/Fred/v0r99/redist/i686-linux/fox12.so: undefined symbol: XcursorSupportsARGB - /afs/slac.stanford.edu/g/glast/ground/GLAST_EXT/rhel4_gcc34/Fred/v0r99/redist/i686-linux/fox12.so (LoadError) from ./kernel/main.rb:5
from /afs/slac/g/glast/ground/GLAST_EXT/rhel4_gcc34//Fred/v0r99/fred.rb:276:in `load'
from /afs/slac/g/glast/ground/GLAST_EXT/rhel4_gcc34//Fred/v0r99/fred.rb:276:in `bootFRED'
from /afs/slac/g/glast/ground/GLAST_EXT/rhel4_gcc34//Fred/v0r99/fred.rb:288
I have the exact same error on my FC7 box, and it seems to be known on the web.... I tried to rebuild FOX and FXRuby 1.2.X but the only available packages I found are FOX 1.2.18 and FXRuby 1.2.6, and theydont seem to be compatible, as compilation failed.
Then I tried to build recent versions of both packages, but then it is FRED itself which seems to have a problem : I can launch the guistandalone, but as soon as I try to read an ior file, I get ############################################################ FRED version v0r100 "Calvin"## Mon Jun 19 09:44:22 W. Europe Daylight Time 2006## Authors: R.Giannitrapani M.Frailis ## Contact: riccardo@fisica.uniud.it ## Web site: www.fisica.uniud.it/~glast/FRED##########################################################FXRbToolBar::create: trying to create window before creating parent window.
and the whole thing hangs.....
so right now, I am stuck..... wonder if anybody else has experienced all this!
Johann