e07@nikhefh.hep.nl (Eric Wassenaar) (10/25/88)
The SR10 librarian (lbr) has lost almost all functionality provided by the SR9 and previous versions. It is a completely different utility now. Its new primitive behaviour is just like that of the unix 'ar' utility. This is particularly cumbersome in fortran-oriented environments, with certain methods for source code and library management. Suppose one has a big source file foo.ftn containing many fortran source modules. Compilation results in one object file foo.bin containing all object modules. The old lbr would be able to put those object modules as individual entries into a library, which could be loaded as needed. The new lbr just puts the whole foo.bin as one entry into the library. If one loads from this library, and needs only a few modules, one gets everything. The old lbr could also give extensive information about the contents of a library and its modules, like defined entry points, externals, common blocks used, and numerous statistical data. Several years ago, the high-energy physics community, as one of the big fortran user groups, has urged Apollo to provide a sophisticated librarian with the same functionality as found in other heavy fortran oriented environments. The fact that such utility was quickly provided, was one of the reasons to remain in favor of Apollo workstations. It is disappointing to notice that compatibility with previous releases is now broken. Does Apollo have any short term plans to enhance the librarian to provide the same functionality as it had before? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 5920412 Home phone: +31 20 909449 Telex: 10262 (hef nl) Internet: e07@nikhefh.hep.nl Bitnet: nikhefh!e07@mcvax.bitnet
geiser@apollo.COM (Wayne Geiser) (11/03/88)
>The SR10 librarian (lbr) has lost almost all functionality provided by >the SR9 and previous versions. It is a completely different utility now. >Its new primitive behaviour is just like that of the unix 'ar' utility. The librarian has not changed. The object format the compilers produce has changed. Prior to SR10, the object module format was "allowed" to contain concatenated binaries (e.g. a module that had several FORTRAN subprograms would create one binary file with several completely separate object modules). This is the reason that one had to bind all FORTRAN programs that had more than just a PROGRAM subprogram. When this was fed to the librarian, it was able to take each of these object modules and make a separate entry in the library for each. At SR10 (and later, of course), the compilers produce COFF standard binary files. This AT&T standard will not "allow" multiple object modules per binary file. For this, and several less important reasons, we were forced to have the FORTRAN compiler place only one object module in each binary file. The librarian sees only one object module and enters only it in the library. >This is particularly cumbersome in fortran-oriented environments, with >certain methods for source code and library management. >Suppose one has a big source file foo.ftn containing many fortran source >modules. Compilation results in one object file foo.bin containing all >object modules. >The old lbr would be able to put those object modules as individual >entries into a library, which could be loaded as needed. >The new lbr just puts the whole foo.bin as one entry into the library. >If one loads from this library, and needs only a few modules, one gets >everything. >The old lbr could also give extensive information about the contents >of a library and its modules, like defined entry points, externals, >common blocks used, and numerous statistical data. > >Several years ago, the high-energy physics community, as one of the >big fortran user groups, has urged Apollo to provide a sophisticated >librarian with the same functionality as found in other heavy fortran >oriented environments. The fact that such utility was quickly provided, >was one of the reasons to remain in favor of Apollo workstations. > >It is disappointing to notice that compatibility with previous releases >is now broken. Does Apollo have any short term plans to enhance the >librarian to provide the same functionality as it had before? Unfortunately, we see no way to keep the past functionality and still continue with our policy of standards conformance. We do, however, have a workaround. A shell script can be easily written (if you'd rather not write it yourself, let me know and I'll dig up the one I wrote) to temporarily split the file into subprograms, compile them, and place the resulting binaries in a library. In this way, you may still continue to maintain your sources in one (or several) huge files and yet get each subprogram listed separately in the library. >Eric Wassenaar >-- >Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics >Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands >Phone: +31 20 5920412 Home phone: +31 20 909449 Telex: 10262 (hef nl) >Internet: e07@nikhefh.hep.nl Bitnet: nikhefh!e07@mcvax.bitnet -- Wayne Geiser Apollo Computer, Inc. {mit-erl, yale, uw-beaver, decvax}!apollo!geiser
achille@cernvax.UUCP (achille) (11/04/88)
In article <3f6dd85c.ba7d@apollo.COM> geiser@apollo.COM (Wayne Geiser) writes: ... (stuff deleted) ... >We do, however, have a workaround. A shell script can be easily written (if >you'd rather not write it yourself, let me know and I'll dig up the one I >wrote) to temporarily split the file into subprograms, compile them, and place >the resulting binaries in a library. In this way, you may still continue to ... (stuff delete) ... >Wayne Geiser >Apollo Computer, Inc. Your workaround is fine, but what about the debugger ??? will the debugger be able to understand that the source of the files are in one huge file and not in a few hundreds small files ??? People don't really want to keep around both the huge source file and the split-up one-routine-per-file sources. We are talking about sources of size 1MB and over. Achille Petrilli, Cray & PWS operations
e07@nikhefh.hep.nl (Eric Wassenaar) (11/08/88)
In <558@nikhefh.hep.nl> e07@nikhefh.hep.nl (Eric Wassenaar) wrote: >>The SR10 librarian (lbr) has lost almost all functionality provided by >>the SR9 and previous versions. It is a completely different utility now. >>This is particularly cumbersome in fortran-oriented environments, with >>certain methods for source code and library management. >>Several years ago, the high-energy physics community, as one of the >>big fortran user groups, has urged Apollo to provide a sophisticated >>librarian with the same functionality as found in other heavy fortran >>oriented environments. The fact that such utility was quickly provided, >>was one of the reasons to remain in favor of Apollo workstations. >>It is disappointing to notice that compatibility with previous releases >>is now broken. Does Apollo have any short term plans to enhance the >>librarian to provide the same functionality as it had before? In <3f6dd85c.ba7d@apollo.COM> geiser@apollo.COM (Wayne Geiser) replied: >Prior to SR10, the object module format was "allowed" to contain concatenated >binaries. When this was fed to the librarian, it was able to take >each of these object modules and make a separate entry in the library for each. >At SR10 (and later, of course), the compilers produce COFF standard binary >files. This AT&T standard will not "allow" multiple object modules per binary >file. For this, and several less important reasons, we were forced to have the >FORTRAN compiler place only one object module in each binary file. The >librarian sees only one object module and enters only it in the library. >Unfortunately, we see no way to keep the past functionality and still continue >with our policy of standards conformance. >We do, however, have a workaround. A shell script can be easily written >to temporarily split the file into subprograms, compile them, and place >the resulting binaries in a library. I understand the reasons behind the change, but I want to mention again some disadvantages of this approach in a heavy fortran development environment. There is a big overhead in splitting a large source file into numerous separate files, and invoking the compiler for each individual file. One is forced to keep all individual files for debugging purposes, since line numbers are relative to the input file to the compiler. This is an adminstrative burden. The old lbr could also give extensive information about the contents of a library and its modules, like defined entry points, externals, common blocks used, and numerous statistical data. This feature has disappeared. The old situation provided facilities closely resembling those found in traditional fortran environments (like Cray, CDC or IBM mainframes, or VAX/VMS). The new situation is a step backward, albeit is the name of standards. Perhaps certain applications need other standards... Physicists don't choose Apollo because of its standards. Physicists choose Apollo because of its superior characteristics to solve their particular problems. E.g. if they want high quality graphics, they use GMR, not GKS. They would even use GSR, if appropriate. I cannot imagine Apollo abandoning such products in the future, although that would be a bigger and more practical step towards standards and portability than adapting COFF format for executables. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 5920412 Home phone: +31 20 909449 Telex: 10262 (hef nl) Internet: e07@nikhefh.hep.nl Bitnet: nikhefh!e07@mcvax.bitnet
geiser@apollo.COM (Wayne Geiser) (11/11/88)
>In <558@nikhefh.hep.nl> e07@nikhefh.hep.nl (Eric Wassenaar) wrote: >>>The SR10 librarian (lbr) has lost almost all functionality provided by >>>the SR9 and previous versions. It is a completely different utility now. >>>This is particularly cumbersome in fortran-oriented environments, with >>>certain methods for source code and library management. >>>Several years ago, the high-energy physics community, as one of the >>>big fortran user groups, has urged Apollo to provide a sophisticated >>>librarian with the same functionality as found in other heavy fortran >>>oriented environments. The fact that such utility was quickly provided, >>>was one of the reasons to remain in favor of Apollo workstations. >>>It is disappointing to notice that compatibility with previous releases >>>is now broken. Does Apollo have any short term plans to enhance the >>>librarian to provide the same functionality as it had before? > >In <3f6dd85c.ba7d@apollo.COM> geiser@apollo.COM (Wayne Geiser) replied: >>Prior to SR10, the object module format was "allowed" to contain concatenated >>binaries. When this was fed to the librarian, it was able to take >>each of these object modules and make a separate entry in the library for each. >>At SR10 (and later, of course), the compilers produce COFF standard binary >>files. This AT&T standard will not "allow" multiple object modules per binary >>file. For this, and several less important reasons, we were forced to have the >>FORTRAN compiler place only one object module in each binary file. The >>librarian sees only one object module and enters only it in the library. >>Unfortunately, we see no way to keep the past functionality and still continue >>with our policy of standards conformance. >>We do, however, have a workaround. A shell script can be easily written >>to temporarily split the file into subprograms, compile them, and place >>the resulting binaries in a library. > >I understand the reasons behind the change, but I want to mention again some >disadvantages of this approach in a heavy fortran development environment. > >There is a big overhead in splitting a large source file into numerous >separate files, and invoking the compiler for each individual file. Agreed. >One is forced to keep all individual files for debugging purposes, since >line numbers are relative to the input file to the compiler. This is an >adminstrative burden. Not so. When this problem was discovered a solution was implemented. It involves placing %LINE <number>[,<file>] directives in each "split-out" file so as to point back to the original file. This can be done automatically by the same shell script that breaks the sources apart (it is in the one I wrote). Note: Don't look for %LINE before SR10.1. >The old lbr could also give extensive information about the contents of a >library and its modules, like defined entry points, externals, common blocks >used, and numerous statistical data. This feature has disappeared. I'm sorry, I don't know enough about lbr to address this point. >The old situation provided facilities closely resembling those found in >traditional fortran environments (like Cray, CDC or IBM mainframes, or VAX/VMS). >The new situation is a step backward, albeit is the name of standards. >Perhaps certain applications need other standards... > >Physicists don't choose Apollo because of its standards. Physicists choose >Apollo because of its superior characteristics to solve their particular >problems. E.g. if they want high quality graphics, they use GMR, not GKS. >They would even use GSR, if appropriate. I cannot imagine Apollo abandoning >such products in the future, although that would be a bigger and more >practical step towards standards and portability than adapting COFF format >for executables. > >Eric Wassenaar >-- >Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics >Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands >Phone: +31 20 5920412 Home phone: +31 20 909449 Telex: 10262 (hef nl) >Internet: e07@nikhefh.hep.nl Bitnet: nikhefh!e07@mcvax.bitnet I'm sorry, I thought you wished to have a technical conversation on the problem you were having. I understand your complaints. However, we must follow the direction that Marketing tells us (through research) will generate the most customers (and, therefore, the most money). If you wish to argue that the direction Apollo has chosen is not the best, someone from the Marketing organization will have to take over. -- Wayne Geiser Apollo Computer, Inc. {mit-erl, yale, uw-beaver, decvax}!apollo!geiser
casey@admin.cognet.ucla.edu (Casey Leedom) (11/11/88)
| From: geiser@apollo.COM (Wayne Geiser) | | | From: e07@nikhefh.hep.nl (Eric Wassenaar) | | | | One is forced to keep all individual files for debugging purposes, since | | line numbers are relative to the input file to the compiler. This is an | | administrative burden. | | Not so. When this problem was discovered a solution was implemented. It | involves placing %LINE <number>[,<file>] directives in each "split-out" | file so as to point back to the original file. This can be done | automatically by the same shell script that breaks the sources apart (it | is in the one I wrote). Note: Don't look for %LINE before SR10.1. | | I'm sorry, I thought you wished to have a technical conversation on the | problem you were having. | | I understand your complaints. However, we must follow the direction that | Marketing tells us (through research) will generate the most customers | (and, therefore, the most money). If you wish to argue that the | direction Apollo has chosen is not the best, someone from the Marketing | organization will have to take over. What is this? Is Apollo just in the business of alienating customers now or what? He tells you there's a problem with your fix to his complaint, and then you come back at him ``no there isn't ... but yes there is (because his problem is with *SR10.0* - not your *SR10.1*)''. I'm not bothered by this particular problem because I don't do fortran, and if I did, I would probably use separate files - it's just a lot more convenient. But I really feel sorry for Eric having to battle this typical egocentric Apollo attitude. Apollo seems to feel that the world revolves about themselves and damn anyone who thinks differently. You should have replied: ``You're right. This is a problem. We've worked out a solution that involves placing placing %LINE <number>[,<file>] directives in each "split-out" file so as to point back to the original file. This can be done automatically by the same shell script that breaks the sources apart (it is in the one I wrote). Unfortunately this new %LINE directive won't be available till SR10.1. We're sorry for the inconvenience. If this is a debilitating problem we can send you a new compiler and our new shell script to tide you over till SR10.1 comes out.'' I think we all understand that standards are important, but customer support is your primary duty. If you don't have that, you'll just continue to lose market share. As Eric said (paraphrased :-)) ``If it's standard but doesn't work, it isn't worth shit.'' Casey
icsu6000@CAESAR.CS.MONTANA.EDU (Mathisen) (11/13/88)
> What is this? Is Apollo just in the business of alienating customers > now or what? He tells you there's a problem with your fix to his > complaint, and then you come back at him ``no there isn't ... but yes > there is (because his problem is with *SR10.0* - not your *SR10.1*)''. > > I'm not bothered by this particular problem because I don't do fortran, > and if I did, I would probably use separate files - it's just a lot more > convenient. But I really feel sorry for Eric having to battle this > typical egocentric Apollo attitude. Apollo seems to feel that the world ^^^^^^^^^^^^^^^^^^^^^^^^^ Amen!! > revolves about themselves and damn anyone who thinks differently. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Another Amen. > > I think we all understand that standards are important, but customer > support is your primary duty. If you don't have that, you'll just > continue to lose market share. As Eric said (paraphrased :-)) ``If it's > standard but doesn't work, it isn't worth shit.'' > Casey Hear Hear!! I couldn't agree more. I manage about 40 workstations and VAXen for the College of Engineering here at Montana State. I can easily say that Apollo has the worst support of any of the vendors that we have, (Apollo,HP,Tek,DEC -- No Sun's). We have 19 Apollo's yet, I can't even get a sales rep to return my phone calls the same week. I've got technical questions into the 2APOLLO number that haven't even been replied to, and it's going on 6 months now, after a couple of call backs to remind them. This coupled with lousy software (great ideas, but lousy implementation) has led me to recommend that our next workstation purchase NOT be Apollo. Don't know which of the others I would choose (probably HP), but definitely not Apollo. As of now, we're just chucking them in the garbage as they break, even if it's a little thing. It's too bad, because I like some of Apollo's ideas. I think that their filesystem is great, I like all of the kinky things you can do with links, the registry is OK, but I wish it was less tightly coupled, performance is average, the Display Manager is hunky-dory (it's my favorite window setup). But.... that's not enough to make me want to put up with all of the down sides, like only being able to fix msd1600 tape drives as a unit for 6700 bucks, miserable Ethernet performance, blah, blah , blah... Jaye Mathisen mathisen.sys_admin.sys_org systems manager icsu6000@caesar.cs.montana.edu Dept of Computer Science 410 Roberts Hall Montana State University, Bozeman, MT 59717
e07@nikhefh.hep.nl (Eric Wassenaar) (11/15/88)
In <3f960034.ba7d@apollo.COM> geiser@apollo.COM (Wayne Geiser) wrote: >This can be done automatically by the >same shell script that breaks the sources apart (it is in the one I wrote). Splitting up a fortran source file is not a trivial job. Utilities like the bsd or sysv 'fsplit' are inadequate, so your script has to be a lot smarter. 'Conditio sine qua non' is that the master file remains unedited. The following cases must be handled: 1. Labeled END statements. 2. Variables named END must not be confused with END statements. 3. Comments between two fortran modules must be put into the proper file. 4. Continuation lines must be recognized. 5. Blank lines between modules must be handled properly. 6. Unnamed modules must be recognized, e.g. BLOCK DATA. 7. File name clashes must be solved, e.g. in case a file already exists. >I'm sorry, I thought you wished to have a technical conversation on the problem >you were having. >I understand your complaints. However, we must follow the direction that >Marketing tells us (through research) will generate the most customers (and, >therefore, the most money). If you wish to argue that the direction Apollo has >chosen is not the best, someone from the Marketing organization will have to >take over. I assume that arguments going on in this newsgroup are discussed more widely in the Apollo organization, if appropriate. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 5920412 Home phone: +31 20 909449 Telex: 10262 (hef nl) Internet: e07@nikhefh.hep.nl Bitnet: nikhefh!e07@mcvax.bitnet
geiser@apollo.COM (Wayne Geiser) (11/19/88)
>In <3f960034.ba7d@apollo.COM> geiser@apollo.COM (Wayne Geiser) wrote: >>This can be done automatically by the >>same shell script that breaks the sources apart (it is in the one I wrote). > >Splitting up a fortran source file is not a trivial job. Utilities like the >bsd or sysv 'fsplit' are inadequate, so your script has to be a lot smarter. >'Conditio sine qua non' is that the master file remains unedited. >The following cases must be handled: >1. Labeled END statements. >2. Variables named END must not be confused with END statements. >3. Comments between two fortran modules must be put into the proper file. >4. Continuation lines must be recognized. >5. Blank lines between modules must be handled properly. >6. Unnamed modules must be recognized, e.g. BLOCK DATA. >7. File name clashes must be solved, e.g. in case a file already exists. I have played around with fsplit. Here are the results of my experimentation: 2, 4, 6, and 7 work just fine (at least with the BSD version). 3 and 5 all comments and blank lines following the END of a preceding subprogram get grouped with the current subprogram. 1 Confuses fsplit. > . > . > . > >Eric Wassenaar >-- >Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics >Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands >Phone: +31 20 5920412 Home phone: +31 20 909449 Telex: 10262 (hef nl) >Internet: e07@nikhefh.hep.nl Bitnet: nikhefh!e07@mcvax.bitnet Wayne. -- Wayne Geiser Apollo Computer, Inc. {mit-erl, yale, uw-beaver, decvax}!apollo!geiser