Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!sunybcs!boulder!hao!oddjob!mimsy!eneevax!umd5!brl-adm!adm!Postmaster%FINFUN.BITNET@WISCVM.WISC.EDU From: Postmaster%FINFUN.BITNET@WISCVM.WISC.EDU (PMDF Mail Server) Newsgroups: comp.unix.questions Subject: Undeliverable mail Message-ID: <9711@brl-adm.ARPA> Date: Fri, 9-Oct-87 07:50:22 EDT Article-I.D.: brl-adm.9711 Posted: Fri Oct 9 07:50:22 1987 Date-Received: Sun, 11-Oct-87 13:54:32 EDT Sender: news@brl-adm.ARPA Lines: 180 The message could not be delivered to: Addressee: pietilainen Reason: %MAIL-E-NOSUCHUSR, no such user PIETILAINEN at node OPMVAX ---------------------------------------- Received: from FINFUN.BITNET by OPMVAX.KPO.FI; Fri, 9 Oct 87 12:14 N Received: From WISCVM(SMTP) by FINFUN with RSCS id 7810 for PIETILAI@FINFUN; Fri, 9 Oct 87 12:14 O Received: from SEM.BRL.MIL by WISCVM.WISC.EDU ; Fri, 09 Oct 87 03:27:05 CDT Received: by SEM.BRL.ARPA id ab07669; 7 Oct 87 3:27 EDT Received: from SEM.BRL.MIL by SEM.brl.ARPA id ab07553; 7 Oct 87 3:00 EDT Received: from sem.brl.mil by SEM.BRL.ARPA id aa07515; 7 Oct 87 2:45 EDT Date: Wed, 07 Oct 87 02:45:33 EST From: The Moderator Subject: INFO-UNIX Digest V4#037 To: INFO-UNIX@BRL.ARPA Reply-to: INFO-UNIX@BRL.ARPA Message-ID: <8710070245.aa07515@SEM.BRL.ARPA> INFO-UNIX Digest Wed, 07 Oct 1987 V4#037 Today's Topics: Re: Looking for a high-quality digital voice synthesiser Re: VI questions Re: question about signal ----------------------------------------------------------------- From: apn@nonvon.uucp Subject: Re: Looking for a high-quality digital voice synthesiser Date: 3 Oct 87 16:35:42 GMT To: info-unix@SEM.BRL.MIL ------------ Whatson used to have an 800 number for demo purposes, and... I found thier product acceptable, but not as good as something that Vynet has. I'm not sure, though, if Vynet is currently offering it for sale as a stand- alone card for PC's or Unix or whatever... The Person to contact ( I don't know Vynets number, but this is the individual who is responsible for most of the development of this product ) This product is currently in use in multiline IAS systems throughout the USA Durand Interstellar (408) 356 3886 Good Luck, Dr Phelps, Alex P Novickis (707) 575 9616 -- UUCP: {ihnp4,ames,qantel,sun,amdahl,lll-crg,pyramid}!ptsfa!nonvon!apn {* Only those who attempt the absurd ... will achieve the impossible *} {* I think... I think it's in my basement... Let me go upstairs and check. *} {* -escher *} -- UUCP: {ihnp4,ames,qantel,sun,amdahl,lll-crg,pyramid}!ptsfa!nonvon!apn {* Only those who attempt the absurd ... will achieve the impossible *} {* I think... I think it's in my basement... Let me go upstairs and check. *} {* -escher *} ----------------------------- From: Karel van Houten Subject: Re: VI questions Date: 5 Oct 87 08:08:29 GMT Keywords: VI, Bells To: info-unix@SEM.BRL.MIL In article <3050@uwmcsd1.UUCP> zhao@csd4.milw.wisc.edu.UUCP (T.C. Zhao) writes: > >2. I remember a while back someone mentioned ' visual bells' in Vi, >that is instead of a bell the screen flashes should an error occur. >Can someone tell me how to do this ? This has to be defined in the TERMCAP (file or environment variable). Below is my entry for a CIT101 terminal. When you want to put these commands in a file, don't forget you must use 'source file...', otherwise the environment of the subshell will be set only. Please note the 'vb' entry, This will reverse the screen, send some NULLs, and reverse it again. setenv TERM cit101n setenv TERMCAP 'd1|cit101n:al=\E[L:\ :am:bs:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:co#80:\ :cs=\E[%i%d;%dr:dc=\E[P:dl=\E[M:ei=:ic=\E[@:im=:kd=\E[B:\ :kl=\E[D:kr=\E[C:ku=\E[A:li#24:nd=\E[C:pt:se=\E[m:so=\E[1m:\ :ue=\E[m:up=\E[A:us=\E[4m:\ :vb=\E[?5h\200\200\200\200\200\200\200\200\200\200\200\200\E[?5l:\ :xn:xv:k0=\EOP:k1=\EOQ:k2=\EOR:k3=\EOS:k4=\EOw:k5=\EOx:k6=\EOy:\ :k7=\EOm:k8=\EOt:k9=\EOu:l0=PF1:l1=PF2:l2=PF3:l3=PF4:sf=\ED:\ :sr=\EM:vs=\E[5v\E\=:ve=\E[4v\E>' -- Karel van Houten BITNET : NO! NO! NO! Delft University of Technology INTERNET : karel@dutesta.UUCP Faculty of Electrical Engineering UUCP : ..!mcvax!dutrun!dutesta!karel Room 9.29H, Mekelweg 4 SURFnet : DUTRUN::KAREL 2628 CD DELFT, The Netherlands VOICE : +31 15 783502 ----------------------------- From: "John Woods, Software" Subject: Re: question about signal Date: 5 Oct 87 22:56:00 GMT To: info-unix@SEM.BRL.MIL In article <4248@udenva.UUCP>, rneitzel@udenva.UUCP (RICHARD NEITZEL ) writes: > In article <720001@hpclmar.HP.COM> mar@hpclmar.HP.COM (Michelle Ruscetta) writes: > > Question about signal(): > > Should the return from a signal handling routine specified by a call > > to signal() go to the instruction which caused the signal, or to the > > instruction immediately following that which caused the signal? > > void (*p_my_handler)(); > > main() > > { > > extern void my_handler(); > > int y = 0; > > int x = 3; > > p_my_handler = my_handler: > > signal(SIGFPE, p_my_handler); > > x = x/y; /* should my_handler return to here? */ > > printf("return from signal\n"); /* or to here? */ > > } > I would argue that the signal should return to the instruction causing the problem, if it returns at all. Presumably, your handler will either fix up the problem to allow the instruction to complete correctly (e.g., it would determine that one of the arguments is 0.0, print a message, stuff a 1.0 into the register or temporary, and return), it would bypass the effects of the instruction and advance the program counter that will be returned to (e.g., it prints a message, stores an IEEE infinity into the result of the instruction (register, memory location, whatever), bumps the PC, and returns), or it prints out an error message, maybe a stack backtrace, and craps out again with a core dump. Note that two of these aren't portable things. Furthermore, they may become impossible in processors with separate, asynchronous, floating point units (e.g. the venerable PDP-11), or with lots of internal pipelining: how does one "properly" re-do divf fr0,fr1 inc r0 addf fr1,fr2 if the divf gets an exception AFTER the 'inc r0' has executed? In short, it is probably easiest to offer to repair damage from an exception if the exception handler is told which instruction faulted and is allowed to return to it, but in the *general* case the only useful thing a signal handler can do in this case is: my_FPE_handler() { fprintf(stderr,"Ah, geez, a floating point exception happened!\n"); abort(); } -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw@eddie.mit.edu "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ----------------------------- End of INFO-UNIX Digest ***********************