burzio@mmlai.UUCP (Anthony Burzio) (09/09/88)
In article <1626@sjuvax.UUCP>, ryan@sjuvax.UUCP (P. Ryan) writes: > Problem 2. > > The Cdb debugger on both the 318 and the 350 does not handle the 25' monitors > correctly (term=300h). It scrolls right of the screen in window mode. This > is particularly frustrating since we are using HP software on HP machines. > Arrrgh! I have problems with my SRX screen too. It seems EMACS (UNIPRESS) just doesn't like HPs' terminfo entrys. Unfortunately, not just the 300h terminal is affected; the vt100 driver, both from a "real" vt100 and in the X Window xterm, doesn't work either. The main problem seems to be mistakes in the scrolling region and the update of the cursor. VT100: - When moving the cursor upward through a region of blank lines the cursor will just stick in the middle. After a refresh, however, the cursor will pop up in the correct position. - When you delete a line which is blank, and there happens to be a line *with* text after it, the second next line will be scrolled up to cover it. SRX: - When you page forward, the reverse video buffer description is scrolled to the middle of the page, the correct text is overwritten, but the reverse video characteristic is left on. (weird :-) ) Anybody at HP have any idea why the terminfos are so messed up? Does anybody else have UNIPRESS EMACS on a 350SRX? I don't think it is UNIPRESS' problem, since the software works fine on VAX/ULTRIX... I have called UNIPRESS and have checked their VT100 terminfo entry and it is the same as HPs' entry. HELP! My boss wants to use EMACS soon, and I am running out of stall excuses! ****************************************************************************** Tony Burzio * Grrr.... Martin Marietta Laboratories * Whatta ya mean I can't use a VT100????? ******************************************************************************
mike@hpfcdc.HP.COM (Mike McNelly) (09/09/88)
Problem 1. > I worked at Goddard Space Flight Center this past summer converting Fortran > code from an HP A900 to 9000 series workstations. Since both the 835 and > the 3XX machines run HP-UX, they are supposed to be source-code compatible. > They aren't. There is great difficulty in calling C routines from Fortran > compiled on the 835. There are even problems compiling the code. Compiler > directives are different on the two machines. Has anyone else experienced > these problems? > ... > -- > /patrick/ryan > st. joseph's university > uucp { allegra | astrovax | bpa | burdvax } ! sjuvax ! ryan > arpa/csnet ryan@sjuvax.sju.edu We are aware that differences between the two systems are aggravating. As you know, the Series 800 and Series 300 machines are built upon two vastly different architectures and we have not yet succeeded in making the compilers for these two systems appear identical although I believe significant progress has been made recently and we are continuing to work on the problem. We are also working on the portibility problems between HP-UX machines and related machines from other vendors. In many cases these are competing goals. I would be happy to discuss specifics with you for our mutual benefit. My personal knowledge is mostly with Series 300 although I can contact those people working on the Series 800 if necessary. Mike McNelly hplabs!hpfcla!mike
cdb@hpclcdb.HP.COM (Carl Burch) (09/13/88)
>Problem 1. >I worked at Goddard Space Flight Center this past summer converting Fortran >code from an HP A900 to 9000 series workstations. Since both the 835 and >the 3XX machines run HP-UX, they are supposed to be source-code compatible. >They aren't. There is great difficulty in calling C routines from Fortran >compiled on the 835. Generically, whoever told you the machines were "source code compatible" was telling you the truth, but didn't tell you what that meant - that the same program in a given language will compile and run the same. ------------------- Multi-language programming is implementation-dependent on anybody's machine. You always have to emulate the calling language's calling sequence in the callee (or, less often, vice versa). You presumably ran into a case where the conventions (probably in Fortran) differ between the two implementations. Calling C from Fortran isn't harder on the S800, only different. You don't say, but the main case I've seen is with regard to character arguments. Fortran/S300 passes character items by a split descriptor (the address in the usual parameter list and the length tacked onto the end of the list). Fortran/S800 uses inline descriptors by default (address immediately followed by the length word). The length word is required in FORTRAN 77 to implement the CHARACTER*(*) feature. You might notice the word "default" above. We observed problems like yours about a year ago and consequentially developed two compiler directives that let you control what Fortran/S800 does in regard to character variables : $HP9000 CHARS to make the S800 pass character arguments like the S300 and $FTN3000_66 CHARS to dispense with the length word altogether (which some Fortran 66 programs expect). These directives were released to customers this past summer. If you'll send me e-mail, I'll see if I can help with any other differences you might have found. >There are even problems compiling the code. Compiler >directives are different on the two machines. Has anyone else experienced >these problems? Yes, most notably our management. ;-) That's why the top priority for both the Fortran compiler teams for the last year has been converging these differences. If you'll e-mail me the directives you were trying to use, I'll get their current convergence status for you. One of the features the S800 (and soon the S300) compiler has to handle the larger number of inline directives on the S800 is the +Q <file> command line option, which pulls in <file> ahead of the files being compiled. If <file> has the directives you need to control a global feature of the language (e.g., $HP9000 CHARS) you can maintain the same source across both S300 and S800 without having to edit in the directives to keep compatibility with your C source. >Problem 2. >The Cdb debugger on both the 318 and the 350 does not handle the 25' monitors >correctly (term=300h). It scrolls right of the screen in window mode. This >is particularly frustrating since we are using HP software on HP machines. >Arrrgh! I'm not the right person to answer this problem, but I'll pass this along to the people who are. >Any feedback/advice is appreciated. Any feedback/advice is appreciated by us, too - we're here to solve your problems, not just to read notes. :-) Carl Burch HP Fortran Lab hpda%cdb@hplabs.HP.COM {the world}!hplabs!hpda!cdb
cdb@hpclcdb.HP.COM (Carl Burch) (09/14/88)
> Your address is incorrect in your posting to comp.sys.hp. You had: > hpda%cdb@hplabs.HP.COM > and it should be: > cdb%hpda@hplabs.hp.com I have to learn to type one of these days. Thanks, - Carl
markm@hpfcdc.HP.COM (Mark McDowell) (09/16/88)
Concerning problem 2, quoting from the Update_info document...
Special note
------------
Certain terminal characteristics are required to support the new
terminal window features and the debuggers attempt to determine
at runtime if these are available. If they are not, the default
is a line-oriented mode. However, for some terminals, the
debuggers will incorrectly attempt to use terminal windows even
though all of the necessary capabilities are not available. If
you notice strange screen behavior, you can force line-oriented
debugging with one of the following functions or aliases:
If your command interpreter is "sh":
cdb() { env TERM= /bin/cdb $*; }
If it is "csh":
alias cdb 'env TERM= /bin/cdb'
Or for "ksh":
alias cdb='TERM= /bin/cdb'
The same methods can be used for fdb and pdb, also.
This problem has been fixed in the next release.
Mark McDowell