You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

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.

FOX Toolkit 

Johann gave an update on his troubles with FRED and Fox.http://www.slac.stanford.edu/~cohen/testFRED.txt

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
 

                                               

  • No labels