XM2: S/W Co-ordination Meeting - MSSL 27 June 1991 H.E.Huckle MINUTES - XMM-OM/MSSL/MN/0015.1 Attending Joe Chavez Sandia Cheng Ho LANL Howard Huckle MSSL Dave Leisawitz Penn State Philip Smith MSSL At an informal discussion group, the following software coordination topics were discussed and the following agreements reached. 1. Which languages should XMM-OM use and for what tasks? It was felt this was best left to the programmer concerned, although the expressed current preference was for C with assembler | where efficiency was required (HEH note - Subsequent E-mail | discussion agreed that this should be in consultation with | software management i.e. contact MSSL (HEH) regarding non-C code | for non-internal use). 2. Coding styles for C, Fortran, assemblers, a.n.other ? HEH agreed to extend his draft C-standard document (XMM-OM/MSSL/SP/0008.draft) to include comments when received (by end of July '91 please!). HEH also agreed to produce a template C header file defining standard types which all sites should modify accordingly so that code, when ported, still uses e.g. integers of the same length. It was felt that a similar document for Fortran was not yet required. HEH will attempt (at a low priority) to produce a 'style' document for assembler code. 3. Should we conform to ANSI-C, K and R Ed 1 with extensions, ? ? It was felt that, although moving to ANSI-C was a desirable goal, the lack of its availability across all platforms made this unlikely at this stage of the project. HEH agreed to draw up a list of extensions to Kernighan and Ritchie Edition 1 that would be acceptable. JC agreed to supply technical information on extensions allowed for the C compilers he is considering for his Macintosh so that this might be accomplished. He also expressed concern that the C cross-compiler he is evaluating for the DSP does not sufficiently exploit the architecture and that it might be necessary to develop a 'toolkit' of assembler routines that would be emulated in C on other platforms. Page 2 4. Should we conform to FORTRAN 77, 77 + extensions, FORTRAN 90? The recent release of the Fortran 90 specification and the lack of any immediate need for an agreed standard meant that no decision was reached. 5. Software/Data/Simulation Data transfer mechanisms 1. Tape 2. E-Mail/File Transfer 3. Floppies 4. Cassettes (e.g. Exabyte) 5. ??? At this stage of the project, E-mail of ASCII files was considered sufficient. However, JC has currently no access to E-mail and agreed to investigate whether this can be achieved and to look into file capture via a modem facility. CH agreed to look into file transfer to DTL via the tapes drives on their respective Sun workstations. It should also be possible to transfer information to JC using Macintosh or PC floppies. On a related topic, PJS said that he would rewrite XMMOM_SIM in C to aid further development and increase portability. CH asked for a piece of code based on this to accept a table of stars and output a table of counts, S/N, resolution, etc. CH agreed to send PJS a proper specification for the required function (table format for input and table format for output and anything else required). 6. What file naming conventions should we adopt (e.g. MS-DOS only allows a max of 8 characters for filename, 3 for extensions)? It was agreed that we should not keep filenames to the restrictive MS-DOS limits. It was felt that any files developed on PC's, when exported, should have an agreed prefix (see below) added to it. It was agreed that filenames should have a prefix of the form xxxi_ where 'xxx' indicates the configuration item (e.g. 'xxx'=DPU to indicate the DPU software package) and 'i' indicates the originating institute (M=MSSL, P=Penn State, L=LANL, S=Sandia, O=OABM, I=IAL Space, G=Officine Galileo) Page 3 7. What routine naming conventions should we adopt? In a similar fashion to filenames, it was agreed that routines should have a prefix of the form xxxi_ where 'xxx' indicates the configuration item, 'i' indicates the originating institute (M=MSSL, P=Penn State, L=LANL, S=Sandia, O=OABM, I=IAL Space, G=Officine Galileo). For C-code, the prefix should be in lower case. 8. What standard file formats (e.g. FITS) should we adopt, and when? CH agreed to list the possible options to transfer image files. Some concern was expressed by the MSSL representatives that FITS was not as 'standard' as commonly believed. 9. Configuration Control. 1. Testing procedures - local, system level? 2. 'Bug' reporting mechanisms 3. How do we number software releases? 4. Who is responsible for each item of software (package managers)? HEH stated that he would prefer to consult the document "ESA Software Engineering Standards Issue 2 (ESA PSS-05-0)" before issuing a proposal document discussing testing procedures and 'bug' reporting mechanisms. However, it was agreed that the software release numbering scheme should be as follows:- Dm.n + optional suffix (Development Versions) m.n + optional suffix (Official Release of above development version) m is a number (starting at 1) indicating the level of major release n is a number (starting at 0) indicating the level of minor release The optional suffix letter (starting at 'a') indicates a 'bug' fix. It was also agreed that 'package managers' should be appointed to be in overall charge of a 'configuration item', and that official releases should only come from them. DTL agreed to take on this responsibility for the DPU, HEH for the ICU. HEH agreed to discuss with MSC encouraging the Italian consortium members to appoint such a person. Page 4 10. Should we keep a central register of software/resources and how should it be accessed? HEH agreed to look into the possibility of writing automatic tools to extract information from the standard module and routine header information (as documented in XMM-OM/MSSL/SP/0008.draft), thus automating as much as possible the provision of a central register. The means of access/distribution of this facility, and its location, was left open. (HEH note - as the lead institute, could I suggest that the definitive version be kept at MSSL). ACTIONS | | XM2-1: All present to reply to draft C-standard XMM-OM/MSSL/SP/0008.draft | by 31 July 91 XM2-2: HEH to include comments in above. XM2-3: HEH to produce standard C 'header' file template to aid portability. XM2-4: HEH to consider producing Assembler code 'style' document. XM2-5: HEH to draw up list of allowed extensions to C K and R Ed 1. XM2-6: JC to provide HEH information on supported extensions for Macintosh C compilers. XM2-7: JC to investigate provision of E-mail access for Sandia XM2-8: JC to investigate file capture via Modem facility. | | XM2-9: CH to investigate file transfer to DTL via tape. (Response | received 3 Jul '91). XM2-10: PJS to re-write XMMOM_SIM in C. XM2-11: CH to supply PJS specifications for XMMOM_SIM code routine(s). XM2-12: PJS to supply CH with requested XMMOM_SIM code. | | XM2-13: CH to list the possible options for image file transfer. (Response | received 3 Jul '91). XM2-14: HEH to discuss with MSC the appointment of 'package managers' from Italian members of the consortium. XM2-15: HEH to investigate provision of software tool(s) to automate module documentation. H.E.Huckle MSSL 1 July 91