danny@idacom.uucp (Danny Wilson) (02/19/90)
A while back I ported a UNIX program to SR9.7 and enhanced its
output because of the way PADs handle character output.
The original (unix) program implemented a 'counting' type display
by printing a number followed by a CR. (a la..
for (i=0,i<10,i++)
printf("Value is %d\r", i)
printf("file transfer complete\n")
Running on a PAD, since all the characters would get queued up in the
transcript pad, it didn't create the same effect.
So, I enhanced the program to create a little window at the top of
the pad to display the 'counting' numbers in. It went something like:
inquire about stdout;
if it is of type pad_$uid, then
create a little window with frame
open a stream to that window/frame
put the output there
else
put the output to stdout
However, now that we've upgraded to SR10.1, the program no longer works!
The inquiry about ios_$stdout yields that it is of type "input_pad_$uid"
instead of simply "pad_$uid".
WHY? I can't really see why the "output" should be of type "input"... etc
Has anyone out there seen this weirdness and can explain it?
(Code segments below )
(lots of detail removed!)
attr.strid = ios_$stdout; /* inquire about stdout */
stream_$inquire(input_mask, stream_$use_strid, attr, error, status);
ob_type = attr.otype; /* now know where output is going */
/* if it's a pad, then create a little window and put the ouput there */
if (ob_type == pad_$uid)
pad_$create(" ", 0, pad_$transcript, ios_$stdout, pad_$top,
pad_$abs_size, 1, str_out, status);
if ((ob_type == pad_$uid) || (ob_type == input_pad_$uid))
{
/* create a frame to display the block count in */
pad_$create_frame(str_out, (short)80, (short)20, status);
frame_id = fdopen(str_out, "w");
}
else
frame_id = stdout; /* block count to stdout */
for (i=0; i<5; i++) {
/* only put returns if not to a file or a mailbox(crp) */
if (ob_type != mbx_$uid && ob_type != uasc_$uid)
{
fprintf(frame_id, "Block number %d\r", i);
fflush(frame_id);
}
/* close frame, stream, window et al */
--
Danny Wilson danny@idacom.uucp
IDACOM Electronics alberta!idacom!danny
Edmonton, Alberta X.400 danny@idacom.cs.ubc.cdn
C A N A D A Voice +1 403 462 4545dbfunk@ICAEN.UIOWA.EDU (David B Funk) (02/20/90)
In posting <1990Feb18.230542.24066@idacom.uucp> Danny Wilson writes: >A while back I ported a UNIX program to SR9.7 and enhanced its >output because of the way PADs handle character output. [stuff deleted] >So, I enhanced the program to create a little window at the top of >the pad to display the 'counting' numbers in. It went something like: > > inquire about stdout; > if it is of type pad_$uid, then > create a little window with frame > open a stream to that window/frame > put the output there > else > put the output to stdout > >However, now that we've upgraded to SR10.1, the program no longer works! > >The inquiry about ios_$stdout yields that it is of type "input_pad_$uid" >instead of simply "pad_$uid". > >WHY? I can't really see why the "output" should be of type "input"... etc >Has anyone out there seen this weirdness and can explain it? My guess is that you've been hit with more JLRU. At sr10, the "tty" command will return a "tty device" for any interactive shell, even a DM pad. Thus the "tty" for your DM window is its transcript pad, "/dev/display" and all those "/dev/pad*" thingies. Unix expects "/dev/tty" to be both readable and writeable, and can't understand the idea of having std-in and std-out going to 2 different types of "devices" for the same "/dev/tty". Thus if you look at all your standard streams for your shell in a DM window using the "/com/lopstr" tool, you'll see that they are all "input pad". One workaround for this that is OS rev independent: at sr10 they've finally documented the DM pad call "pad_$isa". Give this little gem your std-out or other stream, and it'll return a status of OK if its to a DM pad, error otherwise. I can see where this'll become important when there's more X stuff around. Then a window may not be a DM pad. Dave Funk
chen@digital.sps.mot.com (Jinfu Chen) (02/22/90)
In article <1990Feb18.230542.24066@idacom.uucp> danny@idacom.uucp (Danny Wilson) writes: > >A while back I ported a UNIX program to SR9.7 and enhanced its >output because of the way PADs handle character output. > >The original (unix) program implemented a 'counting' type display >by printing a number followed by a CR. (a la.. > > for (i=0,i<10,i++) > printf("Value is %d\r", i) > printf("file transfer complete\n") > >Running on a PAD, since all the characters would get queued up in the >transcript pad, it didn't create the same effect. >So, I enhanced the program to create a little window at the top of >the pad to display the 'counting' numbers in. It went something like: Instead of using a pad (frame?), one can turn off the input pad cooked mode and make it behave JLRU (:-). Here is a short program to demonstrate that: #include <apollo/base.h> #include <apollo/error.h> #include <apollo/pad.h> #include <stdio.h> main() { status_$t status; int i; pad_$raw(ios_$stdin, &status); printf("i = "); for (i = 0; i < 10; i++) { printf("%d ", i); fflush(stdout); sleep(1); } printf("\n"); pad_$cooked(ios_$stdin, &status); } Of course, a real program needs some more checking, such as the pad_$isa call and error checking of the returned status. I do have another question relating to PAD. Is there a way to check if I 'own' the display manager from a program. The reason for this is for the DM editor program someone posted a while ago. If I run a program which would call pad_$create on a remote node via crp or telnet/rsh/rlogin, I can open up a pad on that remote node even I don't 'own' the DM over there. This could be quite annoying to the user on the remote node. The only way I can think of is to check the owner of process 'display_manager'. -- Jinfu Chen (602)898-5338 | Disclaimer: Motorola, Inc. Logic IC Div., Mesa, AZ | ...{somewhere}!uunet!dover!digital!chen | My employer doesn't pay chen@digital.sps.mot.com | me to express opinions.
lambert@spinifex.eecs.unsw.oz (Timothy Lambert) (03/04/90)
In article <48c84a4e.12c9a@digital.sps.mot.com> chen@digital.sps.mot.com (Jinfu Chen) writes:
I do have another question relating to PAD. Is there a way to check
if I 'own' the display manager from a program. The only way I can
think of is to check the owner of process 'display_manager'.
Under SR 10.2 pad_$dm_cmd returns pad_$insuff_rights if you don`t own
the display manager.
Tim