BABYL OPTIONS: Version: 5 Labels:athena,afs,bug-mwm,bug-motif-form,motif,olc,motif-bug,7-29,hellobaby,talk,argus,system,discuss,bug-runrules,feature-ruleeditor,bug-rsedit,bug-motif,xmlist,x-server,re,important Note: This is the header of an rmail file. Note: If you are seeing it in rmail, Note: it means the file has no messages in it.  1,,7-29, Summary-line: 20-Jul mackay@ATHENA.MIT.EDU #SIGGRAPH '89 volunteers Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23627; Thu, 20 Jul 89 13:26:08 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07032; Thu, 20 Jul 89 13:23:14 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA09371; Thu, 20 Jul 89 13:23:04 -0400 Message-Id: <8907201723.AA09371@E40-368-1.MIT.EDU> To: staff@ATHENA.MIT.EDU, video-mail@ATHENA.MIT.EDU Subject: SIGGRAPH '89 volunteers Date: Thu, 20 Jul 89 13:23:00 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU, video-mail@ATHENA.MIT.EDU Subject: SIGGRAPH '89 volunteers Date: Thu, 20 Jul 89 13:23:00 EDT Dick Phillips has asked for volunteers to demonstrate an "Interactive Proceedings" project, which runs on the NeXT computer. He'd like a few people who have experience with NeXT, but it's not a requirement. He'll have a session on Saturday, July 29, to go over how it works and how to demonstrate it. He is looking for a commitment of about 2 hours per day during the conference in exchange for free admission. If you are interested, call Dick Phillips at: (505) 665-1343. Wendy (Even if you aren't really a "graphics person", I still recommend that you take advantage of the fact that SIGGRAPH is in Boston this year. It's acm's premier conference and everyone works throughout the year to bring their best work to SIGGRAPH. The art show and computer graphics theater are especially worth seeing, and the exhibition is pretty overwhelming. I have extra SIGGRAPH advance programs (with registration materials) and SIGGRAPH calendars if you would like one. I've given Dan some complimentary exhibition tickets for SysDev, but have some more if you are in another group and would like to see the exhibition.)  1,,motif-bug, Summary-line: 20-Jul vanharen@ATHENA.MIT.EDU #bug with scrollbar widget, snap 9 Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24984; Thu, 20 Jul 89 14:37:29 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08613; Thu, 20 Jul 89 14:37:21 EDT Received: by FRIES.MIT.EDU (5.60/4.7) id AA08986; Thu, 20 Jul 89 14:37:12 EDT Message-Id: <8907201837.AA08986@FRIES.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU From: Chris VanHaren Subject: bug with scrollbar widget, snap 9 Date: Thu, 20 Jul 89 14:37:07 EDT Sender: vanharen@ATHENA.MIT.EDU *** EOOH *** To: motif-bugs@ATHENA.MIT.EDU From: Chris VanHaren Subject: bug with scrollbar widget, snap 9 Date: Thu, 20 Jul 89 14:37:07 EDT Sender: vanharen@ATHENA.MIT.EDU OSF UEC Problem Report ================================= Submitter Information --------------------- Submitter Name: Chris VanHaren Organization: MIT Project Athena Email Address: vanharen@athena.mit.edu Phone: (617) 253-0111 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot 9 Component (Module): Toolkit, Scrollbar (in ScrolledText instance of Text widget) OSF License Number: --- Client Hardware: VAXstation II/RC w/5 Meg ram Client Software: Unix 4.3 BSD w/Athena extensions, X11r3. Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: pcc Problem Description ------------------- Severity Level: Severe -- represents a problem which resulted in software functionality limitation but had alternative work-around. Date of First Occurrence: July 19, 1989 (07/19/89) One Line Description: Scrollbar (in ScrolledText instance of Text widget) does not display size correctly and causes toolkit warnings if resized and not at top of text in text widget. Full Description: (Interface code was written in UIL, but I assume the error is not there, and is actually in the widget. In case I am wrong, though, I figured I should mention that I did use UIL.) If ScrolledText widget is resized so that full text does not appear in text window, the scrollbar shrinks so as not to cover the entire scrolling region, as expected. Scrollbar is initially at top of scroll region, also as expected. If text is scrolled down by dragging the scrollbar, then the text widget is resized so that the whole text may be displayed, the scrollbar covers the entire scrolling region, even though not all of the text is displayed. At the same time, this warning is issued: X Toolkit Warning: Name: vbar Class: XmScrollBar The specified scrollbar value is greater than the maximum scrollbar value minus the scrollbar slider size. It can be "gotten around", sort of, by clicking in the text area (if you have left it sensitive), and scrolling up via the arrow keys, moving the text cursor up. When the text is scrolled up (using this method), the same warning (above) is issued again. When the text widget is again resized to be smaller than will hold the whole text, the text shown is the first few lines, but the scrollbar is at the bottom of the scrolling region. It would seem that there are a few problems occuring here, actually. (1) The scrollbar does not always get notified of the text scroll, as when you scroll via arrow keys in the text region. (2) The scrollbar does not figure out the correct size to be when the text widget is resized. Repeat By: Repeat steps above, using a ScrolledText widget that has a few lines of text in it (at least two, so that you can shrink the widget small enough so that not all lines are displayed). By "shrinking", I am referring to resizing the window containing the widget (using the window manager), where the widget is attached to the sides of the form. Proposed Solution: Not sure. Seems like callbacks for the text widget and scrollbar are not connected. Also seems like the resize portion of the scrollbar widget is incorrect. This is pure speculation, not having seen the widget code.  1,, Summary-line: 20-Jul maya@ATHENA.MIT.EDU #Re: Is this rule action possible? Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25935; Thu, 20 Jul 89 15:33:45 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09719; Thu, 20 Jul 89 15:32:57 EDT Received: by E40-358-18.MIT.EDU (5.60/4.7) id AA03078; Thu, 20 Jul 89 15:32:46 EDT Message-Id: <8907201932.AA03078@E40-358-18.MIT.EDU> To: bock@xanadu.enet.dec.com (BOSE A/D -- DTN 381-0898) Cc: alens@ATHENA.MIT.EDU Subject: Re: Is this rule action possible? In-Reply-To: Your message of 13 Jul 89 23:05:00 +0000. <8907140312.AA03021@decwrl.dec.com> Date: Thu, 20 Jul 89 15:32:40 EDT *** EOOH *** From: To: bock@xanadu.enet.dec.com (BOSE A/D -- DTN 381-0898) Cc: alens@ATHENA.MIT.EDU Subject: Re: Is this rule action possible? In-Reply-To: Your message of 13 Jul 89 23:05:00 +0000. <8907140312.AA03021@decwrl.dec.com> Date: Thu, 20 Jul 89 15:32:40 EDT Did anyone reply to Geoff's message about whether he can use Argus to sort messages in a priority order? I have a feeling that it can be done with a ruleset, but that you couldn't do it within the folder they started in. So, you'd create a rule that took messages from Maya and moved them to the "read-me" folder, then a message that took the ones from Wendy and moved them to that folder, then the ones from bgardner and put them in that folder. Since a message can only be from: one user at a time, there would be no overlaps. However, if you used a different scheme for ordering, say Subject: or To:, then there would be possible overlaps, and the ordering might not be perfect. This is my guess. Am I right, or does it not work the way I think? [I wouldn't be surprised!] --- Maya  1,,olc, Summary-line: 20-Jul carla@ATHENA.MIT.EDU #6.3B has been released to testers -- impact on OLC Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA26981; Thu, 20 Jul 89 16:21:42 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10722; Thu, 20 Jul 89 16:19:05 EDT Received: by RENOIR.MIT.EDU (5.61/4.7) id AA05573; Thu, 20 Jul 89 16:18:54 -0400 Message-Id: <8907202018.AA05573@RENOIR.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: 6.3B has been released to testers -- impact on OLC Date: Thu, 20 Jul 89 16:18:49 EDT From: Carla Fermann *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: 6.3B has been released to testers -- impact on OLC Date: Thu, 20 Jul 89 16:18:49 EDT From: Carla Fermann Release engineering has updated the testers packs. Any machine that is using the AFS testers packs or has been updated to 6.3B will, by default, contact the test olc server, which we currently are not supporting. If you get a message saying that you are not allowed to do something, find that the queue is empty, or notice any other strange behavior when trying to use OLC or OLCR, it means that you are using the new clients (which are trying to contact the new server). You can contact the old server by using the olcr in the "consult" locker. We hope to have reliable service (for testing) from the new server on Monday. Please let me know if you have any questions. Carla  1,, Summary-line: 20-Jul hoffmann@BITSY.MIT.EDU #Judith Provost: update Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA00343; Thu, 20 Jul 89 21:19:10 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15099; Thu, 20 Jul 89 21:17:01 EDT Received: by BITSY.MIT.EDU id AA01281; Thu, 20 Jul 89 20:16:50 EST Date: Thu, 20 Jul 89 20:16:50 EST From: hoffmann@BITSY.MIT.EDU (Ron M. Hoffmann) Message-Id: <8907210116.AA01281@BITSY.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Judith Provost: update Cc: berlan@BITSY.MIT.EDU *** EOOH *** Date: Thu, 20 Jul 89 20:16:50 EST From: hoffmann@BITSY.MIT.EDU (Ron M. Hoffmann) To: staff@ATHENA.MIT.EDU Subject: Judith Provost: update Cc: berlan@BITSY.MIT.EDU Ron Orcutt spoke with the floor staff at Mt. Auburn Hospital about 15 minutes ago. Judith's condition is being stated now as "quite stable and resting". She should be in the intensive care unit for a few days. I will call tomorrow morning (Friday) for information on visiting her and will forward same to the staff list. -Ron Hoffmann  1,, Summary-line: 20-Jul rap@ATHENA.MIT.EDU #demo outline Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA00960; Thu, 20 Jul 89 22:05:06 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15775; Thu, 20 Jul 89 22:05:02 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA01119; Thu, 20 Jul 89 22:04:25 EDT Date: Thu, 20 Jul 89 22:04:25 EDT Message-Id: <8907210204.AA01119@E51-007-12.MIT.EDU> To: mackay@ATHENA.MIT.EDU Cc: rap@ATHENA.MIT.EDU Subject: demo outline *** EOOH *** From: Date: Thu, 20 Jul 89 22:04:25 EDT To: mackay@ATHENA.MIT.EDU Cc: rap@ATHENA.MIT.EDU Subject: demo outline -R opens -- extra xterm -->icon -- mteditor MSG.bug-report -->icon -- rsedit of flash -->icon -- emacs of DMAIL and DMAIL-SMALL -->icon -- ruleeditor demo -W gives Argus overview (etcc..) -R -- edits new rule to be to or cc then send me a zephyr with the subject line while... -W goes into different field types . . . . . . . . . . types of boxes (as OR box is added) . . . . . . . . . . verbs (as move-to is changed to shell) -- runrules demo on DMAIL-SMALL while... -W goes into different folder types . . . . . . . . . . ways to invoke runrules (alinc, runrules, possibly zephyr) . . . . . . . . . . concept of rule sets as... -R deiconifies rule set editor of flash -W begins to explain the rule set editor. -R edits the first rule of the rule set showing the actions. -R deiconifies the emacs and shows the header list of DMAIL in emacs -R runrules flash on DMAIL. -W wraps up. or --optional part-- -W goes into message types while.. -R pops up the message type menu on the ruleeditor. -R deiconfies the message type editor showing view of an existing message type. -W wraps up.  1,, Summary-line: 20-Jul rap@ATHENA.MIT.EDU #the Motif meeting tomorrow Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01018; Thu, 20 Jul 89 22:08:56 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15841; Thu, 20 Jul 89 22:08:49 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA00859; Thu, 20 Jul 89 19:45:40 EDT Date: Thu, 20 Jul 89 19:45:40 EDT Message-Id: <8907202345.AA00859@E51-007-12.MIT.EDU> To: alens@ATHENA.MIT.EDU Cc: rap@ATHENA.MIT.EDU Subject: the Motif meeting tomorrow *** EOOH *** From: Date: Thu, 20 Jul 89 19:45:40 EDT To: alens@ATHENA.MIT.EDU Cc: rap@ATHENA.MIT.EDU Subject: the Motif meeting tomorrow I am sending this message to augment my meger supply of test data. __Rich Execuglide (eks ek' yew glyd)- v. To propel oneself about an office without getting up from the chair.  1,, Summary-line: 20-Jul rap@ATHENA.MIT.EDU #big font sizes for the demo Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01373; Thu, 20 Jul 89 22:41:35 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16297; Thu, 20 Jul 89 22:41:30 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA01179; Thu, 20 Jul 89 22:40:53 EDT Date: Thu, 20 Jul 89 22:40:53 EDT Message-Id: <8907210240.AA01179@E51-007-12.MIT.EDU> To: bgardner@ATHENA.MIT.EDU, thm@ATHENA.MIT.EDU, mackay@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU Subject: big font sizes for the demo *** EOOH *** From: Date: Thu, 20 Jul 89 22:40:53 EDT To: bgardner@ATHENA.MIT.EDU, thm@ATHENA.MIT.EDU, mackay@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU Subject: big font sizes for the demo I am using an alternative .Xresources file for the demo tomorrow which defines big fonts for the applications as follows... ruleeditor*Font:-adobe-courier-bold-r-normal--18-180-75-75-m-110-iso8859-1 emacs*Font:-adobe-courier-bold-r-normal--18-180-75-75-m-110-iso8859-1 mteditor*Font:-adobe-courier-bold-r-normal--18-180-75-75-m-110-iso8859-1 The problems is that rsedit core dumps when I try this with it. Brian, can you fix it? Wendy if he cannot, should I go ahead and show the ruleeditor and mteditor in big fonts? __Rich.  1,, Summary-line: 21-Jul bgardner@ATHENA.MIT.EDU #Skydiving Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03693; Fri, 21 Jul 89 06:43:57 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22012; Fri, 21 Jul 89 06:43:54 EDT Received: by M11-111-2.MIT.EDU (5.60/4.7) id AA12116; Fri, 21 Jul 89 00:25:45 EDT Date: Fri, 21 Jul 89 00:25:45 EDT Message-Id: <8907210425.AA12116@M11-111-2.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: Skydiving *** EOOH *** From: Date: Fri, 21 Jul 89 00:25:45 EDT To: rap@ATHENA.MIT.EDU Subject: Skydiving You forgot to give me your form. How about if you fill it out and put it on my chair ? I'll try to get there early enough to pick it up and bring it to Carl, in the skydiving club. Don't forget to bring $55 in cash, too. (they only take cash.) (Put it in an envelop on my chair ?? With my name on it.) -- Brian See you tomorrow.  1,, Summary-line: 21-Jul mackay@ATHENA.MIT.EDU #SIGGRAPH update on dates Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA04114; Fri, 21 Jul 89 08:45:35 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23123; Fri, 21 Jul 89 08:44:20 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA09803; Fri, 21 Jul 89 08:44:08 -0400 Message-Id: <8907211244.AA09803@E40-368-1.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: SIGGRAPH update on dates Date: Fri, 21 Jul 89 08:44:02 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Subject: SIGGRAPH update on dates Date: Fri, 21 Jul 89 08:44:02 EDT SIGGRAPH dates are: Monday, July 31 - Friday, August 4 courses: 7/31 - 8/1 Mon - Tue Local hotels (Boston and Cambridge) exhibit: 8/1 - 8/3 Tue - Thu Hynes Auditorium technical session: 8/2 - 8-4 Wed - Fri Hynes and Sheraton Boston art show: 7/31 - 8/1 Mon - Fri Hynes and Computer Museum computer graphics theater: 7/31 - 8/3 Mon - Thu Hynes (two shows on Tues night) The exhibition closes early on Thursday and the art show closes early on Friday, so keep that in mind if you plan to go for just one day. Wendy  1,, Summary-line: 21-Jul carla@ATHENA.MIT.EDU #The great discuss meeting move of '89 Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA04489; Fri, 21 Jul 89 09:19:52 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23560; Fri, 21 Jul 89 09:17:16 EDT Received: by FRIES.MIT.EDU (5.60/4.7) id AA14383; Fri, 21 Jul 89 09:17:05 EDT Message-Id: <8907211317.AA14383@FRIES.MIT.EDU> To: consultants@ATHENA.MIT.EDU, olc_help@ATHENA.MIT.EDU Subject: The great discuss meeting move of '89 Date: Fri, 21 Jul 89 09:16:58 EDT From: Carla Fermann *** EOOH *** To: consultants@ATHENA.MIT.EDU, olc_help@ATHENA.MIT.EDU Subject: The great discuss meeting move of '89 Date: Fri, 21 Jul 89 09:16:58 EDT From: Carla Fermann Hi! Just to clarify things a bit, here's what's happening today. The discuss meetings that Tom mentioned in his mail message will be moved from MATISSE to MENELAUS at 2pm. The mail addresses for those meetings will be changed today, and MATISSE will forward mail for those meetings to MENELAUS, so mail should not be lost while we wait for the update in Moira and the mail hub. There may be a small window when this fails, so if mail to one of these meetings bounces back to you, simply resend it again later. Once again, these meetings will be going away: OLC_Requests (orequests) OLC_announce (oannounce) You should remove these meetings from your .meetings file, either by typing "dm orequests" and "dm oannounce" from inside 'discuss', or deleting the appropriate lines using 'emacs'. The meetings that will move are: Consulting_FYI (cfyi) Consulting_play (cplay) Consulting_Hat (chat) Consulting_Hours (chours) Consulting_Private (cprivate) OLC_stock_answers (ostock) You can make the switchover most easily by using 'emacs' and performing a 'query-replace'. To do this, type: M-X query-replace matisse menelaus This will stop at each occurrence of 'matisse' and ask you if you want to change it. If yes, press . If not, press the key. To quit, press . For help during the query-replace, press "?". To replace each meeting using 'discuss' (rather than editing your .meetings file with 'emacs'), you would need to delete the meeting first (ie. "dm chours"), and then add it again later when the new meeting announcement is made. This is not quite as nice as using emacs, as you will lose your place in the meeting, and the order of your meetings will not be the same as before (if you are used to, or like the order of your meetings now, you may care about this). The following meetings will be created (look for announcements in Athena_Meetings (amtgs)): Consulting_Meetings (cmtgs) OLC_Bugs (obugs) OLC_Discussion (olc) Once the announcements are made, you can go to Athena_Meetings in 'discuss' ("go amtgs"), and then add them when you read the announcement (ie. "print 1021" to see an announcement, then "am" to add it, or just "am 1196" to add the meeting announced in '1196'). If you prefer, you can add the meeting without going to Athena_Meetings by just specifying the full location to 'discuss' (ie. "am menelaus:/usr/spool/discuss/olc"). If you prefer adding the new meetings with 'emacs', you should be able to cut and paste these lines into your .meetings file (make sure that each one is all on one line -- you may want to turn off auto-fill-mode): 0:616684065:1:MENELAUS.MIT.EDU:/usr/spool/discuss/cmtgs:Consulting_Meetings,cmtgs: 0:616684065:1:MENELAUS.MIT.EDU:/usr/spool/discuss/obugs:OLC_Bugs,obugs: 0:616684065:1:MENELAUS.MIT.EDU:/usr/spool/discuss/olc:OLC_Discussion,olc: I can't guarantee that these lines will work, as the meetings haven't yet been created, but they should work if all goes well. Please let me know if you have any trouble.... Enjoy! Carla  1,,argus, Summary-line: 21-Jul aagleckl@ATHENA.MIT.EDU #I wrote mmail. I'll be around until about 5pm today. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08039; Fri, 21 Jul 89 14:12:56 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28880; Fri, 21 Jul 89 14:12:48 EDT Received: by CHOWPEENTULK.MIT.EDU (5.61/4.7) id AA00533; Fri, 21 Jul 89 14:12:35 -0400 Date: Fri, 21 Jul 89 14:12:35 -0400 Message-Id: <8907211812.AA00533@CHOWPEENTULK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: I wrote mmail. I'll be around until about 5pm today. Reply-To: aagleckl@ATHENA.MIT.EDU *** EOOH *** From: Date: Fri, 21 Jul 89 14:12:35 -0400 To: rap@ATHENA.MIT.EDU Subject: I wrote mmail. I'll be around until about 5pm today. Reply-To: aagleckl@ATHENA.MIT.EDU  1,,system, Summary-line: 21-Jul sueu@ATHENA.MIT.EDU #Mwm and Zwgc Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08865; Fri, 21 Jul 89 14:58:25 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA00166; Fri, 21 Jul 89 14:58:21 EDT Received: by BASSELOPE.MIT.EDU (5.61/4.7) id AA23562; Fri, 21 Jul 89 14:58:13 -0400 Message-Id: <8907211858.AA23562@BASSELOPE.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Subject: Mwm and Zwgc Date: Fri, 21 Jul 89 14:58:10 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Subject: Mwm and Zwgc Date: Fri, 21 Jul 89 14:58:10 EDT I have set this resource in my .Xresources: zwgc*reverseStack: true Under mwm, I get the following error every time a zgram comes through ( I believe zwgc implements the above resource by executing a "lower window" immediately after mapping the window): zwgc:X11 Error: BadMatch, invalid parameter attributes Request code: 12 [X_ConfigureWindow] Request function: 0 Request resourceid 0x50002a Obviously, my stack is not reversed... Matthew Swift sueu@athena  1,, Summary-line: 21-Jul vanharen@ATHENA.MIT.EDU #bug with XmTestSetString, snap 9 Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11242; Fri, 21 Jul 89 17:12:03 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02789; Fri, 21 Jul 89 17:11:58 EDT Received: by FRIES.MIT.EDU (5.60/4.7) id AA15760; Fri, 21 Jul 89 17:11:50 EDT Message-Id: <8907212111.AA15760@FRIES.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU From: Chris VanHaren Subject: bug with XmTestSetString, snap 9 Date: Fri, 21 Jul 89 17:11:43 EDT Sender: vanharen@ATHENA.MIT.EDU *** EOOH *** To: motif-bugs@ATHENA.MIT.EDU From: Chris VanHaren Subject: bug with XmTestSetString, snap 9 Date: Fri, 21 Jul 89 17:11:43 EDT Sender: vanharen@ATHENA.MIT.EDU OSF UEC Problem Report ================================= Submitter Information --------------------- Submitter Name: Chris VanHaren Organization: MIT Project Athena Email Address: vanharen@athena.mit.edu Phone: (617) 253-0111 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot 9 Component (Module): XmTextSetString routine OSF License Number: --- Client Hardware: VAXstation II/RC w/5 Meg ram Client Software: Unix 4.3 BSD w/Athena extensions, X11r3. Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: pcc Problem Description ------------------- Severity Level: Critical Date of First Occurrence: July 19, 1989 (07/19/89) One Line Description: Using XmTextSetString to set the value of a text widget *before* the widget is realized gives unpredictable results. Full Description: Using XmTextSetString to set the value of a text widget before the widget is realized causes the text widget not to display it properly when it is later realized and managed. The text value does get set correctly, as can be proven by selecting the entire region and pasting into another window, but it is not necessarily displayed correctly. In some obscure cases, the text is drawn correctly, but more often than not, it is not drawn correctly. This problem seems to occur mainly when used with a variable width font. According to the X Toolkit Intrinsics manual, Xt does not (or should not) have this problem -- "all Intrinsics functions and all widget routines should work with either realized or unrealized widgets." (p. 31) Repeat By: Use XmTextSetString to set the value of a text widget, then realize the widget with XtRealizeWidget, and manage it with XtManageChild if it is not already managed. The text will most likely be displayed incorrectly. Proposed Solution: Unknown.  1,, Summary-line: 21-Jul bgardner@ATHENA.MIT.EDU #Re: Error with ruleeditor. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA12340; Fri, 21 Jul 89 18:26:08 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04341; Fri, 21 Jul 89 18:25:53 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA13475; Fri, 21 Jul 89 18:25:38 -0400 Date: Fri, 21 Jul 89 18:25:38 -0400 Message-Id: <8907212225.AA13475@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: Re: Error with ruleeditor. *** EOOH *** From: Date: Fri, 21 Jul 89 18:25:38 -0400 To: rap@ATHENA.MIT.EDU Subject: Re: Error with ruleeditor. >1>> sh: 6954 Bus error - core dumped >2>> Error with ruleeditor. > >line 1 is from a shell, and line 2 is from the rule set editor. Most >likely the rule set editor has sent some bad shell syntax when >invoking the rule editor. I printed out the syntax with a debug line, and that's not the problem. Besides, the ruleeditor would be pretty buggy if it dumps core and dies of a bus error because it was passed bad syntax. While its true that I invoked the ruleeditore from rsedit, unless there is a bug in the ruleeditor, the ruleeditor cannot be made to dump core by rsedit (all it does is execute the ruleeditor from the commandline in a shell exactly the same as if a user had typed it). Ican't do a "where ruleeditor" right now, because 0.5 is being remade. ... Well, actually, I can, and it says that it can't find the ruleeditor , which meansdd that I'm using the one in the 0.5 directory. So, here's my path, instead (which says the same thing): echo $PATH .:/mit/bgardner/vaxbin:/srvd/patch:/usr/athena:/bin/athena:/usr/bin/X:/usr/new:/ usr/new/mh/bin:/usr/ucb:/bin:/usr/bin:/usr/games:/afs/athena/mit/andrew/vaxbin:/ afs/athena/mit/argus/0.5/vaxbin:/mit/vws/plx/vax/vax_video:/mit/StaffTools/vaxli b:/mit/StaffTools/vaxbin:/mit/StaffTools/include I really suspect that this is that empty rule problem (the same one the -ib & -ia options are being buggy about now). Oh, yes, that same day, I tried typing "ruleeditor -rs testrules" from the commandline myself, but had the same problem. I will try to remember to check this out again after the new release finishes compiling...who knows, maybe it'll be fixed by the re-compile (ok, ok...so I believed in Santa Clause when I was a kid, too.) -- Brian  1,,discuss,system, Summary-line: 21-Jul carla@ATHENA.MIT.EDU #The discuss meetings have moved!! Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA12961; Fri, 21 Jul 89 19:25:55 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05336; Fri, 21 Jul 89 19:23:45 EDT Received: by RENOIR.MIT.EDU (5.61/4.7) id AA11036; Fri, 21 Jul 89 19:23:28 -0400 Message-Id: <8907212323.AA11036@RENOIR.MIT.EDU> To: consultants@ATHENA.MIT.EDU, olc_volunteers@ATHENA.MIT.EDU Cc: carla@ATHENA.MIT.EDU Subject: The discuss meetings have moved!! Date: Fri, 21 Jul 89 19:23:23 EDT From: Carla Fermann *** EOOH *** To: consultants@ATHENA.MIT.EDU, olc_volunteers@ATHENA.MIT.EDU Cc: carla@ATHENA.MIT.EDU Subject: The discuss meetings have moved!! Date: Fri, 21 Jul 89 19:23:23 EDT From: Carla Fermann Hi! The "great discuss move" has been finished. Here's the current state of things, with details about mail into each meeting: Meetings that have been moved: cfyi mail works fine cprivate mail works fine chours mail works fine olc-stock mail works fine cplay mail works fine chat mail doesn't work (never did); will work as soon as moira and athena update Meetings that have been deleted: orequests has been replaced; new meeting is "olcd" oannounce has been replaced; new meeting is "cmtgs" New meetings: cmtgs replaces "oannounce"; no mail into this meeting obugs replaces part of "orequests"; mail works fine olcd replaces the rest of "orequests"; mail will work as soon as moira and athena update (mail to either "olc-wishes" or "olcd" ) **** Also, please note that the "olc discussion" meeting is called "olcd", rather than "olc" as advertised earlier. To add this meeting, choose one of the following: WITHIN DISCUSS: go amtgs am 37 ALSO WITHIN DISCUSS: am menelaus:/usr/spool/discuss/olcd IN EMACS, ADD THE FOLLOWING LINE TO YOUR .meetings FILE: 0:617064555:1:MENELAUS.MIT.EDU:/usr/spool/discuss/olcd:OLC_Discussion,olcd: As always, please let me know if you have any trouble or questions... Carla  1,, Summary-line: 21-Jul danapple@FLOTSAM.MIT.EDU #Re: Postpone today's meeting.... Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13299; Fri, 21 Jul 89 19:56:10 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05933; Fri, 21 Jul 89 19:54:58 EDT Received: by FLOTSAM.MIT.EDU (5.45/4.8) id AA05660; Fri, 21 Jul 89 19:54:39 EDT From: Daniel I. Applebaum Message-Id: <8907212354.AA05660@FLOTSAM.MIT.EDU> To: mackay@ATHENA.MIT.EDU Cc: video-mail@ATHENA.MIT.EDU, danapple@FLOTSAM.MIT.EDU Subject: Re: Postpone today's meeting.... In-Reply-To: Your message of Thu, 20 Jul 89 11:39:43 EDT. <8907201539.AA09319@E40-368-1.MIT.EDU> Date: Fri, 21 Jul 89 19:54:36 EDT *** EOOH *** From: Daniel I. Applebaum To: mackay@ATHENA.MIT.EDU Cc: video-mail@ATHENA.MIT.EDU, danapple@FLOTSAM.MIT.EDU Subject: Re: Postpone today's meeting.... In-Reply-To: Your message of Thu, 20 Jul 89 11:39:43 EDT. <8907201539.AA09319@E40-368-1.MIT.EDU> Date: Fri, 21 Jul 89 19:54:36 EDT I work 8:30 to 4:30 daily and can't get back to Cambridge until about 6pm ever. Evenings would be ok, except July 28. Dan.  1,, Summary-line: 21-Jul mackay@ATHENA.MIT.EDU #New shell script Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13718; Fri, 21 Jul 89 20:53:29 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA06716; Fri, 21 Jul 89 20:53:07 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA11261; Fri, 21 Jul 89 20:52:57 -0400 Date: Fri, 21 Jul 89 20:52:57 -0400 Message-Id: <8907220052.AA11261@E40-368-1.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: New shell script Argus-Application: data collection New-Feature: shell script called "new" *** EOOH *** From: Date: Fri, 21 Jul 89 20:52:57 -0400 To: alens@ATHENA.MIT.EDU Subject: New shell script Argus-Application: data collection New-Feature: shell script called "new" Message type: feature-announcement Date: Fri, 21 Jul 89 20:52:52 EDT From: mackay Attached is a shell script that sends Maya the number of new messages. Remember to make the file executable after saving it. First, save it as "new" (as a substitute for "inc") and type: chmod +x new I called the message type "traffic.data". It's not registered with the message type editor, in case you want to change it. I added redundant fields (date and username), in case there are delays/problems between the use of the "new" command and the sending of the message. I could also add fields for total number of bytes and name of postoffice, which are available in the program called "msgchk". If this shell script doesn't work properly, check to see that msgchk works. ============================== Example of a message... ============================== Received: by E40-PO.MIT.EDU (5.45/4.7) id AA17072; Fri, 21 Jul 89 20:06:40 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA06101; Fri, 21 Jul 89 20:06:13 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA11115; Fri, 21 Jul 89 20:06:00 -0 400 Date: Fri, 21 Jul 89 20:06:00 -0400 Message-Id: <8907220006.AA11115@E40-368-1.MIT.EDU> To: mackay@ATHENA.MIT.EDU Message type: traffic.data New messages: 1 Current date: Fri Jul 21 20:05:45 EDT 1989 User's name: mackay ============================== and now the shell script... ============================== ############################################################################# ## ## Author: Wendy Mackay ## Modified: 21 July 1989 ## ## Purpose: Support Argus user study by collecting mail traffic data. ## Subject replaces the "inc" command with "new" ## which sends electronic mail to researcher. The body of ## the message will have the following fields: ## ## Message type: traffic.data ## New messages: ## Current date: ## User's name: ## ## Note: Additional information from the msgchk program could ## include total number of bytes and post office name. ## ############################################################################# ## ## Remove temporary file, if it exists ## /bin/rm -f \tmp\new.tmp ## ## Create a temporary file that will become the body of the message ## echo "Message type: traffic.data" > \tmp\new.tmp msgchk | awk '{printf "New messages: %3d\n", $3}' >> \tmp\new.tmp echo "Current date: `date`" >> \tmp\new.tmp echo "User's name: $USER" >> \tmp\new.tmp ## ## inc mail ## inc ## ## Mail temporary file to researcher (maya) ## mail maya <\tmp\new.tmp ## ## Remove temporary file ## /bin/rm -f \tmp\new.tmp ############################################################################# ## ## This also works, but is harder to read. Only has required fields. ## ## msgchk | awk '{printf "Message type: traffic.data\nNew messages: %3d\n", $3}' | mail maya ## ## #############################################################################  1,, Summary-line: 21-Jul mackay@ATHENA.MIT.EDU #Shell script... Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA14004; Fri, 21 Jul 89 21:28:29 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07083; Fri, 21 Jul 89 21:27:52 EDT Received: by E40-334-1.MIT.EDU (5.61/4.7) id AA16644; Fri, 21 Jul 89 21:27:41 -0400 Message-Id: <8907220127.AA16644@E40-334-1.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: Shell script... Date: Fri, 21 Jul 89 21:27:36 EDT *** EOOH *** From: To: alens@ATHENA.MIT.EDU Subject: Shell script... Date: Fri, 21 Jul 89 21:27:36 EDT Brian pointed out that the names of the fields shouldn't have spaces in them. So, here's a slightly revised version: ############################################################################# ## ## Author: Wendy Mackay ## Modified: 21 July 1989 ## ## Purpose: Support Argus user study by collecting mail traffic data. ## Subject replaces the "inc" command with "new" ## which sends electronic mail to researcher. The body of ## the message will have the following fields: ## ## Msg-Type: traffic.data ## New-messages: ## Current-date: ## Username: ## ## Note: Additional information from the msgchk program could ## include total number of bytes and post office name. ## ############################################################################# ## ## Remove temporary file, if it exists ## /bin/rm -f \tmp\new.tmp ## ## Create a temporary file that will become the body of the message ## echo "Msg-Type: traffic.data" > \tmp\new.tmp msgchk | awk '{printf "New-messages: %3d\n", $3}' >> \tmp\new.tmp echo "Current-date: `date`" >> \tmp\new.tmp echo "Username: $USER" >> \tmp\new.tmp ## ## inc mail ## inc ## ## Mail temporary file to researcher (maya) ## mail maya <\tmp\new.tmp ## ## Remove temporary file ## /bin/rm -f \tmp\new.tmp ############################################################################# ## ## This also works, but is harder to read. Only has key fields. ## ## msgchk | awk '{printf "Msg-Type: traffic.data\nNew-messages: %3d\n", $3}' | mail maya ## ## #############################################################################  1,,bug-runrules, Summary-line: 21-Jul mackay@ATHENA.MIT.EDU #What happened??? Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15232; Fri, 21 Jul 89 23:43:07 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08602; Fri, 21 Jul 89 23:43:02 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA11434; Fri, 21 Jul 89 23:42:52 -0400 Message-Id: <8907220342.AA11434@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: What happened??? Date: Fri, 21 Jul 89 23:42:43 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: What happened??? Date: Fri, 21 Jul 89 23:42:43 EDT This used to work... %runrules sifter +inbox WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 sh: /usr/new/mh.6.5/lib/rcvstore: not found % It didn't coredump... Wendy  1,,feature-ruleeditor, Summary-line: 22-Jul mackay@ATHENA.MIT.EDU #Text widget Bug and Field types menu design issue Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21054; Sat, 22 Jul 89 19:51:11 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA17451; Sat, 22 Jul 89 19:51:09 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00565; Sat, 22 Jul 89 19:50:56 -0400 Message-Id: <8907222350.AA00565@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Text widget Bug and Field types menu design issue Date: Sat, 22 Jul 89 19:50:49 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: Text widget Bug and Field types menu design issue Date: Sat, 22 Jul 89 19:50:49 EDT I assume you already know about this, but just in case... I typed a field that was longer than the space allocated, and now I can't see if what I typed worked correctly. It doesn't scroll properly. We need to think about this for the Motif version. Also, I got confused when I chose "exists" from the field types menu. It really seems that the "available operators" should be a choice at the end of each field type, rather than a separate choice at the bottom of the menu. If I choose "exists", then change my mind and choose "date", the menu shouldn't disappear and force me to reopen it to get to the "available operators" menu.  1,,bug-rsedit, Summary-line: 22-Jul mackay@ATHENA.MIT.EDU #RSedit bugs Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21341; Sat, 22 Jul 89 20:22:19 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA17698; Sat, 22 Jul 89 20:22:17 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00615; Sat, 22 Jul 89 20:22:05 -0400 Message-Id: <8907230022.AA00615@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: RSedit bugs Date: Sat, 22 Jul 89 20:22:01 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: RSedit bugs Date: Sat, 22 Jul 89 20:22:01 EDT 1. I clicked the left mouse button when opening rsedit and got a full size window. There were two overlapped scroll bars and a few things out of place. Things got worse as I tried to resize it to its usual size. 2. I tried to copy a rule, and kept doing it when it didn't seem to work. There was no indication that anything had happened and I didn't get a rule editor to edit the copy. Nor did it show up as the next rule in the rule set. I finally checked the text file and found that copies of the rule had been placed in the rule set file. 3. I iconified it and then redisplayed it, to see if that would help with the redisplay of the rules and the other redisplay problems. It came up without any text showing and now I can't delete it, since none of the buttons work. Sigh. Wendy  1,,bug-motif,xmlist, Summary-line: 23-Jul Ghost@ATHENA.MIT.EDU #XmListWidget Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25267; Sun, 23 Jul 89 10:48:40 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22357; Sun, 23 Jul 89 10:48:40 EDT Received: by E51-007-11.MIT.EDU (5.60/4.7) id AA00594; Sun, 23 Jul 89 10:48:23 EDT Date: Sun, 23 Jul 89 10:48:23 EDT Message-Id: <8907231448.AA00594@E51-007-11.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Subject: XmListWidget From: Ghost@ATHENA.MIT.EDU Sender: timo@ATHENA.MIT.EDU Reply-To: timo@ATHENA.MIT.EDU *** EOOH *** Date: Sun, 23 Jul 89 10:48:23 EDT To: motif-bugs@ATHENA.MIT.EDU Subject: XmListWidget From: Ghost@ATHENA.MIT.EDU Sender: timo@ATHENA.MIT.EDU Reply-To: timo@ATHENA.MIT.EDU OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: Tim O'Malley Organization: MIT Email Address: timo Phone: 576-2793 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot 9 Component (Module): the XmList OSF License Number: --- Client Hardware: RT Client Software: Unix 4.3 BSD w/Athena extensions X11R3 Server Hardware: same as above Server Software: ditto as above Compiler: hc2 Problem Description ------------------- Severity Level: Severe -- represents a problem which resulted in software functionality limitation but had alternative work-around. Date of First Occurrence: July 23 1989 One Line Description: Using the XmListCallbackStruct item_position integer does not return the position of the item in the list. Full Description: I have a single_selection callback for a SingleSelection list that calls a procedure. the procedure (yes, declared correctly) takes two arguments (w, calldata) where w is a Widget and *calldata is the XmListCallbackStruct. I then set an integer to calldata->item_position to get the position in the list of the selected item. In that dialog box (a custom-created form_dialog with auto_unmanage set to true) I have a Cancel button. This button has an activate callback that passes the integer 50 to a dispatch procedure. The dispatch procedure has a switch in it and knows to unmanage the dialog on a 50. For some reason the integer 50, or any other integer I put in the Cancel button callback, is given to me when I get the value of calldata->item_position. This doesn't seem quite right! Repeat By: here is my UIL code.. object unset_dialog : form_dialog { arguments { dialog_style = XmDIALOG_APPLICATION_MODAL; auto_unmanage = true; default_position = false; x=350; y=250; width = 300; height = 270; vertical_spacing = 5; horizontal_spacing = 10; border_width = 2; shadow_thickness = 2; }; controls { label unset_title; separator unset_separator; label unset_label; list_box alarms_list; separator unset_bottom_separator; push_button unset_help_but; push_button unset_cancel_but; }; }; object alarms_list : list_box { arguments { top_attachment = XmATTACH_WIDGET; top_widget = label unset_label; left_attachment = XmATTACH_FORM; right_attachment = XmATTACH_FORM; selection_policy = XmSINGLE_SELECT; border_width = 2; shadow_thickness = 0; width = 200; list_spacing = 0; font_list = Textfont; visible_item_count = 5; list_size_policy = XmCONSTANT; }; callbacks { single_selection = procedure shutalarm(); }; }; object unset_cancel_but : push_button { arguments { top_attachment = XmATTACH_WIDGET; top_widget = separator unset_bottom_separator; right_attachment = XmATTACH_FORM; font_list = Labelfont; label_string = "Cancel"; shadow_thickness = 3; width = 70; }; callbacks { activate = procedure dispatch(50); }; }; and now the C code... void dispatch(w,proc_id,calldata) Widget w; int *proc_id; XmAnyCallbackStruct *calldata; { switch (*proc_id) { case 1 : XtManageChild(alarm_dialog); break; case 11 : setalarm(); break; case 12 : XtUnmanageChild(alarm_dialog); getunset(); break; case 14 : XtUnmanageChild(alarm_dialog); break; case 50 : XtUnmanageChild(unset_dialog); break; } } void shutalarm(w,calldata) Widget w; XmListCallbackStruct *calldata; { int number; number = calldata->item_position - 1; XtUnmanageChild(unset_dialog); printf("the number = %d\n",number); sprintf(alarm_time[number - 1],""); sprintf(alarm_message[number - 1],""); counter -= 1; printf("time = %s\nmessage = %s\n\n",alarm_time[number - 1], alarm_message[number - 1]); } Proposed Solution: With the position_number I could simply access that number box in the array. I guess I'll have to compare the string to each element in the array until I find the match.  1,, Summary-line: 24-Jul eveham@ATHENA.MIT.EDU #screen dumps of interfaces Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03290; Mon, 24 Jul 89 08:46:02 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01830; Mon, 24 Jul 89 08:45:57 EDT Received: by E40-369-4.MIT.EDU (5.61/4.7) id AA25348; Mon, 24 Jul 89 08:45:43 -0400 Message-Id: <8907241245.AA25348@E40-369-4.MIT.EDU> To: motif@ATHENA.MIT.EDU Subject: screen dumps of interfaces Date: Mon, 24 Jul 89 08:45:39 EDT *** EOOH *** From: To: motif@ATHENA.MIT.EDU Subject: screen dumps of interfaces Date: Mon, 24 Jul 89 08:45:39 EDT As Jackie indicated at the meeting on Friday, I need to get screen dumps of all the interfaces under development with motif. We will be taking a look at them and making sure they are consistent with the motif style guide. Our commitment to OSF is that the interfaces have to look as if they came from one source-- so things like scroll bars have to be placed consistently, exit and help buttons should appear in the same place, etc. In order to minimize the interruption please put copies in my box by 3 today so I can get back to you as soon as possible. Thanks a lot, evelynn  1,, Summary-line: 24-Jul ian@ATHENA.MIT.EDU #[libby@osf.osf.org (Libby Sackett): bug fix] Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06937; Mon, 24 Jul 89 13:12:42 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05903; Mon, 24 Jul 89 13:12:23 EDT Received: by E40-349-1.MIT.EDU (5.60/4.7) id AA11076; Mon, 24 Jul 89 13:12:06 EDT Message-Id: <8907241712.AA11076@E40-349-1.MIT.EDU> To: motif@ATHENA.MIT.EDU Cc: jstewart@ATHENA.MIT.EDU Subject: [libby@osf.osf.org (Libby Sackett): bug fix] Date: Mon, 24 Jul 89 13:12:02 EDT *** EOOH *** From: To: motif@ATHENA.MIT.EDU Cc: jstewart@ATHENA.MIT.EDU Subject: [libby@osf.osf.org (Libby Sackett): bug fix] Date: Mon, 24 Jul 89 13:12:02 EDT This refers to the second bug I reported, to which OSF has replied positively. ------- Forwarded Message Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06657; Mon, 24 Jul 89 12:47:54 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05496; Mon, 24 Jul 89 12:47:59 EDT Received: by osf.osf.org (5.61/OSF 0.1) id AA02671; Mon, 24 Jul 89 12:47:42 -0400 From: libby@osf.osf.org (Libby Sackett) Message-Id: <8907241647.AA02671@osf.osf.org> Subject: bug fix To: ian@ATHENA.MIT.EDU Date: Mon, 24 Jul 89 12:47:40 EDT X-Mailer: Elm [version 2.01 (alpha-release)] Your report P355 BUTTONS IN PACK_COLUMN ROW_COLUMN ARE UNEQUAL WIDTH AFTER RESIZE has been fixed. ------- End of Forwarded Message  0,unseen,, Summary-line: 24-Jul shirl@ATHENA.MIT.EDU #OPEN STAFF MEETING Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA07956; Mon, 24 Jul 89 14:11:41 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07123; Mon, 24 Jul 89 14:10:29 EDT Received: by E40-391-2.MIT.EDU.MIT.EDU (5.60/4.7) id AA29615; Mon, 24 Jul 89 14:09:33 EDT Message-Id: <8907241809.AA29615@E40-391-2.MIT.EDU.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: shirl@ATHENA.MIT.EDU Subject: OPEN STAFF MEETING Date: Mon, 24 Jul 89 14:09:25 EDT There will be an Open Staff Meeting, Thursday, July 27th from 3:30 to 5:00 pm in Conference Room 496. Our major topic will be "Preparation for Fall Start-Up" with informal presentations by Ron, Peter and Jackie followed by a question and answer period. All are welcome to attend.  0,unseen,, Summary-line: 24-Jul roden@ATHENA.MIT.EDU #E40 3rd floor inventory Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08250; Mon, 24 Jul 89 14:25:40 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07420; Mon, 24 Jul 89 14:24:23 EDT Received: by E40-355-P.MIT.EDU (5.61/4.7) id AA28550; Mon, 24 Jul 89 14:23:57 -0400 Message-Id: <8907241823.AA28550@E40-355-P.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: E40 3rd floor inventory Date: Mon, 24 Jul 89 14:23:52 EDT As part of my orientation and planning for new workstation deployment, I want to conduct a survey of all workstations on the 3rd floor of E40. Even though I have some of your configuration files, this technique of gathering information was not complete. Therefore, we will be visiting you soon to colect some simple data on the systems in your office/area. Your help is appreciated. Thank you. Peter  0,unseen,, Summary-line: 24-Jul epeisach@ATHENA.MIT.EDU #MWM PlacementMargin max. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09186; Mon, 24 Jul 89 15:14:56 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08514; Mon, 24 Jul 89 15:15:01 EDT Received: by FLAKEY.MIT.EDU (5.61/4.7) id AA20143; Mon, 24 Jul 89 15:14:46 -0400 Date: Mon, 24 Jul 89 15:14:46 -0400 Message-Id: <8907241914.AA20143@FLAKEY.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Subject: MWM PlacementMargin max. While I know that the placement margin is based on an x and y offset (which I believe is a misfeature), I was disappointed that I could not get the offset greater than a certain value. This is a bug. I should be able to give an offset to be in the middle of the screen. The problem is in the line: WmGlobal.h:#define MAXIMUM_ICON_MARGIN 128 Which defines the max value. Why is it so low? Ezra  1,,argus, Summary-line: 24-Jul rap@ATHENA.MIT.EDU #new Makefiles Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13138; Mon, 24 Jul 89 19:31:35 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA13424; Mon, 24 Jul 89 19:31:37 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA07517; Mon, 24 Jul 89 19:30:42 EDT Date: Mon, 24 Jul 89 19:30:42 EDT Message-Id: <8907242330.AA07517@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: new Makefiles *** EOOH *** From: Date: Mon, 24 Jul 89 19:30:42 EDT To: argus2@ATHENA.MIT.EDU Subject: new Makefiles There is a new copy of the src directories. I have divided out sources into x11r2 and motif versions. The old directories such as .../working/src are now links to the appropriate places so nothing is really changed. BUT... in an effort to keep development going I have divided Argus into two libraries lens.a and xlens.a and I have divided the applications into basic and xbasic (all refers to both groups). The groups refer to: basic runrules alcomp lensdc anyone lens.a xbasic ruleeditor mteditor rsedit xlens.a Of course, xbasic will not compile now. (all the xstuff is wrong). But basic does compile. So we must be sure to use lens.a or xlens.a as appropriate. Be sure to check the Makefiles for which .o's are in which libraries. Also, if you do look at RCS you will notice that I have deleted all of the logs in the new RCS files. This is to save sapve. All of the old logs are availabel in .../working/x11r2/vaxsrc/RCS. I am updating which directrories ..../working/vaxsrc etc point to VERY soon. __Rich.  1,,argus, Summary-line: 24-Jul rap@ATHENA.MIT.EDU #more freebies Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13335; Mon, 24 Jul 89 19:51:09 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA13639; Mon, 24 Jul 89 19:51:13 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA07632; Mon, 24 Jul 89 19:50:20 EDT Date: Mon, 24 Jul 89 19:50:20 EDT Message-Id: <8907242350.AA07632@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: more freebies *** EOOH *** From: Date: Mon, 24 Jul 89 19:50:20 EDT To: argus2@ATHENA.MIT.EDU Subject: more freebies there are now directories called ../working/vaxlib and rtlib which contain files called liblens.a and libxlens.a. These are symbolic links to the appropriate lens.a and xlens.a libraries but the upshot is that you can do something like this when you compile... ... -L/afs/athena/mit/argus/src/working/vaxlib -llens -lxlens this will also be useful with saber. __Rich.  1,, Summary-line: 25-Jul mackay@ATHENA.MIT.EDU #Aiiee... Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15574; Tue, 25 Jul 89 00:05:08 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16550; Tue, 25 Jul 89 00:05:07 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00539; Tue, 25 Jul 89 00:04:49 -0400 Message-Id: <8907250404.AA00539@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Aiiee... Date: Tue, 25 Jul 89 00:04:45 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: Aiiee... Date: Tue, 25 Jul 89 00:04:45 EDT Well, I finally got my workstation back, and if I use "lens.profile.0.5" in my home directory (as opposed to .lens.profile.0.5), I can actually get things to run. Well, sort of. runrules just coredumped, as follows: This is running from: /afs/athena/mit/argus/0.5/vaxbin/runrules Core size: 152 k % runrules sifter +inbox & [1] 482 % E40-368-1 /mit/mackay % WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 sh: /usr/new/mh.6.5/lib/rcvstore: not found WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 sh: /usr/new/mh.6.5/lib/rcvstore: not found WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 sh: /usr/new/mh.6.5/lib/rcvstore: not found WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 sh: /usr/new/mh.6.5/lib/rcvstore: not found WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 sh: /usr/new/mh.6.5/lib/rcvstore: not found WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 WARNING: Field Core-compare with field op: keys don't match 'To:' is not equal to 'to:' ^^^1 sh: /usr/new/mh.6.5/lib/rcvstore: not found Assertion failed: file mh_folder.c: line 878: mh_data->dir_ob_list != 0 [1] Illegal instruction runrules sifter +inbox (core dumped)  1,,feature-ruleeditor, Summary-line: 25-Jul mackay@ATHENA.MIT.EDU #Rule editor Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15692; Tue, 25 Jul 89 00:18:43 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16756; Tue, 25 Jul 89 00:18:48 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00578; Tue, 25 Jul 89 00:18:30 -0400 Message-Id: <8907250418.AA00578@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Rule editor Date: Tue, 25 Jul 89 00:18:26 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: Rule editor Date: Tue, 25 Jul 89 00:18:26 EDT I created my own "To:" field in a rule and it read it back in as an unchangeable "from the message" field. It seems as though we should be consistent -- make them all editable. (Rather than forcing the user to delete one and create a new one.) It also solves the left vs. right justification problem. Thus, if I bring up as my default: IF To: [ ] Subject: [ ] I should be able to edit "subject" to make it "cc" if I want. W  1,,bug-runrules, Summary-line: 25-Jul mackay@ATHENA.MIT.EDU #runrules bug Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15772; Tue, 25 Jul 89 00:29:52 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16899; Tue, 25 Jul 89 00:29:56 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00635; Tue, 25 Jul 89 00:29:39 -0400 Message-Id: <8907250429.AA00635@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: runrules bug Date: Tue, 25 Jul 89 00:29:35 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: runrules bug Date: Tue, 25 Jul 89 00:29:35 EDT Another core dump. These rules use date fields. % runrules test +phyl sh: /usr/new/mh.6.5/lib/rcvstore: not found Assertion failed: file mh_folder.c: line 878: mh_data->dir_ob_list != 0 Illegal instruction (core dumped) % E40-368-1 /mit/mackay/Mail/phyl % ls 10 11 3 4 5 6 7 8 9 core  1,, Summary-line: 25-Jul rap@ATHENA.MIT.EDU #new libxargus.a Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20905; Tue, 25 Jul 89 13:21:25 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24715; Tue, 25 Jul 89 13:21:29 EDT Received: by MORPHEUS.MIT.EDU (5.60/4.7) id AA06457; Tue, 25 Jul 89 13:21:10 EDT Date: Tue, 25 Jul 89 13:21:10 EDT Message-Id: <8907251721.AA06457@MORPHEUS.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: new libxargus.a *** EOOH *** From: Date: Tue, 25 Jul 89 13:21:10 EDT To: argus2@ATHENA.MIT.EDU Subject: new libxargus.a The argus x library is a reduced library containing ArgPack.o -- routines to manipulate lists of widget resources alxms.o -- routines to manipulate XmStrings almonitor.o -- old routines to handle argument passing when using X translation tables alfonts.o -- contains a routine which when given a widget will return an XmFontList of four fonts to be used by applications running on the same display as the widget. rebox.o -- routines to draw boxes on widgets. Complex interface, ask me. menupack.o -- routines for creating menus. This is useful. The types of menus that have been tested good most recently are the MP_POPUP, MP_OPTION and MP_SUBMENU. I haven't tested the MP_PULLDOWN in a couple of weeks but it should work fine. READ the header file. Things are a bit complex but this object is much nicer to use than the widgets themselves. I am planning to add neuomonics and keyboard accelorator support as a set of auxillary function calls, so the existing ones won't change. childpack.o -- routines to manage lists of widgets. (i.e. children lists) xstuff.o -- general x routines. Include things to attach and detach cursors from widgets, a generic routine to set a single widget resource, a routine to get a widget resource, a routine to reverse a widget foreground and background, and a routine to change a widgets fore and background to that of another widget (i.e. normal video). __Rich.  1,, Summary-line: 25-Jul post@xanadu.enet.dec.com #More example rule set files Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21932; Tue, 25 Jul 89 14:43:47 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA26149; Tue, 25 Jul 89 14:43:29 EDT Received: by decwrl.dec.com (5.54.5/4.7.34) id AA00373; Tue, 25 Jul 89 11:43:04 PDT Date: Tue, 25 Jul 89 11:43:04 PDT Message-Id: <8907251843.AA00373@decwrl.dec.com> Received: by decwrl.dec.com (5.54.5/4.7.34) for rap@athena.mit.edu; id AA00373; Tue, 25 Jul 89 11:43:04 PDT From: post@xanadu.enet.dec.com To: rap@ATHENA.MIT.EDU Subject: More example rule set files *** EOOH *** Date: Tue, 25 Jul 89 11:43:04 PDT From: post@xanadu.enet.dec.com To: rap@ATHENA.MIT.EDU Subject: More example rule set files Rich: Last week got runrules working completely under Ultrix"!!! I used a modified version of the example ruleset you sent up (as we don't have a ruleset editor yet). I've played around with changing message types, but would like additional rule set files to use as examples (the only if operator in the example was "%contains", and then operator was "%move-to"). In particular, I would like example ruleset files that contain operators that work on non-text fields (Date, etc.) and then clauses which execute system commands (in addition, other non-mail actions like runrules and user properties) Thanks (in advance) Mark J. Post  1,, Summary-line: 25-Jul ian@ATHENA.MIT.EDU #dialog_type resouce for UIL message_box, and UIL Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22195; Tue, 25 Jul 89 15:02:28 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA26470; Tue, 25 Jul 89 15:02:18 EDT Received: by E40-349-1.MIT.EDU (5.60/4.7) id AA10496; Tue, 25 Jul 89 15:01:58 EDT Date: Tue, 25 Jul 89 15:01:58 EDT Message-Id: <8907251901.AA10496@E40-349-1.MIT.EDU> To: jeffreyh@ATHENA.MIT.EDU, motif@ATHENA.MIT.EDU Subject: dialog_type resouce for UIL message_box, and UIL *** EOOH *** From: Date: Tue, 25 Jul 89 15:01:58 EDT To: jeffreyh@ATHENA.MIT.EDU, motif@ATHENA.MIT.EDU Subject: dialog_type resouce for UIL message_box, and UIL Here is the UIL response to setting the above resource as an argument for message_box: dialog_type = XmDIALOG_MESSAGE; * Warning: the T is not supported for the line: 622 file: olh.uil Here is the relevant UIL code: object ui_msg : message_box { arguments { dialog_style = XmDIALOG_APPLICATION_MODAL; dialog_type = XmDIALOG_MESSAGE; message_string = "I'm a message box and I've got nothing to say"; auto_unmanage = true; }; }; I checked the XmAppl.uil and the Xm.h and find that XmDIALOG_MESSAGE and XmDIALOG_APPLICATION_MODAL are defined for MessageBox in both files with corresponding values. As I pointed out before, UIL tables for snapshot9 are out of sync with the libXm.a. Now, I also tried uil.ga on the same file: /afs/athena/mit/motifdev/include/uil.ga -I/afs/athena/mit/motifdev/include/uil olh.uil and got a different, more troublesome errors, depending on the order of items in a list. Given: list form_args : arguments { resize_policy = XmRESIZE_ANY; allow_overlap = false; dialog_style = XmDIALOG_WORK_AREA; horizontal_spacing = Spacing; vertical_spacing = Spacing; }; The error from UIL is: dialog_style = XmDIALOG_WORK_AREA; * Warning: the ! is not supported for the line: 124 file: olh.uil Segmentation violation Whereas, given: list form_args : arguments { resize_policy = XmRESIZE_ANY; allow_overlap = false; ! dialog_style = XmDIALOG_WORK_AREA; horizontal_spacing = Spacing; vertical_spacing = Spacing; }; the error is: allow_overlap = false; * Warning: the " is not supported for the line: 123 file: olh.uil Segmentation violation That's right, not only does UIL crash needlessly, but simply removing one offending line uncovers an "error" in a *previous* line. Note that the "allow_overlap" resource belongs to BulletinBoard, of which XmForm is, or at leaset was, a child. This resource is important to my form layouts, so I hope there is something equivalent to replace it or that the error is corrected. Please advise. Thanks.  1,,system,x-server, Summary-line: 25-Jul geer@ATHENA.MIT.EDU #Re: bitmaps and NoExpose events Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23040; Tue, 25 Jul 89 16:04:53 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27590; Tue, 25 Jul 89 16:03:03 EDT Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA06563; Tue, 25 Jul 89 16:02:44 -0400 Message-Id: <8907252002.AA06563@E40-342F-2.MIT.EDU> To: sysdev@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: Re: bitmaps and NoExpose events Date: Tue, 25 Jul 89 16:02:40 EDT *** EOOH *** From: To: sysdev@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: Re: bitmaps and NoExpose events Date: Tue, 25 Jul 89 16:02:40 EDT i know that this is not really news, but this is the definitive statement on the qdss server. --dan ------- Forwarded Message From: rws@expo.lcs.mit.edu To: gthomas@june.cs.washington.edu (Greg Thomas) In-Reply-To: Your message of 25 Jul 89 07:53:12 GMT. <8788@june.cs.washington.edu> Date: Tue, 25 Jul 89 08:20:51 -0400 I'm using X11R3 on a VAXstation 3200 running Ultrix 2.3. The R3 QDSS server is horribly broken, CopyPlane is just one thing that doesn't work (see the Xqdss man page). We've basically given up trying to maintain it here, it's too broken and the device is too complex. Digital is aware of the situation, but I give you no promises (either way) about what you can expect for R4. If you need those requests to work, you can try using Digital's product server, or you can find another machine ... ------- End of Forwarded Message  1,, Summary-line: 25-Jul mackay@ATHENA.MIT.EDU #Re: New shell script Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA26229; Tue, 25 Jul 89 19:36:01 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01489; Tue, 25 Jul 89 19:36:03 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA04094; Tue, 25 Jul 89 19:35:43 -0400 Message-Id: <8907252335.AA04094@E40-368-1.MIT.EDU> To: Cc: argus2@ATHENA.MIT.EDU Subject: Re: New shell script In-Reply-To: Your message of Tue, 25 Jul 89 17:04:23 -0400. <8907252104.AA06431@E40-358-18.MIT.EDU> Date: Tue, 25 Jul 89 19:35:41 EDT *** EOOH *** From: To: Cc: argus2@ATHENA.MIT.EDU Subject: Re: New shell script In-Reply-To: Your message of Tue, 25 Jul 89 17:04:23 -0400. <8907252104.AA06431@E40-358-18.MIT.EDU> Date: Tue, 25 Jul 89 19:35:41 EDT Maya, A shell script lets you gather together a set of Unix commands and save them in a file, so that you don't have to retype them each time. If you typed each command of the file I sent, the program would work. So, all you need to is decide on your favorite way of "calling" the file. I tend to use aliases for things, which I place in my .cshrc file. You can also put the file into a special directory and make sure that the name of the directory is in your path. Either will work. To do it the first way, 1. Save the email message as a file, without the header information, in an appropriate directory. (In the example below, it's called "msg-traffic-shell-script" and is stored in "some-directory". The first line of the file should be the pound signs: ####### 2. Add an alias to your .cshrc file as follows: % alias msgtraffic /mit/maya/some-directory/msg-traffic-shell-script 3. Tell Unix to run your updated .cshrc file % source ~/.cshrc 4. Check that the alias works by typing: % alias msgtraffic /mit/maya/some-directory/msg-traffic-shell-script 5. Make the file executable, as follows: % chmod +X /mit/maya/some-directory/msg-traffic-shell-script 6. Try the command % msgtraffic It should inc your mail. I'd try the "msgchk" command first, to see how many mail messages you have waiting, then try the command. Remember that it will send a message to you, so it is increasing your personal message traffic by one message each time it is used. This won't be true, of course, for your subjects. Let me know if you need help. Wendy  1,, Summary-line: 26-Jul jstewart@ATHENA.MIT.EDU #App Dev/User Services Mtg 26 July 1989 Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01153; Wed, 26 Jul 89 09:48:45 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09748; Wed, 26 Jul 89 09:48:24 EDT Received: by FUTURE.MIT.EDU (5.61/4.7) id AA29596; Wed, 26 Jul 89 09:47:59 -0400 Message-Id: <8907261347.AA29596@FUTURE.MIT.EDU> To: appdev@ATHENA.MIT.EDU, userservices@ATHENA.MIT.EDU, elsj@ATHENA.MIT.EDU Cc: murman@ATHENA.MIT.EDU, orcutt@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: App Dev/User Services Mtg 26 July 1989 Date: Wed, 26 Jul 89 09:47:56 EDT From: Jacqueline A. Stewart *** EOOH *** To: appdev@ATHENA.MIT.EDU, userservices@ATHENA.MIT.EDU, elsj@ATHENA.MIT.EDU Cc: murman@ATHENA.MIT.EDU, orcutt@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: App Dev/User Services Mtg 26 July 1989 Date: Wed, 26 Jul 89 09:47:56 EDT From: Jacqueline A. Stewart From: Jackie Stewart Telephone: 3-5226 To: Beth Anderson Gary Bean Ian Boardman Andrew Borthwick-Leslie Roman Budzianowski David Carver Bill Cattey Kevin Cunningham Ben Davis Gary Dryfoos Dan Geer Jud Harward Matt Hodges Beth Kevles Anne LaVin Wendy Mackay Bryan Michon Mark Moormans Russ Sasnett Evelyn Schlusselberg Michael Webster temp. summer AppDev/US staff cc: Earll Murman Ron Orcutt staff APPLICATIONS DEVELOPERS/USER SERVICES MEETING --------------------------------------------------------------------------- Date: Wednesday, 26 July 1989 AGENDA Time: 1:00 pm - 3:00 pm: pls. be prompt Place: E40-382 (Third floor Large Conference room) 1. Fall readiness planning: -- Software matrix review. This will include identifying what documentation, training, and consulting are planning to do for Fall. Also will indicate what we SHOULD be doing (recommendations). Software such as AFS, Muse, Ez, etc. will be part of this matrix. If time is available we will discuss the following, else they will be discussed at the AppDev/US Managers meetings (others welcome) on Thursday, 27 July, 10:00am, E40-316: -- dot files -- xdm (xsession, xlogin, xconsole) -- window managers (mwm, uwm) ************** --------------------------------------------------------------------------- Note: Next scheduled meeting: Wednesday, 9 August 1989, 1:00 pm - 3:00 pm Topic: Fall readiness (yes, again) [appdev_us_agenda]  1,, Summary-line: 26-Jul rap@ATHENA.MIT.EDU #mark and xmark (relating to RMAIL) Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02518; Wed, 26 Jul 89 11:13:41 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11047; Wed, 26 Jul 89 11:13:47 EDT Received: by MORPHEUS.MIT.EDU (5.60/4.7) id AA06846; Wed, 26 Jul 89 11:13:23 EDT Date: Wed, 26 Jul 89 11:13:23 EDT Message-Id: <8907261513.AA06846@MORPHEUS.MIT.EDU> To: thm@ATHENA.MIT.EDU Cc: bgardner@ATHENA.MIT.EDU, argus2@ATHENA.MIT.EDU In-Reply-To: 's message of Tue, 25 Jul 89 17:06:02 -0400 <8907252106.AA00527@MYCROFT.MIT.EDU> Subject: mark and xmark (relating to RMAIL) *** EOOH *** From: Date: Wed, 26 Jul 89 11:13:23 EDT To: thm@ATHENA.MIT.EDU Cc: bgardner@ATHENA.MIT.EDU, argus2@ATHENA.MIT.EDU In-Reply-To: 's message of Tue, 25 Jul 89 17:06:02 -0400 <8907252106.AA00527@MYCROFT.MIT.EDU> Subject: mark and xmark (relating to RMAIL) A note about mh and RMAIL marking. When we make our mark command it will insert fields into an mh message so that they are either msg fields or user property fields. Unfortunately, when someone marks an RMAIL message with emaacs the label becomes a folder specific field with no value. In the future someone may want to make an elisp argus-mark for emacs so that rules which take advantage of marking will work equally well with mh and BABYL files. __Rich.  1,, Summary-line: 26-Jul rap@ATHENA.MIT.EDU #resource files for our applications Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03452; Wed, 26 Jul 89 12:05:36 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA12114; Wed, 26 Jul 89 12:05:44 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA09405; Wed, 26 Jul 89 12:04:45 EDT Date: Wed, 26 Jul 89 12:04:45 EDT Message-Id: <8907261604.AA09405@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: resource files for our applications *** EOOH *** From: Date: Wed, 26 Jul 89 12:04:45 EDT To: argus2@ATHENA.MIT.EDU Subject: resource files for our applications We need to have a standard place for X resources. I am going to set up a file in the argus locker which will hold our X resources. The ultimate goal is to have all user settable resources (like border widths etc. and fonts (I'm still working on this one) specified in this file. For DEVELOPMENT purposes, each of our applications will maintain its own resource file with the following naming convention: ARgus- i.e. ARgus-ruleeditor we will then merge these files into a file called just ARgus at release time. Several notes: -- in order to have the toolkit look for this file you must specify this file as the application class name when initializing the toolkit. An example here is the toolit initialization call from the ruleeditor: TopW=XtInitialize("ruleeditor","ARgus-ruleeditor", NULL, NULL, argc, argv); -- what to do about functioned applications like the ruleeditor which may be called by another application which already initialized the toolkit? Well it isn;t as bad as it seems: if we specify resources by classes of widgets instead of names of widgets than this will create a unified look to any application which calles another. So, specify resources by classes and not names and we'll be all right. -- the path of the resource file will be set up in AlInit. >I'll do it so no need to worry. __Rich.  1,, Summary-line: 26-Jul djf@ATHENA.MIT.EDU #I need volunteers to try out the ga snaphsot Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05582; Wed, 26 Jul 89 14:09:16 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA14474; Wed, 26 Jul 89 14:09:09 EDT Received: by LEO.MIT.EDU (5.61/4.7) id AA25119; Wed, 26 Jul 89 14:08:45 -0400 Date: Wed, 26 Jul 89 14:08:45 -0400 Message-Id: <8907261808.AA25119@LEO.MIT.EDU> To: motif@ATHENA.MIT.EDU Subject: I need volunteers to try out the ga snaphsot *** EOOH *** From: Date: Wed, 26 Jul 89 14:08:45 -0400 To: motif@ATHENA.MIT.EDU Subject: I need volunteers to try out the ga snaphsot I need about 2 people to try out the new GA snapshot. What you need to do is this: change your Makefile to look for includes in /afs/athena/mit/motifdev/include.ga to link with libraries -lMrm.ga -lXm.ga -lXt.ga -lX11 To use the new version of uil: uil.ga (mockup.ga is also available) You will also have to make the following naming changes to your C code. Old Name New name --------------------------------------------- XmInitializeMRM MrmInitialize XmOpenHierarchy MrmOpenHierarchy XmRegisterMRMNames MrmRegisterNames XmFetchWidget MrmFetchWidget #include #include MRMHierarchy MrmHierarchy MRMCode MrmCode MRMCount MrmCount [etc. Many types changed from MRM to Mrm] MRMSuccess MrmSUCCESS MRMFailure MrmFAILURE MRMNotFound MrmNOT_FOUND [etc. capitalization changed in all error codes] MRMRegisterArg no change Once you make these changes, let me know if you have any other problems with the way I've installed things, or with the behaivor of the new widgets. I want feedback on this snapshot before I make it the default. Thanks. -- David Flanagan  1,, Summary-line: 20-Jul orcutt@ATHENA.MIT.EDU #FYI Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA16513; Thu, 27 Jul 89 11:13:33 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15514; Thu, 27 Jul 89 11:10:14 EDT Received: by E40-391A-2.MIT.EDU (5.61/4.7) id AA09485; Thu, 20 Jul 89 20:18:49 -0400 Message-Id: <8907210018.AA09485@E40-391A-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: FYI Date: Thu, 20 Jul 89 20:18:45 EDT From: Ronald L. Orcutt *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: FYI Date: Thu, 20 Jul 89 20:18:45 EDT From: Ronald L. Orcutt MANAGERS' MEETING ACTION ITEMS July 18, 1989 DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT The following is an itemization of action items and responsibilities decided at the July 18, 1989 Managers' Meeting. It has not been reviewed by all managers, and should be considered only tentative at this time. Personnel and other sensitive items discussed are deliberately omitted. Present: Dan Geer, Mary Gibson, Ron Orcutt, Peter Roden, Jeff Schiller, Jackie Stewart, Shirl Merritt (taking notes) * Peter to convene meeting of VCG and Operations managers re operations support for VCG. * Managers will raise items w/r/t the Fall release needing further discussion and decision at next meeting (Aug. 1). Final decisions are due no later than the Aug. 8 meeting. One item of broad impact raised as a question is the email interface featured in Athena training and documentation (MOTIF shell, xmh, mh, or?). * At Jackie's will convene meeting in week of August 14 of all Athena managers to make sure we all understand what is committed for the Fall, and who has what responsibilities. * Jeff to organize/convene a meeting between Athena and Transarc mid- to late-August with the purpose of getting our design changes accepted and supported by Transarc. This may well need to occur in Pittsburgh. * Re workstation security in E40: decided to continue policy of securing all workstations in non-closed-office space in E40, such as the watchmaker area, in the most flexible manner possible. Peter to review and decide on best method. * Re food/drink in user-public clusters: Peter to meet with User Services re any new enforcement/inducement mechanisms required. 7:00 am janitorial cleanup noted as a growing problem, which needs to be addressed. * Re E40 security: (1) decision to change the 3rd floor combination lock as quickly as possible. Peter to meet with Jeff to review mechanism, decide on date, and produce proper announcements. (2) Managers to notify all students to turn in keys when summer employment ends. (3) Managers to turn in to Mary all extraneous keys immediately. * Jeff to provide Peter with complete server-address-location information. * Re seeding experimental use of AFS cells for faculty projects: Dan, Jeff and Peter to meet with Ann Lavin re faculty prospects. * Ron decided that complete install scripts for 3600/3900 servers should receive higher priority than PVAX portation, immediately, given that the same resources are working on both items. The install script is to be handed over to operations by the July 21. The PVAX portation must be completed ASAP so that field deployment can be scheduled for the week of Aug. 7, or earlier.  1,,motif, Summary-line: 27-Jul vanharen@ATHENA.MIT.EDU #How to get at "mwm" Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27552; Thu, 27 Jul 89 23:12:38 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27941; Thu, 27 Jul 89 23:10:15 EDT Received: by FRIES.MIT.EDU (5.61/4.7) id AA03137; Thu, 27 Jul 89 23:10:10 -0400 Message-Id: <8907280310.AA03137@FRIES.MIT.EDU> To: staff@ATHENA.MIT.EDU From: Chris VanHaren Subject: How to get at "mwm" Date: Thu, 27 Jul 89 23:10:04 EDT Sender: vanharen@ATHENA.MIT.EDU *** EOOH *** To: staff@ATHENA.MIT.EDU From: Chris VanHaren Subject: How to get at "mwm" Date: Thu, 27 Jul 89 23:10:04 EDT Sender: vanharen@ATHENA.MIT.EDU If you want to play with mwm, login to any 6.3B machine. Most of the machines in the watchmaker area are 6.3B by now. Here is how you can test mwm even if you are NOT running 6.3B. The method I am about to describe will give you the same defaults and actions as are currently installed in the 6.3B packs. As mentioned during the staff meeting on Thursday afternoon, even these defaults are open to change, so do not take these as gospel. The installed version is open to change. If you don't like these defaults, play with it a bit and get it so that you like it, don't just give up on it right away. We want to know what things you think should be in the defaults. First, get the 63B NFS pack containing the executable attached. You can mount it on /mnt or any unused mount-point. attach -m /mnt bldge40test-vsusr-63B Copy the config files to your account, and copy mwm to /tmp, so you don't have to run it over NFS and slow down everyone that's using those packs: cp /mnt/lib/X11/system.mwmrc ~/.mwmrc cp /mnt/lib/X11/app-defaults/Mwm ~/Mwm.resources cp /mnt/athena/mwm /tmp/mwm detach bldge40test-vsusr-63B Now, in order to run the program, merge the resources with yours: xrdb -merge ~/Mwm.resources (ignore error messages when you exec this, it's OK) Kill off your current window manager, and run the executable: /tmp/mwm & Now you've got the system defaults as they stand. A few quick notes on how to use it, if you've never used it before, following the dashed line at the end of this message. Even if you *have* used it before, you may find what I've said interesting, or want to add your observations to it. I'm mailing this to 'staff' to make sure that many people can see it soon. If people want to add to my comments, I propose that we continue in the "athena-workstation" discuss meeting. Now, there are a few things that I have done to my environment that I think are nicer than the system defaults for 6.3B. If you would like to try out my additions, you can do this: attach vanharen cp /mit/vanharen/Mwmrc.mine ~/.mwmrc cp /mit/vanharen/Mwmrc.resources.mine ~/Mwm.resources.mine xrdb -merge ~/Mwm.resources.mine Move the mouse to the root window, and hold down the middle-mouse button. A "Root Menu" should appear. Drag down and select "Restart". You will be asked to confirm the restart via a dialog box. Click "OK". All your windows will disappear temporarily while mwm reloads the configuration. When the windows re-appear, you will be able to focus by moving the pointer into the window, as you are used to. You will also be able to raise/lower windwows with COMP-right/left button, as are the defaults with uwm. Windows will not pop-up automatically -- you must place them with the mouse: hold down left-button to define upper-left corner, drag to move lower-right (or simply click left-button to get default size). Or via keyboard: arrows to move, RETURN for default size -- or -- SPCBAR to place upper-left, arrows to move and RETURN to define lower-right. (To move more quickly with the arrows, hold down the CTRL key, then use the arrows.) Please play with it a bit. Other people are leaving their favorite customizations in /afs/athena/mit/mwm_samples. Take a look. Add your own favorites. Thanks, Chris VanHaren ------------------------------------------------------------------------------ (1) The way the defaults are now, it is 'click-to-focus'... that is, you click on a border or title bar to be able to type into that window. You may also click anywhere within the window, but in some applications, you don't want to have to click in the application area, because that button means something there. So, the border/titlebar is safe. Clicking in a window also raises it. I do not like this method of doing things, most notably because zephyrgrams grab the focus when they pop up. To get around this, see my defaults above. You can change focus without using the mouse, however... I don't bother with this, though. (2) To move a window, grab the titlebar and drag. To resize, grab the edge or corner you want to drag. In the upper-right-hand corner of the window, there are 2 buttons. The small square is for iconifying, or "minimizing", as they call it. It will change the window into an icon, and -- place the icon for you, making sure that icons do not overlap. By default, the placement starts at lower-left and grows right, and then up for a second row if need be. If the "minimized" window disappears, check to make sure one of your windows isn't covering it up. (I place my xclock in the lower-left...) (3) Many window-manager functions are supplied on a menu, selectable by the rectangular box to the left of the title-bar. Click there, then select the function with the mouse, then perform the action. Keyboard shortcuts are listed next to functions. (Note: F11 doesn't exist.) You can also use the mnemonic supplied by typing the underlined letter while the menu is displayed. This brings up an *important* point. Most everything doable by mouse is doable by keyboard. For example, to pop up the menu, type SHIFT-ESCAPE. You can then select what you want to do via mnemonic, or just use the shortcut shown without having popped-up the menu. Then to perform a move or resize, you need not move the mouse! Use the directional arrows, and hit to confirm the action. (4) By default, new windows will place themselves without any interaction. I find this annoying, so I have disabled it. See above. You can move focus between windows without having to point-and-click, but I forget the keystrokes... That'a about all I can think of at the moment.  1,,bug-motif-form, Summary-line: 28-Jul vagarwal@ATHENA.MIT.EDU #BUGREPORT on FormDialog Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA00912; Fri, 28 Jul 89 11:50:51 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05173; Fri, 28 Jul 89 11:50:46 EDT Received: by E51-007-8.MIT.EDU (5.60/4.7) id AA25794; Fri, 28 Jul 89 11:50:36 EDT Message-Id: <8907281550.AA25794@E51-007-8.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Cc: vagarwal@ATHENA.MIT.EDU Subject: BUGREPORT on FormDialog Date: Fri, 28 Jul 89 11:50:32 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Cc: vagarwal@ATHENA.MIT.EDU Subject: BUGREPORT on FormDialog Date: Fri, 28 Jul 89 11:50:32 EDT OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: Vinay Agarwala Organization: Project Athena (Motif Development) Email Address: vagarwal@athena.mit.edu Phone: (617) 253-0173 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot 9 and ga Component (Module): Toolkit Form.c OSF License Number: Client Hardware: Client Software: Server Hardware: or SAME AS CLIENT Server Software: or SAME AS CLIENT Compiler: Problem Description ------------------- Severity Level: Severe -- represents a problem which resulted in software functionality limitation but had alternative work-around. Date of First Occurrence: One Line Description: One cannot have more than one form_dialog be a child of the same parent Full Description: The Form Dialog is created by inserting a dialog shell named "Popup" between the specified parent and the named form widget. Obviously if you create more than one form_dialog under the same parent you would essentially be trying to create child dialog shells with the same name, "Popup". It would not be possible to access any form_dialog other than the first. Repeat By: Simply make two form_dialogs as children of toplevel (you should still be able to map them) and see if you can try to change any of its arguments with XtSetArgs. You should only be able to change the args for the first form_dialog Proposed Solution: It is possible, I think, to get around the problem by just using create callbacks to identify the widget IDs, instead of XtNameToWidget or XmFetchWidget. However, I don't believe that is an adequate solution. Perhaps if instead of calling the inserted dialog_shell "Popup", it could be called "(name)Popup", where '(name)' is the name specified for the form_dialog. This would be quite a simple fix, and should effectively solve the problem.  1,,bug-motif, Summary-line: 28-Jul thm@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03115; Fri, 28 Jul 89 14:18:30 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07935; Fri, 28 Jul 89 14:18:23 EDT Received: by MYCROFT.MIT.EDU (5.61/4.7) id AA00485; Fri, 28 Jul 89 14:18:09 -0400 Date: Fri, 28 Jul 89 14:18:09 -0400 Message-Id: <8907281818.AA00485@MYCROFT.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Organization: MIT Phone: 253-1358 *** EOOH *** From: Date: Fri, 28 Jul 89 14:18:09 -0400 To: motif-bugs@ATHENA.MIT.EDU Organization: MIT Phone: 253-1358 Offering and Version: Motif snapshot 9 Component (Module): text widget Client Hardware: VS2000 4 meg Client Software: 4.3BSD, X11r3 Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: gcc Severity Level: Severe One Line Description: widget can loose focus many times without getting it Full Description: I have an application shell of vendorShellWidgetClass with focus policy set to XmEXPLICIT. A few levels down I have some text widgets. To these I've added callbacks to the XmNlosingFocusCallback and to the XmNfocusCallbacks that simply indicate that they are being called. When I click in a text widget my callback reports that the widget got the focus and a text cursor appears in the widget's window. When I click in a second text widget the first one reports that it's loosing focus and the second one reports that it's getting it, and the text cursor appears in the second widget; this is exactly what I would expect. However, when the first widget is in focus, and I click on a menu widget the following happens: the text widget reports that it's loosing the focus, as it should, and the text cursor dissapears. But then if I click on a menu again, the loosingFocusCallback is again called for the text widget, without the focusCallback ever being called; this can go on indefinitely. Finally, if I click on a menu widget and hold the button down (causing loosingFocusCallback on the text widget), move out of the application window, release the button, and move the mouse back into the application window, then the focusCallback for the text widget DOES get called. To summarize: the loosingFocusCallback of a text widget gets called repeatedly without the focusCallback getting called in between. An added note: the text in the text widget "blinks" for a moment when it looses the focus. thm  1,, Summary-line: 28-Jul rap@ATHENA.MIT.EDU #resource files and development Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08899; Fri, 28 Jul 89 19:30:45 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA14319; Fri, 28 Jul 89 19:30:35 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA03335; Fri, 28 Jul 89 19:30:19 EDT Date: Fri, 28 Jul 89 19:30:19 EDT Message-Id: <8907282330.AA03335@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: resource files and development *** EOOH *** From: Date: Fri, 28 Jul 89 19:30:19 EDT To: argus2@ATHENA.MIT.EDU Subject: resource files and development I have added code to al.c which will set the environment variable XAPPLREDIR to a profile component called 'XAppResourceFile' which is set globally to /afs/athena/mit/argus/0.6/app-defaults/ In this directory should reside our application defaults in a file called 'Argus'. The toolkit will open and read a file in this directory derrived from the class name of your application WHICH SHOULD BE 'Argus'. Here is some code to demonstrate how to open the toolkit, a display, and an application context correctly (I'm sure you all know this but we're demonstrating where the class name is here). XtToolkitInitialize(); AppCont=XtCreateApplicationContext(); dis=XtOpenDisplay(AppCont,NULL,"ruleeditor","Argus", NULL,0,&argc,argv); you then use the display (here dis) to open a shell as in. ShellW=XtAppCreateShell("ruleeditor","Argus", vendorShellWidgetClass, rei->display, ArgPack_the_args(AP), ArgPack_num_args(AP)); The important part is when you call XtOpenDisplay. In this case, the toolkit will read the file /afs/athena/mit/argus/0.6/app-defaults/Argus and the resource lines which will effect the ruleeditor begin with 'ruleeditor'. O.K. so what do we do for development? Well, reset your OWN lens profile to point to a place where you keep your development resource files. I will merge tham all at release time. __Rich.  1,,system,afs, Summary-line: 30-Jul qjb@ATHENA.MIT.EDU #rearrangement of the athena afs cell Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20057; Sun, 30 Jul 89 16:23:38 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02740; Sun, 30 Jul 89 16:20:11 EDT Received: by SOUP.MIT.EDU (5.61/4.7) id AA16854; Sun, 30 Jul 89 16:19:57 -0400 Date: Sun, 30 Jul 89 16:19:57 -0400 Message-Id: <8907302019.AA16854@SOUP.MIT.EDU> To: staff@ATHENA.MIT.EDU, vice@ATHENA.MIT.EDU, vice-squad@ATHENA.MIT.EDU Subject: rearrangement of the athena afs cell *** EOOH *** From: Date: Sun, 30 Jul 89 16:19:57 -0400 To: staff@ATHENA.MIT.EDU, vice@ATHENA.MIT.EDU, vice-squad@ATHENA.MIT.EDU Subject: rearrangement of the athena afs cell This is a report of the rearrangment of the athena.mit.edu cell that was done by Jay Berkenbilt and Richard Basch on Saturday July 29, 1989. Sorry about the length; the top part of this message is a summary and the rest is a thorough report. ------------------------------------------------------------------- This is the new layout of /afs/athena.mit.edu: /afs/athena.mit.edu service course project system contrib user a-z and other astaff project reference source Here is the justification for each of these directory names and a list of what kinds of things will go in each place. service: This is a standard afs convention introduced by CMU/transarc. It includes things that are of general use for maintanance and use of the cell. course: contains course volumes. project: contains volumes for non-athena projects. system: This contains the release system packs and a few volumes that supplement the release. smsuser is an example. user: This contains user volumes. The user directory itself contains 27 subdirectories: ``a'' through ``z'' and ``other''. User volumes will be classified according to the first letter of the name. Things not starting with lower-case letters will be under other. astaff: This contains volumes directly controlled by Project Athena. It's contents may be incomplete. It is currently subdivided as follows: project: This contains Athena development volumes for all divisions (Systems development, Applications development, operations, etc.) of Athena. kerberos is an example. reference: This contains reference sources. source: This will be the system source directory. We have decided to use singular words for all top-level directory names (i.e., project and user instead of projects and users). There is also still a directory called /afs/athena.mit.edu/mit that contains symbolic links to things that were previously mounted there. This will be disappearing on September 1. In addition, we have set up 2 new lists: bug-afs and afsreq. A discuss meeting has been set up on menelaus that will be an archive of afs bug reports. Requests for hesiod information for filesystems within afs should be sent to afsreq. These are the current contents of all top-level directories in /afs/athena.mit.edu: astaff: project: afsdev ams andrew argus gccdev jove kerberos motifdev olcdev olhdev plx pss smsdev snmp tex xps zephyr reference: 4.3bsd 4.3nfs bsd-network sunnfs3.2 ultrix3.0 source: contrib: mwm_samples rfc sipb watchmaker xpix course: project: c++ clhdev gnu webster x9700 system: decmips_30 rt_r3 smsuser vax_43 user: a: amgreene b: beth bjaspan brlewis c: carla chariot clh d: djf dkk dpeisach drmorris dschmidt e: eichin epeisach f: g: geer h: henry hoffmann i: ilham invent j: jfc jik jis jon jpkirby jtkohl k: kcmcmaho kfall kubitron kzolot l: m: mar marc mckie monkey n: o: opus p: paul probe q: qjb r: raeburn rar rfrench roman s: sctse shanzer t: tjcoppet tmdonahu tytso u: v: vanharen w: wdc wesommer who wlcarrol x: y: z: other: Here is a thorough report of what we did: Here are the steps that we took: 1. At 7:00 p.m., we made /afs/athena.mit.edu an explicit read-write mountpoint to root.cell, and released root.afs. This way, everyone would be using a read-write copy of root.cell so that our changing mountpoints and volume names would be seen immediately and no more than a few seconds of denial of access to volumes would occur at once. 2. While waiting for workstations to notice that we changed root.afs, we create the new volumes that were needed, mounted what we could in root.cell, and made mountpoints for all the volumes with there new names. Of course, at this time, the volumes were inaccessible through the new mountpoints since they had not yet been renamed. No mountpoints were removed at this time. This process took approximately 90 minutes. 3. At 9:00 p.m., we started to rename, unmount and link volumes. We figured that two hours was more than enough time for all clients to notice that /afs/athena.mit.edu was read-write instead of read-only. We did one volume at a time and we did each volume in this fashion: vos rename oldname newname -v && fs rmm oldmtpt && ln -s ../newpath This kept the time of unavailability of each volume on the order of 1 second. 4. While doing renames and deletes, we noticed that there were several volume location database inconsistencies. At this time, we shut down all the fileservers, erased the volume location databases on the primary servers, and ran syncvldb over all servers. This did succesfully replace volume location databases and remove all inconsistencies. After several minutes, however, we found what looked like another inconsistency. We tried various methods of synchronizing the vldbs on orf and maeander (upserver and upclient) and using udebug to determine the version numbers, we noticed that there was more than a one minute discrepency in the times between orf and maeander based on the servers' complaints. At this point, we syncrhonized the clocks and did another rebuild of the volume location database. This did not get rid of the inconsistency, but it did solve the time problems. We also lost contact with pollux for reasons we still don't fully understand. We think it may be related to time problems. (Perhaps a rebozo would have been better than a start?) We ran salvager over pollux. After we were done, the problem was solved. We still don't know whether one has anything to do with the other. Orf still needs to be salvaged; rt.srvd.6.2A is a wierd state. We are reasonably certain that it is in the vldb and "deleted" but still on the server. It is probably a syncvldb bug that it is in the vldb at all. In any case, we think that running salvager will fix things. There should be a way to remove something from vldb analagous to the "zap" command from vos which removes something from the server without messing with the vldb. 5. After this, we released all top-level volumes, made /afs/athena.mit.edu readonly again, and released root.afs and root.cell. 6. Finally, we checked to make sure that *every single volume* was mounted in the right place and had the right link from in mit. After making sure that everything was right, we took write access away from system:administrators on mit as this should not be changed. 7. The following morning, I went through all volumes and built a new backup list. (We moved the old backup list at 11:10 Saturday night.) I created replication sites for all volumes that were supposed to be backed up that didn't have them already. This included about 2 or 3 project volumes and about 15 user volumes. At this time, everything seems to be running normally. Pending issues: What do we do with mit/READONLY? We need the pending volumes taken care of. They are marked below in the volume list. The new layout of the cell: This is permanent: /afs/athena.mit.edu service --- mountpoint to service course --- mountpoint to course project --- mountpoint to project system --- mountpoint to system contrib --- mountpoint to contrib user --- directory containing {[a-z],other} --- mountpoints to user.a, etc. and user.other astaff --- mountpoint to astaff project --- volumes here start with aproj. reference --- volumes here start with ref. source --- volumes here start with source. This is here only until September 1 (date set by Peter Roden): mit --- contains symbolic links ONLY to things that were in mit before. No new links should be made there maint --- symbolic link to service @sys --- for rt, vax, and mips: links to system/@sys for packs root --- a symbolic link to @sys I would argue that mit should stick around until about September 1, but that we can remove @sys as soon as 6.3B goes to staff. 6.3A is the only release that depends on maint, only the non-testers 6.3A afs packs are still around in @sys for rt, and there are few enough people using the mips software that they can just be told what the new location is. The 6.2 packs were removed since they were inaccessible to anyone outside of system:administrators and since no one running 6.2 probably has afs anyway as all of E40 is running 6.3. Volume naming conventions and new names: We have adopted a volume naming convention. All non-top-level volumes will have a name of the following form: category.controlling-entity[.section][.attributes] category currently can be one of astaff, contrib, course, project, system, aproj, ref, source, or user. controlling-entity is the project name for projects, the course name for courses, the user name for users, etc. An example is user.testuser. section will often be absent, but will be present in some cases. For example, kerberos sources are an a volume called aproj.kerberos. This volume should be backed up. However, the configuration directories for rt, vax, and mips are part of kerberos project and do not have to be backed up and they can be easily regenerated. They are named aproj.kerberos.rt.nb, aproj.kerberos.vax.nb, and aproj.kerberos.mips.nb. Attributes are defined by afs convention for .backup and .readonly. We are including our own convention .nb to mean that the volume should not be backed up automatically by the backup script. This could mean either that we do not back it up at all or that it will be backed up manually with some unusual scheme. The top level volumes have the names of the directories except for in user. That is, there are volumes called astaff, contrib, course, project, service, and system. user is a directory containing 27 volumes: user.a through user.z and user.other. We must make sure that no one registers with the username other. It is quite possible that when registering new users, in addition to checking to see whether the name is used anywhere in kerberos or moira, we should check to see whether the name is used in afs. The semantics for doing this are not clear, however. Following is a list of all the volumes in the athena cell as of 11:00 a.m. 7/28/1989 and what we did to them. means that we have not done anything because we don't know what should be done. (These are private volumes owned by people we couldn't find.) There are two volumes that we have new names for but have not renamed yet. They are marked here as well. a-andy-r4 aproj.andrew.r4.nb a-andy-r4.src aproj.andrew.r4.src.nb aproj.kerberos aproj.kerberos aproj.kerberos.mips.nb aproj.kerberos.mips.nb aproj.kerberos.rt.nb aproj.kerberos.rt.nb aproj.kerberos.vax.nb aproj.kerberos.vax.nb argus aproj.argus beeblebrox user.marc.beeblebrox.nb circe.vicepa disk.circe.a circe.vicepb disk.circe.b circe.vicepc disk.circe.c circe.vicepd disk.circe.d circe.vicepe disk.circe.e cplusplus project.cplusplus.nb fratg jove aproj.jove klogs maeander.vicepa disk.maeander.a maeander.vicepb disk.maeander.b maeander.vicepc disk.maeander.c maint service mips.usr system.mips.usr motifdev aproj.motifdev motifdev.projects aproj.motifdev.projects motifdev.src aproj.motifdev.src motifdev.widgets aproj.motifdev.widgets nb.mwm.samples contrib.mwm-samples.nb ntp olhdev aproj.olhdev orf.vicepa disk.orf.a orf.vicepb disk.orf.b orf.vicepc disk.orf.c orf.vicepd disk.orf.d orf.vicepe disk.orf.e pollux.vicepa disk.pollux.a pollux.vicepb disk.pollux.b pollux.vicepc disk.pollux.c pollux.vicepd disk.pollux.d pollux.vicepe disk.pollux.e pss aproj.pss.nb pss.src aproj.pss.src ref.4.3bsd ref.4.3bsd ref.4.3nfs ref.4.3nfs ref.bsd-network ref.bsd-network ref.sunnfs3.2 ref.sunnfs3.2 rfc contrib.rfc.nb root.afs root.afs root.andrew aproj.andrew root.astaff astaff root.cell root.cell rt.andrew aproj.andrew.rt.nb rt.srvd rt.srvd.6.2A rt.srvd.6.3A system.rt.srvd.6.3A rt.urvd rt.urvd.6.2A rt.urvd.6.3A system.rt.urvd.6.3A rt.urvd.athena rt.urvd.lib smsuser system.smsuser snmp aproj.snmp.nb src.rtsys src.vaxsys sysdev.xps aproj.xps ultrix3.0 ref.ultrix3.0 user.afsdev aproj.afsdev user.amgreene user.amgreene user.ams aproj.ams user.beth user.beth user.bjaspan user.bjaspan user.brlewis user.brlewis user.carla user.carla user.cgw user.chariot user.chariot user.clh user.clh user.clhdev project.clhdev user.djf user.djf user.dkk user.dkk user.dpeisach user.dpeisach user.drmorris user.drmorris user.dschmidt user.dschmidt user.eichin user.eichin user.epeisach user.epeisach user.gccdev aproj.gccdev user.geer user.geer user.gnu project.gnu.nb user.hoffmann user.hoffmann user.ilham user.ilham user.invent user.invent user.jfc user.jfc user.jfc.build user.jfc.build.nb user.jik user.jik user.jis user.jis user.jis.snmp user.jis.snmp.nb user.jis.vc user.jis.vc.nb user.jon user.jon user.jpkirby user.jpkirby user.jtkohl user.jtkohl user.kcmcmaho user.kcmcmaho user.kfall user.kfall user.kubitron user.kubitron user.kzolot user.kzolot user.mar user.mar user.marc user.marc user.mckie user.mckie user.monkey user.monkey user.ncs user.olcdev aproj.olcdev user.opus user.opus user.paul user.paul user.probe user.probe user.qjb user.qjb user.raeburn user.raeburn user.rar user.rar user.rfrench user.rfrench user.roman user.roman user.sctse user.sctse user.shanzer user.shanzer user.sipb contrib.sipb.nb user.smsdev aproj.smsdev user.testuser user.tex aproj.tex user.tjcoppet user.tjcoppet user.tmdonahu user.tmdonahu user.tytso user.tytso user.vanharen user.vanharen user.wdc user.wdc user.webster project.webster.nb user.wesommer user.wesommer user.who user.who user.wlcarrol user.wlcarrol vax.andrew aproj.andrew.vax.nb vax.srvd.6.2A vax.srvd.6.3A system.vax.srvd.6.3A vax.urvd.6.2A vax.urvd.6.3A system.vax.urvd.6.3A vax.urvd.rs1 wm.afs contrib.watchmaker.nb x9700 project.x9700.nb xpix contrib.xpix.nb zephyr.main aproj.zephyr zephyr.mips.nb aproj.zephyr.mips.nb zephyr.rt.nb aproj.zephyr.rt.nb zephyr.vax.nb aproj.zephyr.vax.nb Requests: Requests for new afs volumes should be sent to afsreq. Requests to get hesiod information updated for filesystems so that they point into the afs cell should also be sent here. Afs bugs should be sent to bug-afs. The vice-squad list will be a discussion mailing list for afs system:administrators. There will be discuss meetings associated with these, but, for now, only bug-afs will be public.  1,, Summary-line: 30-Jul bjaspan@ATHENA.MIT.EDU #New location Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20631; Sun, 30 Jul 89 18:03:49 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA03692; Sun, 30 Jul 89 18:03:40 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA15432; Sun, 30 Jul 89 18:03:26 -0400 Date: Sun, 30 Jul 89 18:03:26 -0400 Message-Id: <8907302203.AA15432@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU Subject: New location *** EOOH *** Date: Sun, 30 Jul 89 18:03:26 -0400 From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU Subject: New location Just in case some of you did not get the mail about the new AFS structure: The motifdev directory has been moved. It is now in /afs/athena.mit.edu/astaff/projects/motifdev. There is a symlink from the old location for now, but that will be going away sometime (probably September, but you should convert makefiles, etc., immediately.) Barr3y  1,,system, Summary-line: 31-Jul ackerman@ATHENA.MIT.EDU #postps (aka viewdoc) Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22958; Mon, 31 Jul 89 01:56:28 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07223; Mon, 31 Jul 89 01:55:59 EDT Received: by E40-358-18.MIT.EDU (5.60/4.7) id AA25940; Mon, 31 Jul 89 01:55:47 EDT Message-Id: <8907310555.AA25940@E40-358-18.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: mackay@ATHENA.MIT.EDU, swertheim@ATHENA.MIT.EDU, mory@ATHENA.MIT.EDU Subject: postps (aka viewdoc) Date: Mon, 31 Jul 89 01:55:43 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Cc: mackay@ATHENA.MIT.EDU, swertheim@ATHENA.MIT.EDU, mory@ATHENA.MIT.EDU Subject: postps (aka viewdoc) Date: Mon, 31 Jul 89 01:55:43 EDT If you have been having trouble with font names, please use the new versions in visual2: ackerman/postps/vax and ackerman/postps/rt. Also take the .postpsfonts file in those directories. Note that the .psfonts file no longer has any effect. All font names are now R3. Ack  1,,system, Summary-line: 1-Aug qjb@ATHENA.MIT.EDU #AFS requests Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06816; Tue, 1 Aug 89 08:43:48 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27222; Tue, 1 Aug 89 08:40:56 EDT Received: by SOUP.MIT.EDU (5.61/4.7) id AA03373; Tue, 1 Aug 89 08:40:33 -0400 Date: Tue, 1 Aug 89 08:40:33 -0400 Message-Id: <8908011240.AA03373@SOUP.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: AFS requests *** EOOH *** From: Date: Tue, 1 Aug 89 08:40:33 -0400 To: staff@ATHENA.MIT.EDU Subject: AFS requests In our exteremely long mail message sent out a few days ago, there were a few pieces of information that everyone should have had: Requests for AFS volumes, new users to be added, hesiod pointers to be created to afs volumes, etc, should be mailed to afsreq. ^^^^^^ AFS bugs should be mailed to bug-afs. There is a public discuss meeting fed by this as well. The vice-squad mailing list is being phased out or reserved for communcation between afs administrators about the administration of the cell. Thanks Jay Berkenbilt  1,,system, Summary-line: 1-Aug roden@ATHENA.MIT.EDU #Emergency Operations Coverage Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13388; Tue, 1 Aug 89 16:23:40 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05540; Tue, 1 Aug 89 16:22:16 EDT Received: by E40-355-P.MIT.EDU (5.61/4.7) id AA22422; Tue, 1 Aug 89 16:21:50 -0400 Message-Id: <8908012021.AA22422@E40-355-P.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Emergency Operations Coverage Date: Tue, 01 Aug 89 16:21:43 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Subject: Emergency Operations Coverage Date: Tue, 01 Aug 89 16:21:43 EDT If you need to contact someone from operations in an EMERGENCY situation, such as fire, flood, theft, etc., you can call the beeper at (800) 412-3610. An operations systems staff member is on "beeper duty" 24 hours a day. You can try to "zlocate" various operations staff members between 9am and 11:30pm (paul,dkk, invent and roden) to answer other questions. Also, you can send mail to "hotline" where operators are standing by from 7:30am to 11:30pm.  1,, Summary-line: 1-Aug bjaspan@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA14229; Tue, 1 Aug 89 17:16:16 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA06626; Tue, 1 Aug 89 17:16:23 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA25951; Tue, 1 Aug 89 17:16:04 -0400 Date: Tue, 1 Aug 89 17:16:04 -0400 Message-Id: <8908012116.AA25951@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif-bugs@ATHENA.MIT.EDU *** EOOH *** Date: Tue, 1 Aug 89 17:16:04 -0400 From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif-bugs@ATHENA.MIT.EDU OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: Barry Jaspan Organization: MIT Project Athena, sysdev Email Address: bjaspan@athena.mit.edu Phone: (617) 253-4261 Hardware/Software Configuration ------------------------------- Offering and Version: Motif GA Component (Module): MRM (MrmRegisterNames()) OSF License Number: N/A Client Hardware: " Client Software: " Server Hardware: " Server Software: " Compiler: " Problem Description ------------------- Severity Level: Severe (but very close to criticial) Date of First Occurrence: N/A One Line Description: There is not a function MrmAppRegisterNames(), and there needs to be. Full Description: I am writing the Xt/Motif server, which supports multiple clients. I just discovered that Motif function calls ignore Xt application contexts. Since MrmRegisterNames() assumes there is only one app context, it is possible (and therefore inevitable) that there will be name conflicts between clients. There is ALMOST a work around, in that the server could make each name unique before passing it to MrmRegisterNames(). This would involve something like appending the number of seconds since 1970 to the name (appending the client name is no good, as the server must be able to support multiple instances of the same client simultaneously.) This, however, qualifies is a full-grown distgusting hack that I would not want to bring home to mother, and is certainly not the way to design a server. Repeat By: N/A Proposed Solution: Introduce application context-aware functions to Motif wherever appropriate. MrmRegisterNames is only the first I have come across that requires it; there may be others. Following the Xt naming standard, the function name should be MrmAppRegisterNames() and the app context should be the first argument to the function. (This, of course, assumes MrmRegisterNames' name does not change again.)  1,edited,, Summary-line: 1-Aug bgardner@ATHENA.MIT.EDU #MOTIF TEST IGNORE THIS Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17214; Tue, 1 Aug 89 21:44:01 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10551; Tue, 1 Aug 89 21:44:09 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA02911; Tue, 1 Aug 89 21:43:49 -0400 Date: Tue, 1 Aug 89 21:43:49 -0400 Message-Id: <8908020143.AA02911@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU *** EOOH *** From: Date: Tue, 1 Aug 89 21:43:49 -0400 To: rap@ATHENA.MIT.EDU Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15576; Tue, 1 Aug 89 19:03:18 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08434; Tue, 1 Aug 89 19:03:23 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA02782; Tue, 1 Aug 89 19:03:04 -0400 Date: Tue, 1 Aug 89 19:03:04 -0400 Message-Id: <8908012303.AA02782@PINK.MIT.EDU> To: bgardner@ATHENA.MIT.EDU Subject: MOTIF TEST IGNORE THIS Comment: OSF UEC Problem Report ================================= Comment: Submitter Information (Include if not in News/mail headers) --------------------- Submitter-Name: Brian Gardner Organization: athena / motif Email-Address: bgardner@athena.mit.edu Phone: (617) 253-4277 Comment: Hardware/Software Configuration ------------------------------- Offering-and-Version: Motif snapshot 8 Component-or-Module: OSF-License-Number: Client-Hardware: Client-Software: Server-Hardware: or SAME AS CLIENT Server-Software: or SAME AS CLIENT Compiler: Comment: Problem Description ------------------- Severity-Level: Incompatibility -- represents a problem which resulted from inability to install the software on the machine. Fatal -- represents a problem which resulted in a software crash or required reboot of the software. Critical -- represents a problem which resulted in software malfunction or a feature failure and has no work-around. Severe -- represents a problem which resulted in software functionality limitation but had alternative work-around. Minor -- represents a cosmetic type problem. Enhancement -- represents a request for enhancement of the software. Date-of-First-Occurrence: One-Line-Description: Full Description: Repeat By: Proposed Solution:  1,,system, Summary-line: 2-Aug swick@ATHENA.MIT.EDU #twm available for testing Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25402; Wed, 2 Aug 89 15:25:37 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23769; Wed, 2 Aug 89 15:23:52 EDT Received: by LYRE.MIT.EDU (5.60/4.7) id AA02316; Wed, 2 Aug 89 15:23:30 EDT Message-Id: <8908021923.AA02316@LYRE.MIT.EDU> To: sysdev@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: twm available for testing Date: Wed, 02 Aug 89 15:23:26 EDT From: Ralph R. Swick *** EOOH *** To: sysdev@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: twm available for testing Date: Wed, 02 Aug 89 15:23:26 EDT From: Ralph R. Swick I just put a brand-new binary in /mit/StaffTools/vaxbin/twm for anyone who wishes to experiment. You will probably want a .twmrc file in $HOME; there are several to choose from in /mit/StaffTools/examples/twm; I suggest you make a symlink to the one you want. The file labelled 'uwm.twmrc' is a moderately close representation of what I thought were the most common uwm buttons. There are one or two operations that uwm supports that can't currently be emulated in twm, but I doubt many users know about them. The man page is in /mit/StaffTools/man/mann/twm.n I will build an rt binary as soon as I can find the time.  0,unseen,, Summary-line: 3-Aug rap@ATHENA.MIT.EDU #[post@xanadu.enet.dec.com: I don't know if you got this, (our mail gateway was down) URGENT"!!!] Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03928; Thu, 3 Aug 89 11:44:47 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08770; Thu, 3 Aug 89 11:44:44 EDT Received: by MORPHEUS.MIT.EDU (5.60/4.7) id AA04093; Thu, 3 Aug 89 11:44:10 EDT Date: Thu, 3 Aug 89 11:44:10 EDT Message-Id: <8908031544.AA04093@MORPHEUS.MIT.EDU> To: mackay@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: [post@xanadu.enet.dec.com: I don't know if you got this, (our mail gateway was down) URGENT"!!!] Checking again, We are not to oblidge these requests are we? >Date: Thu, 3 Aug 89 06:54:19 PDT >From: post@xanadu.enet.dec.com >To: rap@ATHENA.MIT.EDU >Subject: I don't know if you got this, (our mail gateway was down) URGENT"!!! > >Rich: > >I know you are going on vacation, could you PLEASE do this if you get this >before you go away.... > >Thanks... > >Mark > > >>From: XANADU::POST 25-JUL-1989 14:42:48.46 >>To: DECWRL::"rap@ATHENA.MIT.EDU" >>CC: POST, BOCK >>Subj: More example rule set files > >>Rich: > >>Last week got runrules working completely under Ultrix"!!! > >>I used a modified version of the example ruleset you sent up (as we don't >>have a ruleset editor yet). I've played around with changing message types, >>but would like additional rule set files to use as examples (the only >>if operator in the example was "%contains", and then operator was "%move-to"). >>In particular, I would like example ruleset files that contain operators that >>work on non-text fields (Date, etc.) and then clauses which execute system >>commands (in addition, other non-mail actions like runrules and user properties) >>Thanks (in advance) > >>Mark J. Post  0,unseen,, Summary-line: 3-Aug thm@ATHENA.MIT.EDU #alpop Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA04046; Thu, 3 Aug 89 11:53:03 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08941; Thu, 3 Aug 89 11:53:12 EDT Received: by MYCROFT.MIT.EDU (5.61/4.7) id AA11970; Thu, 3 Aug 89 11:52:43 -0400 Date: Thu, 3 Aug 89 11:52:43 -0400 Message-Id: <8908031552.AA11970@MYCROFT.MIT.EDU> To: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Thu, 3 Aug 89 11:45:28 EDT <8908031545.AA04098@MORPHEUS.MIT.EDU> Subject: alpop Thanks. Also, are those your diagnostics that print to stdout whenever AlPop_Query is called??? thm  0,unseen,, Summary-line: 3-Aug janej@ATHENA.MIT.EDU #I will not be here tomorrow, Friday 8/4. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05800; Thu, 3 Aug 89 14:13:24 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11624; Thu, 3 Aug 89 14:12:12 EDT Received: by E40-337-1.MIT.EDU (5.61/4.7) id AA28295; Thu, 3 Aug 89 14:11:49 -0400 Message-Id: <8908031811.AA28295@E40-337-1.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: janej@ATHENA.MIT.EDU Subject: I will not be here tomorrow, Friday 8/4. Date: Thu, 03 Aug 89 14:11:46 EDT Please see Mary for any "locked up" office supplies. Jane  1,, Summary-line: 3-Aug kcunning@ATHENA.MIT.EDU #xlogin changes Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05916; Thu, 3 Aug 89 14:17:33 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11736; Thu, 3 Aug 89 14:16:59 EDT Received: by E40-371-1.MIT.EDU (5.61/4.7) id AA24394; Thu, 3 Aug 89 14:16:34 -0400 Message-Id: <8908031816.AA24394@E40-371-1.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: managers@ATHENA.MIT.EDU Subject: xlogin changes Date: Thu, 03 Aug 89 14:16:26 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Cc: managers@ATHENA.MIT.EDU Subject: xlogin changes Date: Thu, 03 Aug 89 14:16:26 EDT As Ron suggested, a committee was formed to consider what revisions were appropriate for the xlogin interface. That committee met today and discussed all of the issues and reached a concensus on the set of changes to make, and who should undertake each task. Where can you find out what's going to be changed? - view the file /mit/logos/6.3/interface.PS (or .doc) - use /mit/sipb/*bin/idraw to view /mit/logos/6.3/display.idraw - you can also use plain lpr to print these files out Who's making the revisions? Roman Budzianowski: - make all proposed changes except those listed below Anne Lavin: - revise owl (smaller, say one inch diameter?) Chris VanHaren: - eliminate extra title bar for console window in mwm version * - remove "Close" option from mwm menu for console window * Kevin Cunningham: - provide a "make console reappear" script in release * - review/rewrite some messages (e.g., home dir cannot be attached) - make sure that Xsession is revised appropriately in conjunction with planned revisions * - make sure that system configuration files are revised appropriately in conjunction with planned revisions * these changes are to be made in conjunction with Ezra Peisach These changes should help make xlogin a welcome addition to Athena this Fall. --Kevin (with roman, garybean, aleslie, carla, djf, lavin)  1,, Summary-line: 3-Aug bjaspan@ATHENA.MIT.EDU #XmToggleButtonSetState() Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08215; Thu, 3 Aug 89 16:32:24 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA14501; Thu, 3 Aug 89 16:32:20 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA06526; Thu, 3 Aug 89 16:31:53 -0400 Date: Thu, 3 Aug 89 16:31:53 -0400 Message-Id: <8908032031.AA06526@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU Subject: XmToggleButtonSetState() *** EOOH *** Date: Thu, 3 Aug 89 16:31:53 -0400 From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU Subject: XmToggleButtonSetState() XmToggleButtonSetState() is not working and I am getting pissed off. I know I am using it correctly, because right after I call it I call XmToggleButtonGetState() and dislay the results, and the state is getting set correctly. But when I display the toggle buttons, they are not set. Anyone have any ideas? The source is in /afs/athena/user/b/bjaspan/src/xzwrite/motif/interface.c. Thanks, Barr3y  1,, Summary-line: 3-Aug orcutt@ATHENA.MIT.EDU #DRAFT of Managers' Meeting Action Items Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA10861; Thu, 3 Aug 89 20:21:52 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA18688; Thu, 3 Aug 89 20:20:47 EDT Received: by E40-391A-2.MIT.EDU (5.61/4.7) id AA01127; Thu, 3 Aug 89 20:20:18 -0400 Message-Id: <8908040020.AA01127@E40-391A-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: DRAFT of Managers' Meeting Action Items Date: Thu, 03 Aug 89 20:20:13 EDT From: Ronald L. Orcutt *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: DRAFT of Managers' Meeting Action Items Date: Thu, 03 Aug 89 20:20:13 EDT From: Ronald L. Orcutt MANAGERS' MEETING ACTION AND DECISION ITEMS August 1, 1989 DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT The following is an itemization of action items and responsibilities decided at the August 1, 1989 Managers' Meeting. It has not been reviewed by all managers, and should be considered only tentative at this time. Personnel and other sensitive items discussed are deliberately omitted. Present: Dan Geer, Mary Gibson, Ron Orcutt, Peter Roden, Jackie Stewart, Shirl Merritt (taking notes) Absent: Jeff Schiller * Managers to provide Ron with recommendations of staff for the task force planning the EDUCOM Conference activities. * The managers approved the request for the Athena staff list to be made available to the community on-line. Mary Gibson will contact Beth Anderson re format/contents (e.g., functional responsibilities), and provide data for Ron's decision. * Peter Roden will review W20-575 clusters and designate a subset of workstations there to receive advanced releases for public testing. * Jackie will schedule a meeting with Rob French and SIPB to discuss SIPB support for Athena. * The OLC server will be moved to the E40 basement; operational support will be assumed by Operations. Peter to develop a proposal for availability and off-hour support for the server. * OLTA service will be made available to the community as of the Fall term. * Peter Roden will normally attend Physical Plant's weekly managers status meetings. * Peter and Ron to meet and resolve proposal for A/V Dept. to provide lightvalve support for classrooms. * Jackie will discuss Fishbowl schedule issues with Ben Davis, and bring proposal back to Managers at Aug. 8 meeting. * Dan will provide managers with weekly status report on Sys. Dev. projects with due dates, and staffing assignments. Mary to review administrative support needs of Sys. Dev., User Services, and Operations and increase staffing plans as required. * Peter and Jerry Burke (I.S. Microcomputer Support Center) to meet with Ron on Aug. 16 on IBM maintenance support from I.S. * Dan raised issue of providing input to Provost Commitee by Athena management. This item was raised to Directors' Meeting for discussion. * Release 6.3 release decision processes were discussed; the Aug. 8 Managers' meeting will make final decisions w/r/t the release. * The prior decision to support 4.3 BSD portation to the PMAX was rescinded; ULTRIX will be the only supported o.s. on that platform. * Open item: need to schedule a stress test of the registration server under the new release in mid-August.  1,, Summary-line: 4-Aug bjaspan@ATHENA.MIT.EDU #Xt/Motif server information Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15953; Fri, 4 Aug 89 11:35:29 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28244; Fri, 4 Aug 89 11:35:22 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA11875; Fri, 4 Aug 89 11:34:56 -0400 Date: Fri, 4 Aug 89 11:34:56 -0400 Message-Id: <8908041534.AA11875@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU Subject: Xt/Motif server information *** EOOH *** Date: Fri, 4 Aug 89 11:34:56 -0400 From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU Subject: Xt/Motif server information The Xt/Motif server is approaching a useful level of function. I have solved most of the hard problems (at least, I *think* so.) Most of the work now is grunt work; just simply adding the myriads of function calls that programs use (like XmTextSetString, etc.) What I would like is for people to send me mail telling me what Xt, Xm, Mrm function calls you use in your client applications. This will tell me what functions to implement first, so that we can start actually running some clients off this server. The function calls that are supported so far are: XtInitialize XtCreateWidget XtManageChild XtSetValues XtNameToWidget XtAddCallback XtRealizeWidget MrmOpenHierarchy MrmRegisterNames MrmFetchWidget (My previous opinion to the contrary, callbacks from uil files work.) When I'm ready I'll tell people how to compile their programs so they work with the server (basically, you will have to add one #include line to your interface .c file, and link against different libraries, and that is ALL). If you're curious, look in /afs/athena/user/b/bjaspan/src/Xtd/client.c for what an Xtd client looks like. So, again, tell me ALL the Motif or Xt function calls you use, no matter how trivial. Thanks! Barr3y  1,, Summary-line: 4-Aug jnrees@ATHENA.MIT.EDU #Xt/Motif server information Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA16177; Fri, 4 Aug 89 11:52:02 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28552; Fri, 4 Aug 89 11:51:50 EDT Received: by E40-315-5.MIT.EDU (5.61/4.7) id AA04293; Fri, 4 Aug 89 11:51:06 -0400 Date: Fri, 4 Aug 89 11:51:06 -0400 Message-Id: <8908041551.AA04293@E40-315-5.MIT.EDU> To: bjaspan@ATHENA.MIT.EDU Cc: motif@ATHENA.MIT.EDU In-Reply-To: Barr3y Jaspan's message of Fri, 4 Aug 89 11:34:56 -0400 <8908041534.AA11875@ANATHEMA.MIT.EDU> Subject: Xt/Motif server information *** EOOH *** From: Date: Fri, 4 Aug 89 11:51:06 -0400 To: bjaspan@ATHENA.MIT.EDU Cc: motif@ATHENA.MIT.EDU In-Reply-To: Barr3y Jaspan's message of Fri, 4 Aug 89 11:34:56 -0400 <8908041534.AA11875@ANATHEMA.MIT.EDU> Subject: Xt/Motif server information Functions that my project needs which aren't included in your list are: XtAddConverter XtGetGC XtReleaseGC XtCallCallbacks XtDisplay XtWindow i.e. does your server offer support for widgets which we have created ourselves? Does your version of XtCreateWidget handle the case where the widget class pointer points to data on the client end? I wouldn't expect the server to contain the widget code, but it could offer substantial support with regards to shared GC's, translation table and actions table processing, etc. Oh and one other thing which wasn't on your list, XtMainLoop (??) -JIM  1,, Summary-line: 4-Aug aagleckl@ATHENA.MIT.EDU #Xt/Motif server information Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA16283; Fri, 4 Aug 89 11:55:52 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28625; Fri, 4 Aug 89 11:55:46 EDT Received: by CHOWPEENTULK.MIT.EDU (5.61/4.7) id AA14765; Fri, 4 Aug 89 11:55:16 -0400 Date: Fri, 4 Aug 89 11:55:16 -0400 Message-Id: <8908041555.AA14765@CHOWPEENTULK.MIT.EDU> To: bjaspan@ATHENA.MIT.EDU Cc: motif@ATHENA.MIT.EDU In-Reply-To: Barr3y Jaspan's message of Fri, 4 Aug 89 11:34:56 -0400 <8908041534.AA11875@ANATHEMA.MIT.EDU> Subject: Xt/Motif server information Reply-To: aagleckl@ATHENA.MIT.EDU *** EOOH *** From: Date: Fri, 4 Aug 89 11:55:16 -0400 To: bjaspan@ATHENA.MIT.EDU Cc: motif@ATHENA.MIT.EDU In-Reply-To: Barr3y Jaspan's message of Fri, 4 Aug 89 11:34:56 -0400 <8908041534.AA11875@ANATHEMA.MIT.EDU> Subject: Xt/Motif server information Reply-To: aagleckl@ATHENA.MIT.EDU Here are all the things I use which weren't on the list you sent: XmCreateInformationDialog XmCreatePushButton XmListAddItemUnselected XmListDeletePos XmListSelectPos XmStringCreate XmStringCreateLtoR XmTextGetString XmTextSetString XtAppCreateShell XtCalloc XtDestroyWidget XtMapWidget XtUnmapWidget  0,unseen,, Summary-line: 4-Aug bjaspan@ATHENA.MIT.EDU #Toggle Buttons Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17013; Fri, 4 Aug 89 12:52:13 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29589; Fri, 4 Aug 89 12:52:15 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA11988; Fri, 4 Aug 89 12:51:37 -0400 Date: Fri, 4 Aug 89 12:51:37 -0400 Message-Id: <8908041651.AA11988@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU Subject: Toggle Buttons OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: Barr3y Jaspan Organization: MIT Project Athena Email Address: bjaspan@athena.mit.edu Phone: (617) 253-4261 Hardware/Software Configuration ------------------------------- Offering and Version: Motif GA Component (Module): Toolkit (ToggleButton) OSF License Number: Client Hardware: Digital VAX VS2, 5MB Client Software: X11R3 Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: cc Problem Description ------------------- Severity Level: Severe Date of First Occurrence: 8/4/89 One Line Description: A toggle button widget always calls the arm and disarm callbacks when either event occurs. Full Description: I have the same callback registered for both XmNarmCallback and XmNdisarmCallback. The function displays the reason and the state of the toggle. Each time the state changes, the callback is called twice, once with the reason ARM and once with the reason DISARM. Repeat By: Create a toggle button and give it a callback for arm and/or disarm, and observe when it is invoked. Proposed Solution: The callback should only be called ONCE when the state changes; ie: when it button is armed, the callback should be called once with a reason of ARM; similarly for disarm. It is possible to work around this bug by checking the set field of the callback structure and ignoring any reason/set pairs that don't make sense. But that means the callback is invoked twice as many times as is necessary.  0,unseen,, Summary-line: 4-Aug bjaspan@ATHENA.MIT.EDU #Toggle buttons Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17093; Fri, 4 Aug 89 12:55:24 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29632; Fri, 4 Aug 89 12:55:38 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA11996; Fri, 4 Aug 89 12:55:14 -0400 Date: Fri, 4 Aug 89 12:55:14 -0400 Message-Id: <8908041655.AA11996@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif-bugs@ATHENA.MIT.EDU Subject: Toggle buttons OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: Barr3y Jaspan Organization: MIT Project Athena Email Address: bjaspan@athena.mit.edu Phone: (617) 253-4261 Hardware/Software Configuration ------------------------------- Offering and Version: Motif GA Component (Module): Toolkit (ToggleButton) OSF License Number: Client Hardware: Digital VAX VS2, 5MB Client Software: X11R3 Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: cc Problem Description ------------------- Severity Level: Severe Date of First Occurrence: 8/4/89 One Line Description: A toggle button widget always calls the arm and disarm callbacks when either event occurs. Full Description: I have the same callback registered for both XmNarmCallback and XmNdisarmCallback. The function displays the reason and the state of the toggle. Each time the state changes, the callback is called twice, once with the reason ARM and once with the reason DISARM. Repeat By: Create a toggle button and give it a callback for arm and/or disarm, and observe when it is invoked. Proposed Solution: The callback should only be called ONCE when the state changes; ie: when it button is armed, the callback should be called once with a reason of ARM; similarly for disarm. It is possible to work around this bug by checking the set field of the callback structure and ignoring any reason/set pairs that don't make sense. But that means the callback is invoked twice as many times as is necessary.  0,unseen,, Summary-line: 4-Aug bjaspan@ATHENA.MIT.EDU #Toggle Buttons Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17117; Fri, 4 Aug 89 12:56:00 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29636; Fri, 4 Aug 89 12:56:05 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA11999; Fri, 4 Aug 89 12:55:41 -0400 Date: Fri, 4 Aug 89 12:55:41 -0400 Message-Id: <8908041655.AA11999@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU In-Reply-To: Barr3y Jaspan's message of Fri, 4 Aug 89 12:51:37 -0400 <8908041651.AA11988@ANATHEMA.MIT.EDU> Subject: Toggle Buttons Oops.. sorry about that. I typed the wrong "to" field.. Barr3y  0,unseen,, Summary-line: 4-Aug bjaspan@ATHENA.MIT.EDU #Oops, again. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17659; Fri, 4 Aug 89 13:31:54 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA00350; Fri, 4 Aug 89 13:31:55 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA12017; Fri, 4 Aug 89 13:31:25 -0400 Date: Fri, 4 Aug 89 13:31:25 -0400 Message-Id: <8908041731.AA12017@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU Subject: Oops, again. XtMainLoop() is of course already supported by the server.. I didn't think to list it. :-) Barr3y  0,unseen,, Summary-line: 4-Aug maya@ATHENA.MIT.EDU #byebyes and sniglets Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17717; Fri, 4 Aug 89 13:33:12 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA00378; Fri, 4 Aug 89 13:32:59 EDT Received: by E40-115A-1.MIT.EDU (5.60/4.7) id AA28825; Fri, 4 Aug 89 13:32:22 EDT Message-Id: <8908041732.AA28825@E40-115A-1.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: byebyes and sniglets Date: Fri, 04 Aug 89 13:32:17 EDT I'm going to be out of town and out of touch until August 15th. I hope you all had a good time at SIGGRAPH, and that fun and exciting things get done while I'm gone. I'd appreciate getting the mail on major updates so I can read it when I return, of course. I sure hope the weather gets cooler by the time I return. --- Maya carperpetuation: the act, when vacuuming, of going over the same piece of string several times, picking it up and examining it, then putting it back down on the ground to give the vacuum one more chance. [this is by far my favorite sniglet.]  1,, Summary-line: 4-Aug roden@ATHENA.MIT.EDU #Helen and Agamemnon Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA19706; Fri, 4 Aug 89 15:57:16 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA03128; Fri, 4 Aug 89 15:55:31 EDT Received: by E40-355-P.MIT.EDU (5.61/4.7) id AA04478; Fri, 4 Aug 89 15:55:04 -0400 Message-Id: <8908041955.AA04478@E40-355-P.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Helen and Agamemnon Date: Fri, 04 Aug 89 15:54:57 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Subject: Helen and Agamemnon Date: Fri, 04 Aug 89 15:54:57 EDT For your information, during the week of August 7th, Helen and Agamemnon (the 750s) will be shut down and decomissioned to make way for new 3600 systems.  1,, Summary-line: 4-Aug rap@ATHENA.MIT.EDU #I love the debuggers for the rt Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21984; Fri, 4 Aug 89 18:53:18 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA06201; Fri, 4 Aug 89 18:53:31 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA12492; Fri, 4 Aug 89 18:52:50 EDT Date: Fri, 4 Aug 89 18:52:50 EDT Message-Id: <8908042252.AA12492@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: I love the debuggers for the rt *** EOOH *** From: Date: Fri, 4 Aug 89 18:52:50 EDT To: argus2@ATHENA.MIT.EDU Subject: I love the debuggers for the rt This is a trace... 918 else{ (gdb) 923 if (container==NULL) (gdb) 925 SrcWin=XtWindow(container); (gdb) p container $8 = (Widget) 0x0 (gdb) quit The code acts as if container !=NULL but the debugger thinks it is! __Rich.  1,, Summary-line: 4-Aug rap@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23082; Fri, 4 Aug 89 21:17:16 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08067; Fri, 4 Aug 89 21:17:29 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA13250; Fri, 4 Aug 89 21:16:44 EDT Date: Fri, 4 Aug 89 21:16:44 EDT Message-Id: <8908050116.AA13250@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU *** EOOH *** From: Date: Fri, 4 Aug 89 21:16:44 EDT To: argus2@ATHENA.MIT.EDU make sure you immediately cast to an unisgned char when reading XmNunitType and pass those values as ints between functions, this keeps the rt and gcc happy respectively. Failure to do former kills rt executables.  1,, Summary-line: 4-Aug rap@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23139; Fri, 4 Aug 89 21:30:38 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08203; Fri, 4 Aug 89 21:30:52 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA13272; Fri, 4 Aug 89 21:30:11 EDT Date: Fri, 4 Aug 89 21:30:11 EDT Message-Id: <8908050130.AA13272@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU *** EOOH *** From: Date: Fri, 4 Aug 89 21:30:11 EDT To: argus2@ATHENA.MIT.EDU ignore my previous message all. GETTING THE UNIT TYPE DOESN'T WORK AT ALL !!! as I wrote to you previously Toby. Thats the bug to report. __Rich.  1,, Summary-line: 4-Aug rap@ATHENA.MIT.EDU #alpop Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23150; Fri, 4 Aug 89 21:32:27 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08214; Fri, 4 Aug 89 21:32:41 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA13275; Fri, 4 Aug 89 21:32:01 EDT Date: Fri, 4 Aug 89 21:32:01 EDT Message-Id: <8908050132.AA13275@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: alpop *** EOOH *** From: Date: Fri, 4 Aug 89 21:32:01 EDT To: argus2@ATHENA.MIT.EDU Subject: alpop since getting the unit type don;t work I have choosen Xm100th_MILLIMETERS as the unit type. If your widgets use this alpop will hang correctly, if not, no big deal but the alpop popups will hang (i.e. pop up) away from where they are intended to, by how much I don't know but it shouldn't be much. --Rich  1,, Summary-line: 5-Aug rap@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24821; Sat, 5 Aug 89 02:15:54 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10853; Sat, 5 Aug 89 02:16:06 EDT Received: by E51-007-12.MIT.EDU (5.60/4.7) id AA13895; Sat, 5 Aug 89 02:15:23 EDT Date: Sat, 5 Aug 89 02:15:23 EDT Message-Id: <8908050615.AA13895@E51-007-12.MIT.EDU> To: argus2@ATHENA.MIT.EDU *** EOOH *** From: Date: Sat, 5 Aug 89 02:15:23 EDT To: argus2@ATHENA.MIT.EDU I edited assert.h so the rt can use hc2 which is now the default for the rt working directory. Somebody is going to have to check it out with the rest of the codfe in src but I feel there should be no problems, its a nice ANSI compiler for the rt!!! and works well with ruleeditor code. Toby, the predicate part of the ruleeditor is working functionally reasonably (but looking kinda ugly). The THEN part is up to you if you choose to accept that misson, otherwise I will gladly do it when I return. Somebody please get in contact with Dave Crickorian about the zephyr stuff, THIS IS IMPORTANT. For rt compiling please use my rt across the street. Since toby is most likely going to do ruleeditor stuff I'll 'give' it to you because the local drive is all set up for it. the directory /site/lens/src/rap/re/rt is the current ruleeditor. In AFS the directory is /afs/athena/mit/argus/src/rap/re/vax/0.7. I will move all working files to src from this dired. The rt is called e51-007-12 and the root passwrd is 'jupiter'. access_on. Don;t use the rt gdb, its bad, use dbx. Also, use hc2, not pcc. The rt is also configured with 27M swap so running saber is nice. I have it xlocked, if you wanna reboot just become su. The rt also has local copies of X motif argus libraries and include files for speed. See ya' all in 3 weeks!!!!!!!!!!! {:-)))))))) __Rich  1,, Summary-line: 8-Aug ian@ATHENA.MIT.EDU #quickly unmanaging Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02816; Tue, 8 Aug 89 18:17:40 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05280; Tue, 8 Aug 89 18:18:01 EDT Received: by E40-349-1.MIT.EDU (5.60/4.7) id AA26126; Tue, 8 Aug 89 18:17:16 EDT Date: Tue, 8 Aug 89 18:17:16 EDT Message-Id: <8908082217.AA26126@E40-349-1.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Subject: quickly unmanaging *** EOOH *** From: Date: Tue, 8 Aug 89 18:17:16 EDT To: motif-bugs@ATHENA.MIT.EDU Subject: quickly unmanaging OSF UEC Problem Report ================================= Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot GA Component (Module): Message Dialog OSF License Number: Client Hardware: VaxStation 2 Client Software: BSD 4.3, Athena 6.2, X11R3 Server Hardware: or SAME AS CLIENT Server Software: or SAME AS CLIENT Compiler: Problem Description ------------------- Severity Level: Severe -- represents a problem which resulted in software functionality Date of First Occurrence: 8/8/89 One Line Description: Widget hangs if managed and then quickly unmanaged. Full Description: Trying to find *some* way to get a timely message put up (still haven't succeeded), I found that my message box, which can be managed nicely if left alone until the user activates it, will hang if I try to put it up and then unmanage it quickly. Repeat By: ... XtManageChild(widget); /* modal dialog */ XtUnmanageChild(widget); ... program is hung up by widget that won't go away Proposed Solution:  1,, Summary-line: 9-Aug ilham@ATHENA.MIT.EDU #Palladium Staff Test Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11501; Wed, 9 Aug 89 14:05:25 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19522; Wed, 9 Aug 89 14:05:17 EDT Received: by GARFIELD.MIT.EDU (5.61/1.1) id AA06069; Wed, 9 Aug 89 14:04:38 -0400 Date: Wed, 9 Aug 89 14:04:38 -0400 Message-Id: <8908091804.AA06069@GARFIELD.MIT.EDU> From: Ilhamuddin Ahmed Sender: ilham@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Cc: geer@ATHENA.MIT.EDU, paul@ATHENA.MIT.EDU, ilham@ATHENA.MIT.EDU Subject: Palladium Staff Test Reply-To: ilham@ATHENA.MIT.EDU Us.Snail: 213 Bemis, 3 Ames St. Cambridge, MA 02139 (617)-225-6273 *** EOOH *** Date: Wed, 9 Aug 89 14:04:38 -0400 From: Ilhamuddin Ahmed Sender: ilham@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Cc: geer@ATHENA.MIT.EDU, paul@ATHENA.MIT.EDU, ilham@ATHENA.MIT.EDU Subject: Palladium Staff Test Reply-To: ilham@ATHENA.MIT.EDU Us.Snail: 213 Bemis, 3 Ames St. Cambridge, MA 02139 (617)-225-6273 **** THIS WILL ONLY WORK FROM 6.3B MACHINES **** "Calvin", the printer that is between the Watchmaker and Consultant area is now a palladium printer of the same name. You can print a file by issuing the following command : pdpr -Pcalvin name_of_file name_of_another_file You can query jobs of a printer by : pdpq -Pcalvin If the printer (or the server that the printer is connected to) is paused/disabled, pdpq will inform the user of it. And finally if you ever need to remove jobs you can use : pdrm -Pcalvin jobid For 'jobid' this can either be a local id or a global id as can be seen in the example below. Any bugs or problems thats you have should be sent to bugs@athena.mit.edu. Please specify the problem in as much detail as you can so that it will enable us to make fixes quicker. - Ilham =============================================================================== Examples : {/mit/ilham} <799> 1:22pm % pdpr -Pcalvin /etc/motd {/mit/ilham} <800> 1:23pm % pdpq -Pcalvin {/mit/ilham} <801> 1:23pm % pdpq -Pcalvin Service provider = ravs LocalId Global Id Owner Job Title JobState ================================================================================ 1 ravs-618686592 ilham /etc/motd Active 2 ravs-618686605 ilham /etc/named.local Pending Now to remove the second job (/etc/named.local) we can do either of the following : pdrm -Pcalvin 2 pdrm -Pcalvin ravs-618686605  1,, Summary-line: 9-Aug amgreene@ATHENA.MIT.EDU #Questions about Palladium Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11846; Wed, 9 Aug 89 14:22:14 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19777; Wed, 9 Aug 89 14:20:11 EDT Received: by GEVALT.MIT.EDU (5.61/4.7) id AA14519; Wed, 9 Aug 89 14:19:30 -0400 Date: Wed, 9 Aug 89 14:19:30 -0400 Message-Id: <8908091819.AA14519@GEVALT.MIT.EDU> To: ilham@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU In-Reply-To: Ilham's announcement of Palladium Subject: Questions about Palladium *** EOOH *** From: Date: Wed, 9 Aug 89 14:19:30 -0400 To: ilham@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU In-Reply-To: Ilham's announcement of Palladium Subject: Questions about Palladium Being interested in the options that pdpr will give us (most interested in continuing to use -h), I came across these questions based on the man page: > -b banner-type > Specifies the type of banner to use: "full" for a com- > plete banner containing information about the job or > "breif" for a banner containing only the job name and > user name. Will "brief" save the extra piece of paper? And does pdpr want "breif" or is that a manpage typo? > -d doc-type > Specifies the type of document being printed: "Ascii" > or "Postscript", the default is Ascii. Does Palladium do any magic-number tests, or will we have to explicitly declare our PostScript files? If the latter, I suggest that the default is wrong, since an Ascii file interpreted as PS generates 0 or 1 pages of output, while a PS file printed as Ascii will generate gobs (which is, I believe, the technical term :-). > -e event-list > The user will be notified when the events listed occur. > If more than one event is listed they should be sur- > rounded by "'s and separated by commas. What events are these? They weren't enumerated on the man page, unless I missed them... It may be that these are silly questions; I'm not in E40 right now so I can't test to find the answers, but they're things that raise exception flags in my mind.... - Andrew  1,, Summary-line: 9-Aug ilham@ATHENA.MIT.EDU #Questions about Palladium Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13106; Wed, 9 Aug 89 15:51:25 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21752; Wed, 9 Aug 89 15:49:21 EDT Received: by GARFIELD.MIT.EDU (5.61/1.1) id AA06250; Wed, 9 Aug 89 15:48:41 -0400 Date: Wed, 9 Aug 89 15:48:41 -0400 Message-Id: <8908091948.AA06250@GARFIELD.MIT.EDU> From: Ilhamuddin Ahmed Sender: ilham@ATHENA.MIT.EDU To: amgreene@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU In-Reply-To: 's message of Wed, 9 Aug 89 14:19:30 -0400 <8908091819.AA14519@GEVALT.MIT.EDU> Subject: Questions about Palladium Reply-To: ilham@ATHENA.MIT.EDU Us.Snail: 213 Bemis, 3 Ames St. Cambridge, MA 02139 (617)-225-6273 *** EOOH *** Date: Wed, 9 Aug 89 15:48:41 -0400 From: Ilhamuddin Ahmed Sender: ilham@ATHENA.MIT.EDU To: amgreene@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU In-Reply-To: 's message of Wed, 9 Aug 89 14:19:30 -0400 <8908091819.AA14519@GEVALT.MIT.EDU> Subject: Questions about Palladium Reply-To: ilham@ATHENA.MIT.EDU Us.Snail: 213 Bemis, 3 Ames St. Cambridge, MA 02139 (617)-225-6273 Before I start, I should be noted that the man pages are seriously out and date and has lots of typos ... new ones are in the middle of being written. Rhu> Being interested in the options that pdpr will give us (most interested Rhu> in continuing to use -h), I came across these questions based on the Rhu> man page: The -h option of lpr can be emulated with the -B option of pdpr which should supress the banner page. Rhu> Will "brief" save the extra piece of paper? And does pdpr want Rhu> "breif" or is that a manpage typo? It should actually be "Brief" and "Full" (they are case sensitive) where Brief is currently the default. [I know the problem with specifying a banner which does not exist.] The only difference between the two is that "Full" shows the Athena owl whereas Brief does not. Rhu> Does Palladium do any magic-number tests, or will we have to explicitly Rhu> declare our PostScript files? If the latter, I suggest that the default Rhu> is wrong, since an Ascii file interpreted as PS generates 0 or 1 pages of Rhu> output, while a PS file printed as Ascii will generate gobs (which is, I Rhu> believe, the technical term :-). It does do magic-number tests so queuing a postscript file / ascii file / standard input will do the right thing. Rhu> What events are these? They weren't enumerated on the man page, unless Rhu> I missed them... Event are the notifications that one can get when the state of a job changes. Currently the events are : jobstart /* on server reciept */ jobend /* when spvr is done */ printstart /* when spvr starts printing */ jobabort /* when spvr chokes on file */ jobcancel /* when a job is killed, either by a user or administrator */ These notifications default to zephyr for Athena but mail notification can also be specified. Rhu> It may be that these are silly questions; I'm not in E40 right now so I Rhu> can't test to find the answers, but they're things that raise exception Rhu> flags in my mind.... No problem at all .... of course if you find any bug send them to bugs@athena.mit.edu and I will look at them as soon as I can. - Ilham  1,, Summary-line: 9-Aug bjaspan@ATHENA.MIT.EDU #Xt/Motif server testing Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA14323; Wed, 9 Aug 89 17:09:07 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23244; Wed, 9 Aug 89 17:09:14 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA00871; Wed, 9 Aug 89 17:08:29 -0400 Date: Wed, 9 Aug 89 17:08:29 -0400 Message-Id: <8908092108.AA00871@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU, motifdev@ATHENA.MIT.EDU Subject: Xt/Motif server testing *** EOOH *** Date: Wed, 9 Aug 89 17:08:29 -0400 From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: motif@ATHENA.MIT.EDU, motifdev@ATHENA.MIT.EDU Subject: Xt/Motif server testing I will soon be ready to test full fledged applications with my Xt server. Here is a list of the Xt, Xm, and Mrm function calls currently supported (in no particular order.) If your application doesn't use any Xt, Xm, or Mrm functions calls not on this list, please let me know; your program will become a guinea pig. If there *ARE* functions not on this list that you need, please let me know. -- Barr3y XtInitialize() XtSetValues() XtParent() XtDisplay() XtScreen() XtWindow() XtAppCreateShell() XtCreateWidget() XtNameToWidget() XtManageChild() XtUnmanageChild() XtMapWidget() XtUnmapWidget() XtSetMappedWhenManaged() XtAddCallback() XtRealizeWidget() XtMainLoop() XtSetArg() XtDestroyWidget() XtIsRealized() XtMalloc() XtRealloc() XtCalloc() XtFree() XmCreate*() XmList*() XmTextGetString() XmTextSetString() XmTextGetSelection() XmStringCreate() XmStringCreateLtoR() XmStringLength() MrmOpenHierarchy() MrmRegisterNames() MrmFetchWidget() (Callbacks created in the uil file work) Restrictions ------------ The XrmOptionsDescRec field of XtInitialize() doesn't work. I have no idea what will happen if it is set to anything but NULL. The XEvent * field of a callback struct cannot be accessed. The list widget's callback returns an XmString or XmString *, but these cannot be accessed.  1,, Summary-line: 9-Aug tinoue@ATHENA.MIT.EDU #scrolled_text Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15946; Wed, 9 Aug 89 19:50:16 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA25701; Wed, 9 Aug 89 19:50:44 EDT Received: by E40-334-1.MIT.EDU (5.61/4.7) id AA11400; Wed, 9 Aug 89 19:50:00 -0400 Message-Id: <8908092350.AA11400@E40-334-1.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Cc: tinoue@ATHENA.MIT.EDU Subject: scrolled_text Date: Wed, 09 Aug 89 19:49:55 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Cc: tinoue@ATHENA.MIT.EDU Subject: scrolled_text Date: Wed, 09 Aug 89 19:49:55 EDT OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: T.I. Organization: MIT Email Address: tinoue Phone: x3-4277 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot GA Component (Module): Scrolled Text OSF License Number: Client Hardware: Vax Station 2 Client Software: BSD 4.3 Athena 6.3a, X11R3 Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: Problem Description ------------------- Severity Level: Severe Date of First Occurrence: 8/9/89 One Line Description: Attachment specifications do not work for scrolled text widgets in a form widget. Full Description: XmATTACH_FORM and XmATTACH_WIDGET specified in a scrolled_text are ignored. Scrolled_text widgets are also ignored when specified as targets of XmATTACH_WIDGET Repeat By: Here is a simple uil code: module scrolled_text_bug names = case_sensitive include file 'XmAppl.uil'; object main : form { controls { label topTitle; scrolled_text sw_text; label bottomTitle; }; }; object topTitle : label { arguments { top_attachment = XmATTACH_FORM; }; }; object sw_text : scrolled_text { arguments { top_attachment = XmATTACH_WIDGET; top_widget = label topTitle; edit_mode = XmMULTI_LINE_EDIT; columns = 35; rows = 20; text_value = "My name is T.I."; }; }; object bottomTitle : label{ arguments { top_attachment = XmATTACH_WIDGET; top_widget = scrolled_text sw_text; }; }; end module; Proposed Solution: A scrolled_text widget consists of a scrolled_window widget and a text widget within the scrolled_window. Actually, the name of scrolled_text widget is the name of the text widget inside the scrolled_window. When we want to do attachment manipulations under form widgets, we have to specify the name of 'scrolled_window' widgets in place of that of 'text' widgets, I guess. When we write in C code, we can do that using XtParent('textW-name') or writing the name of scrolled_window as 'textW-name'SW, but I could find no way to do in UIL code. I had to separate the scrolled_text widget into a scrolled_window widget and a text widget. In terms of 'Attachment', the scrolled_text is an in-convenient widget ?!!! :~(  1,, Summary-line: 10-Aug orcutt@ATHENA.MIT.EDU #Printing Policy Statement for your Review Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25747; Thu, 10 Aug 89 18:04:22 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11921; Thu, 10 Aug 89 18:03:38 EDT Received: by E40-391A-2.MIT.EDU (5.61/4.7) id AA00372; Thu, 10 Aug 89 18:02:54 -0400 Message-Id: <8908102202.AA00372@E40-391A-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Printing Policy Statement for your Review Date: Thu, 10 Aug 89 18:02:50 EDT From: Ronald L. Orcutt *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: Printing Policy Statement for your Review Date: Thu, 10 Aug 89 18:02:50 EDT From: Ronald L. Orcutt The following policy statement on printing was reviewed and approved by the Directors this afternoon. This will be sent to the Tech, and further publicized by User Services. I would like to pass this by the staff for any further suggestions. Please send any comments directly to me, and please treat this document as an Athena-confidential draft for now. ===============================DRAFT========================================== Memo to: The Project Athena User Community From: Ronald L. Orcutt, Executive Director Date: August 10, 1989 The provision of printing and the maintenance of conveniently-placed printers continue to represent a significant cost to Project Athena. This service is important to the community, and because of that, improvements in printing service have received priority attention over the past year. With the approval of Project Athena's Executive Committee, Project Athena is adopting a new cost containment and recovery policy for printing. This memorandum begins a process of informing the community of this change. Beginning with the Fall, 1989 academic term, each Athena user will have a quota of 500 printed pages per term. There will be no fee for users whose printing usage falls under this allotment. Allotments beyond the base quota will be available, but for a fee. From analysis of last year's usage, the base allotment should suffice for the majority of users. Because of implementation requirements, fees will be waived until after the Fall, 1989 term. Newly-developed and installed software will enable us to track and report on print usage in an effective manner, and has made this policy change possible. It will also allow us to accommodate exceptions to the norm, e.g., departmental printers dedicated to specific users or fees waived in situations where the costs of printing are covered in some other manner. During the Fall term, each Athena print server will be converted to use the new software, and as this conversion is completed, this new software will be subjected to widespread user testing prior to any funds changing hands. The fee structure and mechanism for fee collection will be detailed in subsequent memoranda.  1,, Summary-line: 10-Aug jbs@ATHENA.MIT.EDU #my check? Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA28928; Thu, 10 Aug 89 23:27:39 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16210; Thu, 10 Aug 89 23:28:10 EDT Received: by M11-111-2.MIT.EDU (5.60/4.7) id AA02809; Thu, 10 Aug 89 23:27:07 EDT Date: Thu, 10 Aug 89 23:27:07 EDT Message-Id: <8908110327.AA02809@M11-111-2.MIT.EDU> To: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Fri, 14 Jul 89 22:47:22 EDT <8907150247.AA22055@E51-007-12.MIT.EDU> Subject: my check? *** EOOH *** From: Date: Thu, 10 Aug 89 23:27:07 EDT To: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Fri, 14 Jul 89 22:47:22 EDT <8907150247.AA22055@E51-007-12.MIT.EDU> Subject: my check? Sorry about the check delay (as you can guess, I'm catching up on my mail). Why didn't you mention it when we talked on the phone? I lost your address in my move, but I've just put the check in an envelope. I'll try to remember to mail it on the way to work tomorrow. Jeffrey  1,, Summary-line: 11-Aug bgardner@ATHENA.MIT.EDU #new runrules Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09187; Fri, 11 Aug 89 18:50:29 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01027; Fri, 11 Aug 89 18:51:01 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA02583; Fri, 11 Aug 89 18:50:10 -0400 Date: Fri, 11 Aug 89 18:50:10 -0400 Message-Id: <8908112250.AA02583@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: new runrules *** EOOH *** From: Date: Fri, 11 Aug 89 18:50:10 -0400 To: argus2@ATHENA.MIT.EDU Subject: new runrules I've just hard in the path for rcvstore as /usr/new/mh/lib/rcvstore in the motif version of r. This isn't the nicest solution (but the only nicer one would be in they moved rcvstore into the /usr/new/mh/bin directory were it belongs). I also recompiled runrules. (It was doing some weird stuff, which I suspect was some thing unrelated that was outdated and sitting in the libargus.a file...but I'm not positive.) Any Anyway, the good news is...It seems to be working fine. So, I've copied the new working version of runrules into the 0.6 argus bin directory (vaxbin). Wendy, this should solve your problem. (At least with runrules). You should probably test it out on a test folder, first. (I actually tested it already on my main ruleset and +inbox, so I'm reasonably certain it'll work, but it doesn't hurt to check first just in case your workstation does something unexpected.) Please message me if you have any problems. (Was there anything else that was (and still is ) fakey ? flakey ?) -- Brian PS: Please forgive the typoes, 6.3B seems to have a bug, my backspace key doesn't work.  1,, Summary-line: 11-Aug djf@ATHENA.MIT.EDU #modal dialogs aren't modal under uwm Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09340; Fri, 11 Aug 89 19:02:08 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01182; Fri, 11 Aug 89 19:02:37 EDT Received: by LEO.MIT.EDU (5.61/4.7) id AA01873; Fri, 11 Aug 89 19:01:51 -0400 Date: Fri, 11 Aug 89 19:01:51 -0400 Message-Id: <8908112301.AA01873@LEO.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU, uec-defect@osf.osf.org Subject: modal dialogs aren't modal under uwm *** EOOH *** From: Date: Fri, 11 Aug 89 19:01:51 -0400 To: motif-bugs@ATHENA.MIT.EDU, uec-defect@osf.osf.org Subject: modal dialogs aren't modal under uwm OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: David Flanagan Organization: Project Athena Email Address: djf@athena.mit.edu Phone: 617 253-0169 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot GA Component (Module): DialogS.c OSF License Number: Client Hardware: N.A. Client Software: running uwm Server Hardware: Server Software: Compiler: Problem Description ------------------- Severity Level: Critical -- represents a problem which resulted in software malfunction or a feature failure and has no work-around. One Line Description: Modal dialogs aren't modal under uwm. Full Description: The XmDialogShell widget makes itself modal in a way that relies on the presence of mwm. It does not use the XtAddGrab() function supported by the intrinsics. The relevant code from ChangeManaged() in Xm/DialogS.c is: /* * We assume that Mwm is present. If it isn't then we should * set some kind of grab mode based on BBoard's dialogStyle. */ shell->dialog.grab_kind = XtGrabNone; The comment indicates that the programmer knew what to do; it just hasn't been done. Proposed Solution: Implement the behaivor described in the comment.  1,, Summary-line: 11-Aug djf@ATHENA.MIT.EDU #[Hyun-Ju Vega: MotifUtilities] Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09503; Fri, 11 Aug 89 19:12:30 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01318; Fri, 11 Aug 89 19:12:55 EDT Received: by LEO.MIT.EDU (5.61/4.7) id AA01893; Fri, 11 Aug 89 19:12:04 -0400 Date: Fri, 11 Aug 89 19:12:04 -0400 Message-Id: <8908112312.AA01893@LEO.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: [Hyun-Ju Vega: MotifUtilities] *** EOOH *** From: Date: Fri, 11 Aug 89 19:12:04 -0400 To: argus2@ATHENA.MIT.EDU Subject: [Hyun-Ju Vega: MotifUtilities] Those of you working on Motif might find this library of utility routines useful. People have been using it this week with a minimum of problems. Enjoy. -- djf ------- Forwarded Message From: To: motifdev@ATHENA.MIT.EDU Subject: MotifUtilities Date: Mon, 07 Aug 89 16:52:53 EDT **************************************************************************** Here's a brief description of the functions available in MotifUtilities for those of you who want to start using the library functions. I'll write up a more complete documentation later (more things will be added on). To link against MotifUtilities library, please add "-lMu" to your list of libraries in your makefile. For now, please send any bug reports to "hvega". (Note: Create callback in uil doesn't seem to be working on vax.) **************************************************************************** **************************************************************************** void MuInitialize(toplevel) Everyone uses MotifUtilities in their c files must call MuInitialize(toplevel) after you XtInitialize your toplevel. You pass your toplevel widget. e.g. Widget toplevel; toplevel = XtInitialize( "test", "testclass", NULL, 0, &argc, argv); MuInitialize(toplevel); ************************************************************************** void MuRegisterNames() If you are using any of the MotifUtilities functions which can be called from uil, you must call this function. It will automatically register all MotifUtilities Callback functions in uil so that you won't have to add them on to your MRMRegisterArg. e.g. if (MrmOpenHierarchy (1, vec, NULL, &s_MrmHierarchy) != MrmSUCCESS) { printf ("cant' open hierarchy. . . \n"); } MuRegisterNames(); The functions which can be called directly from uil are: void MuSetEmacsBindings(), MuSetSingleLineEmacsBindings(), MuSetStandardCursor(), MuSetCursor(integer), MuSetWaitCursor() . *************************************************************************** void MuSetEmacsBindings(text_widget) and void MuSetSingleLineEmacsBindings(text_widget) These functions add emacs bindings to your text widgets translation table so that you can back space, d, d, etc. From your c file you pass the text_widget you want the emacs bindings for. MuSetEmacsBindings takes multi-line text widgets, and MuSetSingleLineEmacsBindings take single-line text widgets. You will get an error message if the widget you pass is NULL or not a text widget. ------------------------------------------------------------------------ void MuSetEmacsBindings() and void MuSetSingleLineEmacsBindings() These functions are to be used in the uil file with the create callbacks of your text widgets. (However, the create callback doesn't seem to be working on the vax -- worked fine for me on the rt though.) e.g. object textbox : scrolled_text { arguments { editable = true; edit_mode = XmMULTI_LINE_EDIT; word_wrap = true; }; callbacks { create = procedure MuSetEmacsBindingsCallback(); }; }; *************************************************************************** void MuSetStandardCursor(widget), void MuSetWaitCursor(widget), void MuSetCursor(widget, cursorshape) Widget widget; unsigned int cursorshape; These functions set the cursor shape in your interface window. (Standard cursor is an arrow, and the Wait cursor is a watch.) You can pass any widget to these functions, and they will set the cursor shape in the shell ancestor (parent, grandparent, great-grandparent...) of the widget passed. MuSetCursor sets any cursor shape (from cursor font) passed. (If you do "xfd cursor", you'll get a window with all the cursor shapes available in font cursor. Click on a cursor shape with your middle button, and you'll get the number description of the cursor shape.) ------------------------------------------------------------------------ void MuSetStandardCursor(), void MuSetWaitCursor(), void MuSetCursor(tag) Note: Djf recommends calling these functions from uil because he feels that the cursor is really part of the interface and as such belongs in the uil file rather than the C file. ** These functions are to be used in the uil file with the activate callbacks. MuSetCursor takes an integer tag which is the number description of the cursor shape from the cursor font. e.g. object button : push_button { arguments { label_label = compound_string('Button'); }; callbacks { activate = procedures { MuSetWaitCursor(); Do_some_procedure(); MuSetStandardCursor(); }; }; }; **************************************************************************** void MuError(string) char *string; void MuWarning(string) char *string; void MuHelp(string) char *string; These functions put up an error dialog box, a warning dialog box, and a help dialog box when passed a string. The wait cursor will be put up automatically, and the dialog box will have a standard cursor. (If this isn't the way it's behaving right now, it will soon be fixed.) These dialog boxes are supposed to be modal. ************************************************************************** void MuSetTextTraversal(widgets, num) Widget widgets[num]; int num; This function enables traversal among a group of text widgets using the up arrow, down arrow, and the return key. This is useful for text widgets used for field input. This should not be used with multiple_line text widgets for now since the return key will not behave properly. You pass an array of widgets and the number of widgets in the array to the function. The function will be modified later to allow independent traversal in two separate groups of text widgets. Also, for now, the text widgets must be descendents of the toplevel shell (i.e. can't be in dialog shells). **************************************************************************** About MuGetBoolean, MuGetFile, and MuGetString ... * This is a general description of MuGetBoolean, MuGetFile, and * MuGetString. These popup a modal dialog box for communication with * the user. They provide a synchronous interface to the programmer. * That is, like gets() or scanf() they return the desired value * directly to the programmer, without any intervening callbacks. * This is accomplished by invoking a recursive copy of XtMainLoop * inside of the each utility routine, and using longjmp() from within * the ok and cancel callbacks to abort from that recursive copy. * This is witchcraft, but provides powerful interface tools to the * programmer. * For additional convenience, these functions never take compound * strings as arguments. All strings are passed as char *. ------------------------------------------------------------------------ Boolean MuGetBoolean(prompt, yeslabel, nolabel, helptext, defaultbutton) char *prompt, *yeslabel, *nolabel; char *helptext; Boolean defaultbutton; * Uses an XmMessageDialog widget to prompt the user for an answer to * a yes-or-no type question. * Inputs: * prompt The question to present the user. * yeslabel The text to appear on the "True" button. * nolabel The text to appear on the "False" button. * helptext The text to appear when the "Help" button is clicked. * If NULL is specified, the help button will not appear. * defaultbutton A Boolean indicating which button should be the default * Returns: * a Boolean indicating which button was pressed. * ----------------------------------------------------------------------- Boolean MuGetString(prompt, buffer, bufsize, helptext) char *prompt; char *buffer; int bufsize; char *helptext; * MuGetString * Uses a PromptDialog convenience widget to prompt the user to input * a string. The string is returned in a passed buffer, and the * function returns a Boolean indicating whether the "Ok" or the * "Cancel" button was pressed. * Inputs: * prompt The string to prompt the user with. * buffer A pointer to a buffer to return the string in. * The contents of the buffer will be displayed as * the default string. * bufsize The size in bytes of the buffer. * helptext The text to display if the help button is * clicked. If NULL, no Help button will be * displayed. * Outputs: * buffer Contains the NULL-terminated string the user * selected. * Returns: * a Boolean indicating whether the user clicked the "Ok" * button (True) or the "Cancel" button (False). If False is * returned, then the contents of buffer should be ignored. * ------------------------------------------------------------------------ Boolean MuGetFile(buffer, bufsize, dirmask, dirmasksize, helptext) char *buffer; int bufsize, dirmasksize; char *dirmask; char *helptext; * MuGetFile (more properly called MuGetFileName -- will be fixed) * Uses a FileSelectionDialog widget to prompt the user to select a file. * The string is returned in a passed buffer, and the * function returns a Boolean indicating whether the "Ok" or the * "Cancel" button was pressed. * Inputs: * buffer A pointer to a buffer to return the file name in. * * bufsize The size in bytes of the buffer. * dirmask A pointer to a buffer to return the value of the * directory mask. The contents of dirmask will * be used as the default. * * dirmasksize The size in bytes of the dirmask. * helptext The text to display if the help button is * clicked. If NULL, no Help button will be * displayed. * Outputs: * buffer Contains the NULL-terminated file name the user * selected. * dirmask Contains the NULL-terminated directory mask used. * Returns: * a Boolean indicating whether the user clicked the "Ok" * button (True) or the "Cancel" button (False). If False is * returned, then the contents of buffer should be ignored. * Note: FileSelectionDialog seems to be a bit flaky right now. ***************************************************************************** ------- End Forwarded Message  1,, Summary-line: 14-Aug hvega@ATHENA.MIT.EDU #MotifUtilities Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25904; Mon, 14 Aug 89 16:17:40 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15912; Mon, 14 Aug 89 16:17:06 EDT Received: by E51-007-4.MIT.EDU (5.60/4.7) id AA02071; Mon, 14 Aug 89 16:17:08 EDT Message-Id: <8908142017.AA02071@E51-007-4.MIT.EDU> To: motif@ATHENA.MIT.EDU Subject: MotifUtilities Date: Mon, 14 Aug 89 16:17:04 EDT *** EOOH *** From: To: motif@ATHENA.MIT.EDU Subject: MotifUtilities Date: Mon, 14 Aug 89 16:17:04 EDT **************************************************************************** Here's a brief description of the functions available in MotifUtilities. (More functions have been added on.) To link against MotifUtilities library, please add "-lMu" to your list of libraries in your makefile. For now, please send any bug reports to "hvega". **************************************************************************** **************************************************************************** void MuInitialize(toplevel) Everyone uses MotifUtilities in their c files must call MuInitialize(toplevel) after you XtInitialize your toplevel. You pass your toplevel widget. e.g. Widget toplevel; toplevel = XtInitialize( "test", "testclass", NULL, 0, &argc, argv); MuInitialize(toplevel); ************************************************************************** void MuRegisterNames() If you are using any of the MotifUtilities functions which can be called from uil, you must call this function. It will automatically register all MotifUtilities Callback functions in uil so that you won't have to add them on to your MRMRegisterArg. Note: MuRegisterNames() should go before the "MrmFetchWidget" and after "MrmOpenHierarchy". e.g. if (MrmOpenHierarchy (1, vec, NULL, &s_MrmHierarchy) != MrmSUCCESS) { printf ("cant' open hierarchy. . . \n"); } MuRegisterNames(); The functions which can be called directly from uil are: void MuSetEmacsBindings(), MuSetSingleLineEmacsBindings(), MuSetStandardCursor(), MuSetCursor(integer), MuSetWaitCursor() . *************************************************************************** void MuSetEmacsBindings(text_widget) and void MuSetSingleLineEmacsBindings(text_widget) These functions add emacs bindings to your text widgets translation table so that you can back space, d, d, etc. From your c file you pass the text_widget you want the emacs bindings for. MuSetEmacsBindings takes multi-line text widgets, and MuSetSingleLineEmacsBindings take single-line text widgets. You will get an error message if the widget you pass is NULL or not a text widget. ------------------------------------------------------------------------ void MuSetEmacsBindings() and void MuSetSingleLineEmacsBindings() These functions are to be used in the uil file with the create callbacks of your text widgets. (However, the create callback doesn't seem to be working on the vax -- worked fine for me on the rt though.) e.g. object textbox : scrolled_text { arguments { editable = true; edit_mode = XmMULTI_LINE_EDIT; word_wrap = true; }; callbacks { create = procedure MuSetEmacsBindings(); }; }; *************************************************************************** void MuSetStandardCursor(widget), void MuSetWaitCursor(widget), void MuSetCursor(widget, cursorshape) Widget widget; unsigned int cursorshape; These functions set the cursor shape in your interface window. (Standard cursor is an arrow, and the Wait cursor is a watch.) You can pass any widget to these functions, and they will set the cursor shape in the shell ancestor (parent, grandparent, great-grandparent...) of the widget passed. MuSetCursor sets any cursor shape (from cursor font) passed. (If you do "xfd cursor", you'll get a window with all the cursor shapes available in font cursor. Click on a cursor shape with your middle button, and you'll get the number description of the cursor shape.) ------------------------------------------------------------------------ void MuSetStandardCursor(), void MuSetWaitCursor(), void MuSetCursor(tag) Note: Djf recommends calling these functions from uil because he feels that the cursor is really part of the interface and as such belongs in the uil file rather than the C file. ** These functions are to be used in the uil file with the activate callbacks. MuSetCursor takes an integer tag which is the number description of the cursor shape from the cursor font. e.g. object button : push_button { arguments { label_label = compound_string('Button'); }; callbacks { activate = procedures { MuSetWaitCursor(); Do_some_procedure(); MuSetStandardCursor(); }; }; }; **************************************************************************** void MuError(string) char *string; void MuWarning(string) char *string; /* MuHelp(string) can also be called from uil. */ void MuHelp(string) char *string; These functions put up an error dialog box and a warning dialog box when passed a string (can include " \n " in the string to get a new line). (The dialog boxes will have a standard cursor.) These dialog boxes are supposed to be modal. *************************************************************************** You can call MuHelp("help string") from uil as well as from C files. void MuHelp(string) char *string; MuHelp puts up a help message box with your choice of help string. These are "modeless" dialog boxes, and you can have as many as 25 different help dialog boxes managed at once. (If you try to manage more than 25 at once, you will get an error message.) Don't forget to call MuRegisterNames() before MrmFetchWidget(...) if you call MotifUtilities functions from uil. ************************************************************************* void MuSetTextTraversal(widgets, number, subtree) WidgetList widgets; int number; Widget subtree; widgets: array of text widgets number: number of text widgets in the array subtree: subtree of the hierarchy for which the keyboard focus is to be set. (e.g. It'll probably be "toplevel".) This function enables traversal among a group of text widgets using the up arrow, down arrow, and the return key. This is useful for text widgets used for field input. The function checks to see if the text widgets passed are single-line or multi-line text widgets. The Return key binding is not changed for multi-line text widgets (this is for those of you who have a scrolled, multi-line text widget, and you want the up and down arrow keys to be "traversal keys", while the Return key still behaves like a normal return key). The function also checks for sensitivity. Therefore, if a text field is not "sensitive", it will be skipped during traversal. ** You can have more than one set of text widgets for traversal. i.e. If you call MuSetTextTraversal(widgets1, 3, toplevel) and MuSetTextTraversal(widgets2, 4, toplevel), traversal among the text widgets in widgets1 will be set independent of the text widgets in widgets2. ** Send bug reports to "hvega" for now. ( Dennis (dpmcnagg) wrote MuSetTextTraversal if you have specific questions about the code. ) **************************************************************************** About MuGetBoolean, MuGetFile, and MuGetString ... * This is a general description of MuGetBoolean, MuGetFile, and * MuGetString. These popup a modal dialog box for communication with * the user. They provide a synchronous interface to the programmer. * That is, like gets() or scanf() they return the desired value * directly to the programmer, without any intervening callbacks. * This is accomplished by invoking a recursive copy of XtMainLoop * inside of the each utility routine, and using longjmp() from within * the ok and cancel callbacks to abort from that recursive copy. * This is witchcraft, but provides powerful interface tools to the * programmer. * For additional convenience, these functions never take compound * strings as arguments. All strings are passed as char *. ------------------------------------------------------------------------ Boolean MuGetBoolean(prompt, yeslabel, nolabel, helptext, defaultbutton) char *prompt, *yeslabel, *nolabel; char *helptext; Boolean defaultbutton; * Uses an XmMessageDialog widget to prompt the user for an answer to * a yes-or-no type question. * Inputs: * prompt The question to present the user. * yeslabel The text to appear on the "True" button. * nolabel The text to appear on the "False" button. * helptext The text to appear when the "Help" button is clicked. * If NULL is specified, the help button will not appear. * defaultbutton A Boolean indicating which button should be the default * Returns: * a Boolean indicating which button was pressed. * ----------------------------------------------------------------------- Boolean MuGetString(prompt, buffer, bufsize, helptext) char *prompt; char *buffer; int bufsize; char *helptext; * MuGetString * Uses a PromptDialog convenience widget to prompt the user to input * a string. The string is returned in a passed buffer, and the * function returns a Boolean indicating whether the "Ok" or the * "Cancel" button was pressed. * Inputs: * prompt The string to prompt the user with. * buffer A pointer to a buffer to return the string in. * The contents of the buffer will be displayed as * the default string. * bufsize The size in bytes of the buffer. * This will determine the maximum length of the * text string, which will be bufsize - 1. * helptext The text to display if the help button is * clicked. If NULL, no Help button will be * displayed. * Outputs: * buffer Contains the NULL-terminated string the user * selected. * Returns: * a Boolean indicating whether the user clicked the "Ok" * button (True) or the "Cancel" button (False). If False is * returned, then the contents of buffer should be ignored. * ------------------------------------------------------------------------ Boolean MuGetFile(buffer, bufsize, dirmask, dirmasksize, helptext) char *buffer; int bufsize, dirmasksize; char *dirmask; char *helptext; * MuGetFile (more properly called MuGetFileName -- will be fixed) * Uses a FileSelectionDialog widget to prompt the user to select a file. * The string is returned in a passed buffer, and the * function returns a Boolean indicating whether the "Ok" or the * "Cancel" button was pressed. * Inputs: * buffer A pointer to a buffer to return the file name in. * (e.g. in your c file, * declare buffer to be something like .. * char buffer[50]; ) * * bufsize The size in bytes of the buffer. * This will determine the maximum length of the * text string -- the maximum will be bufsize - 1. * * dirmask A pointer to a buffer to return the value of the * directory mask. The contents of dirmask will * be used as the default. * * dirmasksize The size in bytes of the dirmask. * This will determine the maximum length of the * text string for the dirmask. * helptext The text to display if the help button is * clicked. If NULL, no Help button will be * displayed. * Outputs: * buffer Contains the NULL-terminated file name the user * selected. * dirmask Contains the NULL-terminated directory mask used. * Returns: * a Boolean indicating whether the user clicked the "Ok" * button (True) or the "Cancel" button (False). If False is * returned, then the contents of buffer should be ignored. * Note: The default value of dirmask in the FileSelectionDialog resources is " * ". FileSelectionDialog believes that this indicates the current directory you are in. (i.e. If you're in /mit/motifdev, it will display all the files in /mit/motifdev .) Changing the dirmask to be "*.c" or something like that will NOT do what you expect it to do, which is to display all the c files in the current directory. However, changing the dirmask to be "/mit/motifdev/projects" will make it display all the files in /mit/motifdev/projects . ***************************************************************************** void MuRegisterWidget(string) /* called from uil and Widget MuGetWidget(string) /* called from C char *string; These two functions were written so that you can get a widget id without using XtNameToWidget() and without having to write a procedure in your c file to take care of the create callbacks from uil. You call MuRegisterWidget from uil, passing it a string (any name you want to call it) which identifies the widget you want to know the widget id of in C. e.g. object textbox1 : text { arguments { top_attachment = XmATTACH_FORM; right_attachment = XmATTACH_FORM; left_attachment = XmATTACH_FORM; }; callbacks { create = procedure MuRegisterWidget("box1"); }; }; Then, in C you can get the widget id of the widget by calling MuGetWidget, passing it the same string. e.g. Widget w; w = MuGetWidget("box1"); ****************************************************************************  1,, Summary-line: 14-Aug bjaspan@ATHENA.MIT.EDU #MotifUtilities Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA26640; Mon, 14 Aug 89 17:01:37 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16849; Mon, 14 Aug 89 17:01:06 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA08729; Mon, 14 Aug 89 17:01:10 -0400 Date: Mon, 14 Aug 89 17:01:10 -0400 Message-Id: <8908142101.AA08729@ANATHEMA.MIT.EDU> From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: hvega@ATHENA.MIT.EDU Cc: motif@ATHENA.MIT.EDU In-Reply-To: 's message of Mon, 14 Aug 89 16:17:04 EDT <8908142017.AA02071@E51-007-4.MIT.EDU> Subject: MotifUtilities *** EOOH *** Date: Mon, 14 Aug 89 17:01:10 -0400 From: Barr3y Jaspan Sender: bjaspan@ATHENA.MIT.EDU To: hvega@ATHENA.MIT.EDU Cc: motif@ATHENA.MIT.EDU In-Reply-To: 's message of Mon, 14 Aug 89 16:17:04 EDT <8908142017.AA02071@E51-007-4.MIT.EDU> Subject: MotifUtilities I have used the MuGetString function and in general really like it. I have a couple requests, however. There should be another parameter, an integer, that determines how the particular invokation of MuGetString works. Specifically, I want to be able to control where the dialog box pops up and whether a default string is displayed. The options I would like for popup control are: o Popup in the top (or bottom, left, right, or center) of parent o Popup directly under the mouse (pointer) o Popup at the same (x,y) coordinate as the PREVIOUS MuGetString() o Popup under window manager placement control (or, presumably, under a user's .Xresources control.) I can think of good uses for all these options. An easy way to implement this would be as a series of constants OR'ed together. ie: MU_GS_POPUP_CENTER || MU_GS_SHOW_DEFAULT would pop up the dialog box centered in the parent and display the contents of the buffer as the default string. MU_GS_POPUP_POINTER || MU_GS_NOSHOW_DEFAULT would pop up the dialog box under the pointer without displaying the contents of the buffer. Also, MU_GS_POPUP_PREVIOUS wouldn't be hard to do; just maintain two static integers (like prev_x and prev_y) that contain the previous x and y coords, and set these each time you do a MuGetString. Now that I think about it, all this (except the show_default stuff) applies to all the MuGet* functions, not just MuGetString. Barr3y  1,, Summary-line: 15-Aug drr%saber@harvard.harvard #Compiler Postions Open Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06371; Tue, 15 Aug 89 14:11:58 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA00559; Tue, 15 Aug 89 14:08:28 EDT Message-Id: <8908151808.AA00559@ATHENA.MIT.EDU> Received: by harvard.harvard.edu (5.54/a0.25) (for staff@athena.mit.edu) id AA09381; Tue, 15 Aug 89 14:09:42 EDT Received: by saber.HARVARD.EDU; Tue, 15 Aug 89 14:11:23 EDT Date: Tue, 15 Aug 89 14:11:23 EDT From: drr%saber@harvard.harvard.edu (David Reed) To: staff@ATHENA.MIT.EDU Subject: Compiler Postions Open *** EOOH *** Date: Tue, 15 Aug 89 14:11:23 EDT From: drr%saber@harvard.harvard.edu (David Reed) To: staff@ATHENA.MIT.EDU Subject: Compiler Postions Open Research and Development Positions Open at Saber Software, Inc. Come join a young energetic company to help define the future of programming environments. We are currently looking for highly motivated individuals to aid in the development of a Unix based C/C++ development environment. Candidates should have a strong compiler background, ideally C, C++, or Ada. Strong Unix and C skills also a requirement. Experience with programming environments, large systems, or shipping products a plus. Saber Software, Inc. is a successful vendor of software engineering tools. We offer an entrepreneurial workplace, convenient Cambridge location, and excellent benefits and salaries. Interested individuals should send their resumes to: Duncan Mewherter Saber Software, Inc. 185 Alewife Brook Parkway Cambridge, MA 02138  1,, Summary-line: 15-Aug kubitron@ATHENA.MIT.EDU #Re: FLAME: aklog Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06873; Tue, 15 Aug 89 14:36:35 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01108; Tue, 15 Aug 89 14:35:48 EDT Received: by ALEFNULL.MIT.EDU (5.61/4.7) id AA04863; Tue, 15 Aug 89 14:35:52 -0400 Message-Id: <8908151835.AA04863@ALEFNULL.MIT.EDU> To: Cc: ian@ATHENA.MIT.EDU, watchmakers@ATHENA.MIT.EDU, jstewart@ATHENA.MIT.EDU, motif@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU Subject: Re: FLAME: aklog In-Reply-To: Your message of Tue, 15 Aug 89 10:29:43 -0400. <8908151429.AA26307@SOUP.MIT.EDU> Date: Tue, 15 Aug 89 14:35:50 EDT From: John D. Kubiatowicz *** EOOH *** To: Cc: ian@ATHENA.MIT.EDU, watchmakers@ATHENA.MIT.EDU, jstewart@ATHENA.MIT.EDU, motif@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU Subject: Re: FLAME: aklog In-Reply-To: Your message of Tue, 15 Aug 89 10:29:43 -0400. <8908151429.AA26307@SOUP.MIT.EDU> Date: Tue, 15 Aug 89 14:35:50 EDT From: John D. Kubiatowicz Uh... Seems to me that nfsid -cell athena.mit.edu is rather an oxymoron... (NFSid!??). Also, why force users to type 26 letters when they can type 5? This seems rather rediculous. Also, what if they don't know which cell a given volume resides in?? Further, I LIKE the aklog interface which you developed (complete with path traversal). Figure that this is something that users will have to type at least once a term (final paper time, more than 8 hours at a workstation). Asking people to remember such a long invocation (nfsid) seems optimistic at best (remember we are talking REAL people). Further, asking them to reattach seems rather counterintuitive also (granted, the concept of "attach" is rather befuddled in the AFS domain, but...) I understand that this has been discussed, but it is always useful to flame about something... --KUBI--  1,, Summary-line: 16-Aug bgardner@ATHENA.MIT.EDU #Notes on #ifdef __STDC__ Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05077; Wed, 16 Aug 89 16:39:43 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11813; Wed, 16 Aug 89 16:39:16 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA02247; Wed, 16 Aug 89 16:39:21 -0400 Date: Wed, 16 Aug 89 16:39:21 -0400 Message-Id: <8908162039.AA02247@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Notes on #ifdef __STDC__ *** EOOH *** From: Date: Wed, 16 Aug 89 16:39:21 -0400 To: argus2@ATHENA.MIT.EDU Subject: Notes on #ifdef __STDC__ I tried compiling stuff with cc today, and it was horrendous the number of bugs in the argus header files. So, i thought I'd send out a note about what the major mistakes have been. There are only a couple that are repeated frequently. gcc use the definitions between the "#ifdef __STDC__" and the "#else" (there are no bugs there). cc uses the definitions between the "#else" and "#endif" (the else clause of the "#ifdef __STDC__"). The errors are: "const char *" -- There is no such a beastie..."const" is ONLY valid in the "#ifdef __STDC__" section, it is INVALID outside. (ie. - it shouldn't be in a struct definition or the #else section of the header files). "extern int foo(NOARGS);" -- There should be NOTHING between the parenthesises in a function definition; not even "NOARGS". Such things are only valid in functions defined within the "#ifdef __STDC__" and "#else" section, but never anywhere outside of that. As I say, there are only two minor bugs, but they are repeated consistently. (And consequently, our code won't compile under the standard unix cc compiler.) I'm going thru and fixing these now. (Priam's disk holding the gcc compiler died recently from a power tidalwave, and the gnu afs stuff isn't working at the moment either. So, I only have the cc compiler available, now. And nothing will compile, due to excessive error messages in the header file processing. Hence my sudden interest in header files.) -- Brian  1,, Summary-line: 17-Aug bgardner@ATHENA.MIT.EDU #shell actions documentation Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17876; Thu, 17 Aug 89 17:00:52 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29134; Thu, 17 Aug 89 17:00:32 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA03239; Thu, 17 Aug 89 17:00:39 -0400 Date: Thu, 17 Aug 89 17:00:39 -0400 Message-Id: <8908172100.AA03239@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: shell actions documentation *** EOOH *** From: Date: Thu, 17 Aug 89 17:00:39 -0400 To: argus2@ATHENA.MIT.EDU Subject: shell actions documentation I just looked at the code itself. I put a VERY brief description of the shell action's parameters into the file "/afs/athena/astaff/project/argus/doc/shellaction.txt" Wendy needs some documentation of that feature, so please feel free to edit this file and add what you know. Hope this is of some help. -- Brian  1,, Summary-line: 18-Aug geer@ATHENA.MIT.EDU #re: Serpent UIMS available Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25094; Fri, 18 Aug 89 11:20:24 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10156; Fri, 18 Aug 89 11:18:54 EDT Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA09297; Fri, 18 Aug 89 11:19:01 -0400 Message-Id: <8908181519.AA09297@E40-342F-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: re: Serpent UIMS available Date: Fri, 18 Aug 89 11:18:59 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Subject: re: Serpent UIMS available Date: Fri, 18 Aug 89 11:18:59 EDT i'd be interested in having this picked up. has anyone already done so or have other information on what might result? --dan ------- Forwarded Message Date: 15 Aug 1989 19:50:46-EDT From: Len.Bass@sei.cmu.edu Subject: Serpent UIMS available Apparently-To: xpert@athena.mit.edu The Serpent UIMS is available for public release. Serpent represents a new generation of User Interface Management Systems which manage the total dynamic behavior of an interface and which allow applications to remain uninvolved with the details of the user interface. It differs from available tools in this ability to handle dynamic behavior. Serpent is available for anonymous ftp. It can be found on fg.sei.cmu.edu under the directory /usr/data/ftp/pub/serpent. Serpent is designed to manage relatively arbitrary toolkits. There is a language which is used to describe the user interface and its dynamic behavior and an editor (under development) that allows the interface to be built using standard drawing facilities. Only the language and its supporting software is being released at this time. The language is very simple for specifying simple interfaces and is powerful enough to provide for creating visual programming demonstrations. Demonstrations of the language are included in the released software. The "Hello World" program written using Serpent is: #include "saw.ill" ||| OBJECTS: hello: label_widget {ATTRIBUTES: label_text: "Hello world"; } Serpent is intended to be used either with an application in a production environment or without an application in a prototyping environment. There is an interface description language used both by the application to describe its interface to Serpent and by the toolkits to describe their interface to Serpent. Applications and toolkits written in either C or Ada can be used with Serpent, although the interface description mechanism is designed to be extensible to other languages. The use of Serpent depends upon the types of toolkits which have been integrated into it. Currently, Serpent supports the Athena Widgets. The usage of the toolkit includes moving and resizing capability for widgets within their parents and point specification capabilities for form widgets to allow pointing for the positioning of new widgets. ------- End of Forwarded Message  1,, Summary-line: 19-Aug paul@ATHENA.MIT.EDU #It's Time for the 6.3B World Release -- WEDNESDAY NOON 8/23 Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03140; Sat, 19 Aug 89 03:49:14 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22185; Sat, 19 Aug 89 03:45:54 EDT Received: by ANATHEMA.MIT.EDU (5.61/4.7) id AA11370; Sat, 19 Aug 89 03:45:57 -0400 Date: Sat, 19 Aug 89 03:45:57 -0400 Message-Id: <8908190745.AA11370@ANATHEMA.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: It's Time for the 6.3B World Release -- WEDNESDAY NOON 8/23 *** EOOH *** From: Date: Sat, 19 Aug 89 03:45:57 -0400 To: staff@ATHENA.MIT.EDU Subject: It's Time for the 6.3B World Release -- WEDNESDAY NOON 8/23 After an impromptu hallway conference, it was decided that the 6.3B release is ready to go to the public, including the moving of dot files. Below is the tentative schedule of distribution events for the release. I assume that we'll test the RT's in 16 right after the Vaxen in 66. N.B. Peter Roden and Pete Ralston are on vacation. Dave Krikorian and I will be doing the actual pack-releasing and dot-moving. -Paul *PRELIMINARY* *PRELIMINARY* Release Schedule for the 6.3B Release Note: Pack Locations: RT: Leopold: rtsys63b and rtusr63b VAX: Chiroptera: vssys63b vsusr63b Before Tuesday What Who ------------------------------------------------------------------------------- Put in Hesiod Cluster info Paul and appropriate filsys names Tuesday Evening 8/22/89: What Who ------------------------------------------------------------------------------- Copy 6.3B Packs from Dave E40 to world (starting with building 66) Close building 66 Dave and test packs there. Wednesday 8/23/89: What Who ------------------------------------------------------------------------------- 9AM Begin dot file munge Dave After ^ Exchange Pack names Dave, Paul Watch world win or lose All  1,, Summary-line: 19-Aug mackay@ATHENA.MIT.EDU #BUG: Rule Editor Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05628; Sat, 19 Aug 89 16:18:55 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01381; Sat, 19 Aug 89 16:18:49 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00632; Sat, 19 Aug 89 16:18:38 -0400 Message-Id: <8908192018.AA00632@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: BUG: Rule Editor Date: Sat, 19 Aug 89 16:18:35 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: BUG: Rule Editor Date: Sat, 19 Aug 89 16:18:35 EDT Toby and Rich, If I create a rule with fields other than "from the message", save it , and read it back in again, they all come up as "from the message" ... and can't be changed to anything else. W  1,, Summary-line: 20-Aug tinoue@ATHENA.MIT.EDU #single line text widget Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA07703; Sun, 20 Aug 89 01:09:36 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04569; Sun, 20 Aug 89 01:09:32 EDT Received: by E40-334-1.MIT.EDU (5.61/4.7) id AA00651; Sun, 20 Aug 89 01:09:22 -0400 Message-Id: <8908200509.AA00651@E40-334-1.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Cc: tinoue@ATHENA.MIT.EDU Subject: single line text widget Date: Sun, 20 Aug 89 01:09:16 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Cc: tinoue@ATHENA.MIT.EDU Subject: single line text widget Date: Sun, 20 Aug 89 01:09:16 EDT OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: T.I. Organization: Project Athena Email Address: tinoue@athena Phone: x3-4277 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot GA Component (Module): PromptDialog OSF License Number: Client Hardware: Vax Station 2 Client Software: X11R3, 6.3B Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: Problem Description ------------------- Severity Level: Critical -- represents a problem which resulted in software malfunction or a feature failure and has no work-around. Date of First Occurrence: 8/10/89 One Line Description: A fatal error occures and the program stops if up, or down-arrow key is used in single line text. Full Description: While editing the single line text window in a prompt dialog widget, I accidentaly used the up-arrow key, then, a segmentation fault occurred and the program stopped. Repeat By: It happens when either an up-arrow key or a down-arrow kew is used, regardless of using MuSingleLineEmacsBindings(). Proposed Solution: The event handling function must be wrong. Users could avoid this by making a translation table which overrides the text widget. But I think to make a translation table for a text widget is not a simple work. In addition, as for the text widget in a prompt dialog, it is again troublesome to write a translation table because we have to write it in a C source, not in a UIL source. I suggest we wait until it is fixed.  1,, Summary-line: 20-Aug tinoue@ATHENA.MIT.EDU #convenience dialogs Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA07754; Sun, 20 Aug 89 01:21:37 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04602; Sun, 20 Aug 89 01:21:34 EDT Received: by E40-334-1.MIT.EDU (5.61/4.7) id AA00658; Sun, 20 Aug 89 01:21:24 -0400 Message-Id: <8908200521.AA00658@E40-334-1.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Cc: tinoue@ATHENA.MIT.EDU Subject: convenience dialogs Date: Sun, 20 Aug 89 01:21:19 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Cc: tinoue@ATHENA.MIT.EDU Subject: convenience dialogs Date: Sun, 20 Aug 89 01:21:19 EDT OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: T.I. Organization: Project Athena Email Address: tinoue@athena Phone: x3-4277 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot GA Component (Module): Convenience Dialogs OSF License Number: Client Hardware: Client Software: Server Hardware: or SAME AS CLIENT Server Software: or SAME AS CLIENT Compiler: Problem Description ------------------- Severity Level: Enhancement -- represents a request for enhancement of the software. Date of First Occurrence: Aug 1989 One Line Description: Inconvenient points of convenience dialogs Full Description: 1. There seem to be no ways to manipulate resource values in UIL files for children of convenience dialogs. In C, we can see widget IDs for OK, Cancel, Help, Text.. widgets by calling XmMessageBoxGetChild, or XmSelectionBoxGetChild and can specify any resource values according to the child's class. We cannot do that in UIL. If the purpose of using UIL is to allow designers to develop user interface designs that are independent of application contents, it is inconsistent as well as inconvenient. 2. I do not know the widget names of children widgets. Unless we know the names, we cannot move resource value specs into resource files. We could specify it by writing class names, but then, we cannot distinguish, such as, the OK button from the help button because both are in a push_button class. 3. Besides resource values, we sometimes want to set callback functions for children of dialogs. E.g., when we want to use the function MuSetSingleLineEmacsBindings() for the text widget in PromptDialog, we have no ways to specify that in a UIL file because that function should be a callback which attributes to the text widget; we have no place to write callback functions for children of dialog widgets. Repeat By: Proposed Solution: One easy solution is to allow the resource names to be child name followed by resource names of child's class. For example, resource names of OK button as a child of dialogs could be ok_background_color, ok_label_string, smt. like that. Since the ok button is in push_button class, all resource name in push_button class could be available for the ok button by prefixing 'ok_'. In a similar fashion, above-mentioned callback can also be realized by setting the reason such as, 'text_create = procedure MuSetSingleLineEmacsBindings();'. As for the child name, I have no idea. It might be a 'parent name'+'OK', 'parent name'+'HELP' .... like a text widget's parent name for the scrolled text widget, i.e. 'child name'+'SW'. Since the origins of the resource file and the UIL are different(?), there are incon(sistent or venient) points, I think. For example, the Class concept in terms of the extent of resource value validity, UIL is a little weak; UIL seems to me a name-oriented concept. These are just my ideas. They may be too easy ways and we must be prudent. One thing I am concerning is that to allow too many things must cause to violate the rule of the Motif Style Guide and that means there could be many inconsistent user-interfaced softwares.  1,, Summary-line: 21-Aug hvega@ATHENA.MIT.EDU #MotifUtilities Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA18890; Mon, 21 Aug 89 15:38:50 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA20967; Mon, 21 Aug 89 15:38:40 EDT Received: by E51-007-7.MIT.EDU (5.60/4.7) id AA01343; Mon, 21 Aug 89 15:38:29 EDT Message-Id: <8908211938.AA01343@E51-007-7.MIT.EDU> To: motif@ATHENA.MIT.EDU Subject: MotifUtilities Date: Mon, 21 Aug 89 15:38:25 EDT *** EOOH *** From: To: motif@ATHENA.MIT.EDU Subject: MotifUtilities Date: Mon, 21 Aug 89 15:38:25 EDT There are three more functions available from MotifUtilities: ** Descriptions of these functions are after "**********" . ** void MuSetSensitive(string) /* to be used from UIL only */ char *string; void MuErrorSync(string) char *string void MuWarningSync(string) char *string -------------------------------------------------------------------- Also, before, if you called MuError or MuWarning several times in a row (not giving the user a chance to press OK and unmanage the dialog boxes), they would crash. They no longer behave this way -- if you call MuError or MuWarning twice in a row, not letting them become unmanaged first, they will just ignore the second call. -------------------------------------------------------------------- Furthermore, if you haven't read the mail from kcmcmaho : Subject: saber If you try to load libMu.a or any object file compiled by gcc with -g into saber, it won't work. To fix this use "load -G" in saber. This tells saber to ignore debugging information, which is what screws it up with gcc-compiled stuff. ********************************************************************** MuWarningSync and MuErrorSync are synchronous versions of the MuWarning and MuError functions. They are great for dealing with fatal errors and the like -- in the event of a fatal error where the user cannot continue the program, you can warn the person before taking down the program using MuErrorSync or MuWarningSync (the function will wait for the OK button, then exit or do whatever you want it to do). These functions were Chris Vanharen's idea. ************************************************************************ MuSetSensitive is to be used from UIL only. It sets a widget to be sensitive (the widget should receive keyboard and pointer events) if it's not currently sensitive, or it sets it to be insensitive if it's currently sensitive. This is useful if you want to make certain button insensitive or sensitive when a certain process is called. You pass it a string description of the widget that you had registered with MuRegisterWidget. e.g. object button : push_button { arguments { label_label = compound_string('Does something'); }; callbacks { create = procedure MuRegisterWidget("p_button"); activate = procedures { MuSetSensitive("p_button"); Do_something(); }; }; }; In this example after the push button is activated, the button will become insensitive, and the application will "Do_something()". **********************************************************************  1,, Summary-line: 21-Aug hvega@ATHENA.MIT.EDU #Mu functions MuGetBoolean and MuGetString Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA19169; Mon, 21 Aug 89 15:55:11 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21259; Mon, 21 Aug 89 15:55:02 EDT Received: by E51-007-7.MIT.EDU (5.60/4.7) id AA01366; Mon, 21 Aug 89 15:54:49 EDT Message-Id: <8908211954.AA01366@E51-007-7.MIT.EDU> To: motif@ATHENA.MIT.EDU Subject: Mu functions MuGetBoolean and MuGetString Date: Mon, 21 Aug 89 15:54:44 EDT *** EOOH *** From: To: motif@ATHENA.MIT.EDU Subject: Mu functions MuGetBoolean and MuGetString Date: Mon, 21 Aug 89 15:54:44 EDT I forgot to mention that the convenience dialog widgets used in Mu functions MuGetBoolean and MuGetString have a bug which causes these functions to crash (when you click on the help button in the dialog boxes, the help box appears, but the dialog boxes disappears -- this messes up the setjmp and longjmp calls, and you get an error message that says "longjmp botch" if you are on the vax and "segmentation violation" or "bus error" if you are on the rt. I'm going to file a bug report and see if this will be fixed. In the mean time I've commented out part of my code which manages and adds callbacks to the help button. Therefore, even if you send a non-NULL helptext, the help button will not appear for now. If you don't want a help button with these dialog boxes, continue to send NULL for helptext when you call MuGetBoolean and MuGetString.  1,, Summary-line: 21-Aug hvega@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21203; Mon, 21 Aug 89 18:47:47 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23989; Mon, 21 Aug 89 18:47:44 EDT Received: by GEVALT.MIT.EDU (5.61/4.7) id AA18796; Mon, 21 Aug 89 18:47:23 -0400 Message-Id: <8908212247.AA18796@GEVALT.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Date: Mon, 21 Aug 89 18:47:11 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Date: Mon, 21 Aug 89 18:47:11 EDT OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: Hyun-Ju Vega Organization: mit (athena) Email Address: hvega@mit.edu Phone: 253-0173 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot GA and version 1 Component (Module): SelectioB.h , MessageB.h OSF License Number: Client Hardware: vax and rt Client Software: uwm Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: gcc and hc2 Problem Description ------------------- Severity Level: severe Incompatibility -- represents a problem which resulted from inability to install the software on the machine. Fatal -- represents a problem which resulted in a software crash or required reboot of the software. Critical -- represents a problem which resulted in software malfunction or a feature failure and has no work-around. Severe -- represents a problem which resulted in software functionality limitation but had alternative work-around. Minor -- represents a cosmetic type problem. Enhancement -- represents a request for enhancement of the software. Date of First Occurrence: 8/16/89 One Line Description: Problem with the XmNhelpCallback in XmCreateQuestionDialog and XmCreatePromptDialog. Full Description: After the question dialog and the prompt dialog are created in C, a callback is added to the help button using the resource XmNhelpCallback. When the help button is pushed, an information dialog is supposed to popup. However, when the information dialog (with the help text) pops up, the question dialog or the prompt dialog is unmanaged -- in fact, they seem to become unmanaged just when the information dialog is created. Repeat By: ( call Popup_question() ) /* ****************************************************************** */ static Widget DialogBox = NULL; static Widget HelpBox = NULL; Popup_question(toplevel, helptext) Widget toplevel; char *helptext; { Arg args[10]; int n; if (DialogBox == NULL) { n = 0; XtSetArg(args[n], XmNdialogStyle, XmDIALOG_APPLICATION_MODAL); n++; DialogBox = XmCreateQuestionDialog(toplevel, "DialogBox",args,n); HelpButton = XmMessageBoxGetChild(DialogBox, XmDIALOG_HELP_BUTTON); XtRealizeWidget(DialogBox); } if (helptext != NULL) { if (!XtIsManaged(HelpButton)) XtManageChild(HelpButton); if (XtHasCallbacks(DialogBox, XmNhelpCallback)==XtCallbackHasNone) XtAddCallback(DialogBox, XmNhelpCallback, HelpCallback, helptext); } else { if (XtIsManaged(HelpButton)) XtUnmanageChild(HelpButton); if (XtHasCallbacks(DialogBox, XmNhelpCallback)==XtCallbackHasSome) XtRemoveCallback(DialogBox,XmNhelpCallback, HelpCallback, helptext); } if (!XtIsManaged(DialogBox)) XtManageChild(DialogBox); } static void HelpCallback(w, tag, callback_data) Widget w; char *tag; caddr_t *callback_data; { Arg args[10]; int n; Widget dummy; if (HelpBox == NULL) { n = 0; XtSetArg(args[n], XmNdefaultButtonType, XmDIALOG_OK_BUTTON); n++; XtSetArg(args[n], XmNdialogStyle, XmDIALOG_APPLICATION_MODELESS); n++; HelpBox = XmCreateErrorDialog(MuToplevel, "HelpBox",args,n); dummy = XmMessageBoxGetChild(HelpBox, XmDIALOG_CANCEL_BUTTON); XtUnmanageChild(dummy); dummy = XmMessageBoxGetChild(HelpBox, XmDIALOG_HELP_BUTTON); XtUnmanageChild(dummy); XtRealizeWidget(HelpBox); } XtSetArg(args[n], XmNmessageString, XmStringLtoRCreate(tag,"ISOLatin1")); n++; XtSetValues(HelpBox, args, n); if (!XtIsManaged(HelpBox)) XtManageChild(HelpBox); } /* ****************************************************************** */  1,, Summary-line: 22-Aug geer@ATHENA.MIT.EDU #re: XDMCP is ready for Public Review Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA29534; Tue, 22 Aug 89 15:21:33 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05832; Tue, 22 Aug 89 15:20:16 EDT Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA00825; Tue, 22 Aug 89 15:20:02 -0400 Message-Id: <8908221920.AA00825@E40-342F-2.MIT.EDU> To: sysdev@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: re: XDMCP is ready for Public Review Date: Tue, 22 Aug 89 15:19:59 EDT *** EOOH *** From: To: sysdev@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: re: XDMCP is ready for Public Review Date: Tue, 22 Aug 89 15:19:59 EDT this material is available from me now. if you are able to review it formally, so much the better. pick it up here, and if you will work on the review part, let me know. --dan ------- Forwarded Message From: rws@expo.lcs.mit.edu To: advisory@expo.lcs.mit.edu Cc: security@expo.lcs.mit.edu Subject: XDMCP is ready for Public Review Date: Mon, 21 Aug 89 15:13:53 -0400 I believe the X Display Manager Control Protocol (XDMCP) specification is ready for Public Review. I will forward the current version of the document in a separate message. I would like votes from Advisory representatives by Friday, September 1, on whether or not to forward for Public Review. A prototype implementation has been produced by Network Computing Devices, and we are working on extending and integrating this into R4 sources. We expect to have the code completed and ready for R4 beta. ------- End of Forwarded Message  1,, Summary-line: 22-Aug orcutt@ATHENA.MIT.EDU #DRAFT for your comments ASAP Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01991; Tue, 22 Aug 89 18:39:44 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08770; Tue, 22 Aug 89 18:37:07 EDT Received: by E40-391A-2.MIT.EDU (5.61/4.7) id AA04424; Tue, 22 Aug 89 18:36:51 -0400 Message-Id: <8908222236.AA04424@E40-391A-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: DRAFT for your comments ASAP Date: Tue, 22 Aug 89 18:36:47 EDT From: Ronald L. Orcutt *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: DRAFT for your comments ASAP Date: Tue, 22 Aug 89 18:36:47 EDT From: Ronald L. Orcutt Folks, Below is a draft of an Athena explanation about the Fall release, to be used to respond to questions or comments. Please review and comment to me by 10 am Wednesday (tomorrow). I'm particuarly interested in comments about: (1) contact points w/i Athena and escalation of complaints, (2) suggestions for dissemination (I want this to go on-line, be pointed to by a MOTD, postered, others?), and (3) accuracy. Ron =============================================================================== Memo to: The Athena User Community From: Ronald L. Orcutt Executive Director Date: August 21, 1989 Subject: New Software Release for the Fall '89 Term Beginning this week, Project Athena will begin to install a new release of the system software, Release 6.3B. This release provides the hooks that will enable us to introduce new and important functionality to the user community on an optional basis during the course of the Fall term, without disrupting existing applications. Some examples of improved functionality we will be introducing include: the Andrew File System through which we will introduce new educational widgets for courseware development, software that allows us to track and charge for printing, and a new window manager based on the Open Software Foundation's graphical user interface, MOTIF. You will also see a new on-line Help facility, that facilitates getting to the information you need much more quickly. We will be introducing to faculty and TA's a new network service called OLTA (on line teaching assistant) for TA's to support students on a per-course basis. And, we are planning a large deployment of additional workstations, primarily but not exclusively in departmental clusters. With this release, we are also introducing a graphically-oriented display manager, xdm, as part of Athena's commitment to improve its user interface. In order to accomplish this, it was necessary also to introduce a new architecture of command (or 'dot') files in users' home directories. For new users (and with the opening of Athena to graduate students, we anticipate the largest fraction of first-time users to Athena in several years) learning this new artchitecture will be a normal part of their learning how to get around Athena. Returning users' accounts will be fully functional, albeit in a 'default' mode. Those who wish to customize their environment or restore prior customizations will have to learn enough of the new architecture to create and/or edit these new command files. For the most part, this will entail cutting and pasting contents of old command files into new command files. Documenation describing the function of each new command file with examples showing how to perform the editing will be readily available in public clusters and from Athena consultants beginning with the new release. Athena will provide special assistance to get returning users over this hurdle. The Athena consulting staff will be ready to address 'dot' file questions beginning with the release installation through the normal mechanisms of OLC, the Consulting Hotline, and in-person visits to 11-115. In addition, the Athena cluster in 11-116 will be staffed with experienced consultants and other Athena staff from September 5 through the first two weeks of classes, on a schedule that will be posted on-line and in the clusters, specifically to help users through this change. A question has been raised about ensuring the privacy of each user's locker, and the process by which Athena will introduce the new command files into those lockers. Athena Operations will perform an automated script that renames old command files as follows: .filename --> .filename.prefall89 and writes two new command files, .cshrc and .login, into the user's locker. Exception tracking is built into the process that will enable us to 'flag' unusual situations requiring that we contact the user individually. At no time during the process are the contents of any user files read or altered.  1,, Summary-line: 23-Aug mackay@ATHENA.MIT.EDU #File protections Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA04411; Wed, 23 Aug 89 00:03:01 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA12262; Wed, 23 Aug 89 00:03:01 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA08893; Wed, 23 Aug 89 00:02:45 -0400 Message-Id: <8908230402.AA08893@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: File protections Date: Wed, 23 Aug 89 00:02:40 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: File protections Date: Wed, 23 Aug 89 00:02:40 EDT Hi. I've been trying to move the doc directory over to /afs/athena/astaff/project/argus/doc, but everything is protected against me. Suggestions? Wendy  1,, Summary-line: 23-Aug geer@ATHENA.MIT.EDU #re: call for participation in the 4th Annual X Technical Conference Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08168; Wed, 23 Aug 89 11:35:07 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA18084; Wed, 23 Aug 89 11:33:35 EDT Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA06419; Wed, 23 Aug 89 11:33:19 -0400 Message-Id: <8908231533.AA06419@E40-342F-2.MIT.EDU> To: sysdev@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: re: call for participation in the 4th Annual X Technical Conference Date: Wed, 23 Aug 89 11:33:15 EDT *** EOOH *** From: To: sysdev@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: re: call for participation in the 4th Annual X Technical Conference Date: Wed, 23 Aug 89 11:33:15 EDT ------- Forwarded Message From: rws@expo.lcs.mit.edu To: xpert@expo.lcs.mit.edu Subject: call for participation in the 4th Annual X Technical Conference Date: Tue, 22 Aug 89 15:52:09 -0400 CALL FOR PARTICIPATION in the 4TH ANNUAL X TECHNICAL CONFERENCE The 4th annual Technical Conference on the X Window System will be held on January 15-17, 1990 at the Marriott Copley Place Hotel in Boston, MA. The conference, sponsored by the MIT X Consortium, will bring together experts from industry and academia to present and discuss leading edge research and development in the X environment. This is an ideal opportunity to learn about the very latest X technology, and to talk individually with a variety of developers. As with last year, there will be tutorials on the first day. If you are interested in giving a tutorial, please contact us. We are particularly interested in topics which have not been given before, or which have had only limited attendance. Tutorials on commerical products are allowed, although we reserve the right to have the material "(un)slanted" appropriately for the conference. The second two days will be devoted to talks, in a single track. Presentations can be anywhere from 5 to 50 minutes, and video tape is welcome. Written papers are welcome, but not required; but, we would like to reproduce any slides and written materials in advance for distribution at the conference. There is no set "theme" for the conference; we are interested in submissions covering all aspects of X. Presentations on both research and commercial developments are welcome. On all three days, there will be "Birds of a Feather" sessions for general discussion of areas of specific interest to the attendees. If there are particular BOFs you would like to see or run, please let us know. As usual, there will no "trade show" attached to this conference. If you would like to give a tutorial, make a presentation, or run a BOF, send details to: xconference@expo.lcs.mit.edu or Bob Scheifler Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139 Network mail is preferred. Please include your name, net and postal address, phone number, affiliation, a reasonably detailed outline of what you want to present, what your relationship is to the work (e.g. project manager, principal designer, lead engineer, me-myself-and-I), how much time you need, and what A/V facilities you need. The deadline for submissions is November 17; receipt will be acknowledged. However, we will not wait for this deadline before making decisions on tutorials, so the earlier you get your tutorial proposal in, the better your chances are. If you are interested in serving (electronically) on the program committee for this conference, please send mail by September 22 to: xconference@expo.lcs.mit.edu Due to the costs of holding the conference off campus (we've outgrown MIT's facilities), there will be a registration fee of $50, covering the entire conference (this is not to make a profit, but to keep the X Consortium subsidy within reason). Exceptions will be made for students who cannot afford the fee. Since there will be a fee this year, registration will not be handled by electronic mail. Please do *not* send inquiries about registration yet; we'll send out registration and hotel information a little later. However, if you believe your network mail is unreliable and are concerned that you might not see later announcements in this forum, you can be placed on a mailing list to receive information by post by writing to: X Technical Conference c/o MIT Conference Services Room 7-111 77 Massachusetts Ave Cambridge, MA 02139 ------- End of Forwarded Message  1,, Summary-line: 23-Aug orcutt@ATHENA.MIT.EDU #Athena Statement on new Fall Release Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11259; Wed, 23 Aug 89 15:31:20 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21980; Wed, 23 Aug 89 15:29:01 EDT Received: by E40-391A-2.MIT.EDU (5.61/4.7) id AA08536; Wed, 23 Aug 89 15:28:43 -0400 Message-Id: <8908231928.AA08536@E40-391A-2.MIT.EDU> To: staff@ATHENA.MIT.EDU, usermsgs@ATHENA.MIT.EDU, sipb-staff@ATHENA.MIT.EDU Subject: Athena Statement on new Fall Release Date: Wed, 23 Aug 89 15:28:39 EDT From: Ronald L. Orcutt *** EOOH *** To: staff@ATHENA.MIT.EDU, usermsgs@ATHENA.MIT.EDU, sipb-staff@ATHENA.MIT.EDU Subject: Athena Statement on new Fall Release Date: Wed, 23 Aug 89 15:28:39 EDT From: Ronald L. Orcutt Below is an announcement about the Fall release for your information and use. This document will be posted on cluster doors and placed on-line in the info locker. =============================================================================== Memo to: The Athena User Community From: Ronald L. Orcutt Executive Director Date: August 21, 1989 Subject: New Software Release for the Fall '89 Term Beginning this week, Project Athena will install a new release of the system software, Release 6.3B. I want to highlight just a few of the new features in this release, some apparent and some behind the scenes. I also want to anticipate and address some questions you may have about the new release. This release will enable users to try out new and important features during the course of the Fall term without disrupting existing applications. These features include a new window manager based on the Open Software Foundation's MOTIF graphical user interface, software that will allow us to control and recover printing expenses, and the Andrew File System (AFS) through which we will offer new tools for shared courseware development. You will also see a new on-line Help facility that provides a centralized place from which you will be able to find all the information and documentation about Athena. You should be able to find what you need much more quickly. This new Help system is not yet complete, so all information and documentation will continue to be available in the traditional locations. We will introduce a new network service, the On-Line Teaching Assistant (OLTA), that will greatly facilitate TA's support of students on course-related questions. OLTA uses the same syntax as OLC, so students should be able to use it with little or no difficulty. With this release, we are introducing a graphically-oriented display manager, 'xdm,' as part of Athena's commitment to improve its user interface. In order to accomplish this, it was necessary also to introduce a new architecture of command (or 'dot') files in users' home directories. With the opening of Athena to graduate students and the arrival of new freshmen, we anticipate the largest number of first-time users to Athena in several years. For these new users, learning this new architecture will be a normal part of their getting acquainted with Athena. Returning users' accounts will be fully functional, although in a system-wide 'default' mode, without any customizations they may have previously introduced. The process we use to introduce new command files into users' lockers has been designed to ensure the privacy and integrity of the contents each user's files. Athena Operations has performed an automated script that renames old command files as follows: .filename --> .filename.prefall89 and writes two new command files, .cshrc and .login, into each user's locker. Exception tracking is built into the process that will enable us to 'flag' unusual situations requiring that we contact the user individually. At no time during the process are the contents of any user files read, altered, or deleted. Returning users who wish to restore prior customizations will need to learn enough of the new architecture to create new command files. For the most part, customization will entail cutting and pasting the contents of old command files into new command files. User documentation describing the new release and what's changed from the prior release will be readily available on-line and in the public clusters. Separate documentation describing the function of each new command file with examples showing how to create ne  1,, Summary-line: 25-Aug tinoue@ATHENA.MIT.EDU #form widget Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25010; Fri, 25 Aug 89 01:51:13 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15813; Fri, 25 Aug 89 01:51:21 EDT Received: by E40-334-1.MIT.EDU (5.61/4.7) id AA25026; Fri, 25 Aug 89 01:50:55 -0400 Message-Id: <8908250550.AA25026@E40-334-1.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Cc: tinoue@ATHENA.MIT.EDU Subject: form widget Date: Fri, 25 Aug 89 01:50:50 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Cc: tinoue@ATHENA.MIT.EDU Subject: form widget Date: Fri, 25 Aug 89 01:50:50 EDT OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: T.I. Organization: Project Athena Email Address: tinoue Phone: x3-4277 Hardware/Software Configuration ------------------------------- Offering and Version: Motif snapshot GA Component (Module): form widget OSF License Number: Client Hardware: Vax station2 Client Software: X11R3, Athena 6.3B Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: cc Problem Description ------------------- Severity Level: Severe -- represents a problem which resulted in software functionality limitation but had alternative work-around. Date of First Occurrence: 8/25/89 One Line Description: Form's geometry management not correct, when it resizes. Full Description: In the Athena Widget set, a form widget has constraint resources such as XtNleft, XtNtop, etc. and if they are specified as 'XtRubber' in its children, the toolkit automatically calculates the space size and the widget size proportion to the new size of the parent form widget, and set new positions correctly. This functionality must be necessary in the Motif Widget Set. I tried that in various ways using every direction's attachment, but I was obstinately rejected to do that. Sometimes, the children did not change their size or space. Sometimes, only right widgets and bottom widgets changed their sizes; what an ugly feature!! Repeat By: Play with this.... module demo version = 'V1.0' names = case_sensitive include file 'XmAppl.uil'; object main:form{ arguments { horizontal_spacing = 5;}; controls{ label child1; label child2; label child3;};}; object child1:label{ arguments { left_attachment = XmATTACH_FORM; };}; object child2:label{ arguments { left_attachment = XmATTACH_WIDGET; left_widget = label child1; };}; object child3:label{ arguments { left_attachment = XmATTACH_WIDGET; left_widget = label child2; right_attachment = XmATTACH_FORM; };}; end module; Proposed Solution: I am doing event handling in C, i.e. using XtAddEventHandler and a callback function; selecting ConfigureNotify, and calculating new geometry by using 'ev.configure.width' and 'ev.configure.height'. I am not sure if I am using a proper method; it was tough.  1,, Summary-line: 28-Aug thm@ATHENA.MIT.EDU #rule life (and more on rile life) Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA14427; Mon, 28 Aug 89 09:38:35 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA26412; Mon, 28 Aug 89 09:38:51 EDT Received: by MYCROFT.MIT.EDU (5.61/4.7) id AA15836; Mon, 28 Aug 89 09:38:17 -0400 Date: Mon, 28 Aug 89 09:38:17 -0400 Message-Id: <8908281338.AA15836@MYCROFT.MIT.EDU> To: mackay@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU In-Reply-To: 's message of Sat, 26 Aug 89 20:45:35 EDT <8908270045.AA00599@E40-368-1.MIT.EDU> Subject: rule life (and more on rile life) *** EOOH *** From: Date: Mon, 28 Aug 89 09:38:17 -0400 To: mackay@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU In-Reply-To: 's message of Sat, 26 Aug 89 20:45:35 EDT <8908270045.AA00599@E40-368-1.MIT.EDU> Subject: rule life (and more on rile life) I checked Argusi and rule life is on. But the last time it was updated was on August 31, 1988. (No, that's not a typo -- it was last year.) I have made many rules since then, so I'm not sure why it's not recording the changes. The reason for this is that your rule-life collection interval was set from Tue Aug 30 03:38:48 1988 to Wed Aug 31 03:38:48 1988. Rule life is not a periodic collection category; it does not renew its interval (it would not make sense for it to do so). [And in another message:] When I tried to save Argusi, I got the following message: The date parser might be incorrectly parsing the date Tue Aug 30 03:38:48 1988 It things the date is Tue Aug 29 03:10:48 1989 If this is incorrect please press cancel and adjust the date by the correct amount. Otherwise press O.K. to continue saving. My guess is that the problem is that it is not saving the year... Close; the issue is not about saving, it's about the bug in the date parser. The work around I have depends on stripping the year off the date string (since it's the year that causes the bug) and comparing the parse of the truncated string with the value that the parse should have been if it weren't for the bug (the difference between this value and the bugged value is a known constant). The reason why the known unbugged value is not used without checking it against the stripped-date parse is because we want to make sure that the bug actually occured, i.e. that there is a date (the cause of the bug). In general, if the date is there and stripped off, the new parsed value should be the same as the corrected bug value. If it is not, as in your case, Argusi thinks that what it stripped off was not a date, and so it assumes it doesn't know what is going on and reports to the user. What happened here is that it *was* a date, but stripping it off gave a new string that was assumed to be 1989, whose value obviously didn't match with the same string in 1988. I really should enhance the workaround so that it tries to adjust for the possible difference in the year. This is doable. Also, the text widget acts very oddly. When I press the delete key, it deletes to the right, not to the left. To delete a line, I had to move the cursor to the beginning of the line and press delete until the line disappeared. This is standard Motif text widget behavior. I had thought Rich had a set of translations for the text widget but he didn't, and I decided that all our texts should behave the same so i didn't make up my own. We should check out the MU text translations that give you Emacs bindings. thm  1,, Summary-line: 29-Aug hvega@ATHENA.MIT.EDU #MotifUtilities changes Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25060; Tue, 29 Aug 89 11:12:24 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA13841; Tue, 29 Aug 89 11:12:20 EDT Received: by E51-007-1.MIT.EDU (5.61/4.7) id AA05936; Tue, 29 Aug 89 11:11:42 -0400 Message-Id: <8908291511.AA05936@E51-007-1.MIT.EDU> To: motif@ATHENA.MIT.EDU Subject: MotifUtilities changes Date: Tue, 29 Aug 89 11:11:36 EDT *** EOOH *** From: To: motif@ATHENA.MIT.EDU Subject: MotifUtilities changes Date: Tue, 29 Aug 89 11:11:36 EDT ** Especially important if you're using MuGetBoolean, MuGetString, or MuGetFileName. ** 1) Everyone who are using MotifUtilities functions should include file "Mu.h" in their C files. 2) A feature has been added to the MotifUtilities functions MuGetBoolean, MuGetString, and MuGetFileName. Unfortunately, if you are using one of these functions, and even if you don't want to use the feature, it'll require a small change in your code. A parameter has been added to the above functions which determines where the dialog box pops up. The options for the popup control are: Mu_Popup_Left -- popup to the left of parent, Mu_Popup_Right -- popup to the right of parent, Mu_Popup_Bottom -- popup at the bottom of the parent, Mu_Popup_Top -- popup at the top of the parent, Mu_Popup_Center -- popup at the center of the parent (same as passing NULL), Mu_Popup_Pointer -- popup directly underneath the pointer, Mu_Popup_Previous -- popup at the same coordinates as the last "management" of the dialog box (therefore, if a user moves the dialog box to a location on the screen different from where it had popped up, that would be the coordinates of the last "management" of the dialog box), NULL -- if you want the default behavior, which is popping up in the center of the parent (same as Mu_Popup_Center). Note: If there is not enough room on the screen for a dialog box to popup on top, bottom, left or right of the parent, then the dialog box will overlap the parent interface. Also, if you specify Mu_Popup_Previous and the dialog box had never been managed before (i.e first time it's being called), it will popup in the top left corner of the screen. Bug: If you are using mwm, you may notice that the popup dialog box sometimes will not popup in the correct position. You may see this problem if you resize your application window after the dialog box had already been managed once. This behavior may go away after a couple of popups. Since this problem doesn't occur in uwm, it's probably an mwm quirk. This bug will be corrected once we figure out what's going on. (If you don't want to deal with this bug in mwm, don't specify Mu_Popup_Left, Mu_Popup_Right, Mu_Popup_Bottom, or Mu_Popup_Top.) Note: Boolean MuGetBoolean(prompt, yeslabel, nolabel, helptext, defaultbutton, popup_control) char *prompt, *yeslabel, *nolabel; char *helptext; Boolean defaultbutton; int popup_control; Boolean MuGetString(prompt, buffer, bufsize, helptext, popup_control) char *prompt; char *buffer; int bufsize; char *helptext; int popup_control; Boolean MuGetFile(buffer, bufsize, dirmask, dirmasksize, helptext, popup_control) char *buffer; int bufsize, dirmasksize; char *dirmask; char *helptext; int popup_control; ****************************************************************************  1,, Summary-line: 29-Aug bgardner@ATHENA.MIT.EDU #States: "message properties" & "processing state" Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27849; Tue, 29 Aug 89 15:31:22 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA18393; Tue, 29 Aug 89 15:31:42 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA00447; Tue, 29 Aug 89 15:31:08 -0400 Date: Tue, 29 Aug 89 15:31:08 -0400 Message-Id: <8908291931.AA00447@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: States: "message properties" & "processing state" *** EOOH *** From: Date: Tue, 29 Aug 89 15:31:08 -0400 To: argus2@ATHENA.MIT.EDU Subject: States: "message properties" & "processing state" In reference to Wendy's note to Rich: > we decided that we should distinguish > between "message properties" (e.g. length) and "processing state" > (e.g. number of times a rule fired). It seems a good idea to distinguish between the two types of states, but I think the term "message properties" is too confusing. A "user property" is literally a property of a message, already (probably more so than the length of a message). I would suggest instead that we use the term "property" to mean a property which can be set by external means (ie by a user or a msg source), for the sake of consistency. And use some other term like "state" to mean the properties determined internally. I suggest the term "fixed states" to describe unchangable intern states (like length), rather than "message properties", for clarity. (Although, "message state" would also be reasonable.) So, a better scheme might be: we should distinguish between "message states" (e.g. length) and "processing state" (e.g. number of times a rule fired). Does this seem better ? -- Brian .  1,, Summary-line: 30-Aug djf@ATHENA.MIT.EDU #Motif 1.0 now installed Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA04631; Wed, 30 Aug 89 11:25:49 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01234; Wed, 30 Aug 89 11:26:05 EDT Received: by TOTO.MIT.EDU (5.61/4.7) id AA19053; Wed, 30 Aug 89 11:25:31 -0400 Date: Wed, 30 Aug 89 11:25:31 -0400 Message-Id: <8908301525.AA19053@TOTO.MIT.EDU> To: motif@ATHENA.MIT.EDU Subject: Motif 1.0 now installed *** EOOH *** From: Date: Wed, 30 Aug 89 11:25:31 -0400 To: motif@ATHENA.MIT.EDU Subject: Motif 1.0 now installed Motifdev is now a locker. You can now type 'attach motifdev' and have the illusion that the afs filesystem is under /mit/motifdev. The libraries in /mit/motifdev/{vax,rt}lib are 1.0. The old snapshot11 libraries are available as Mrm.11, Xm.11, and Xt.11 /mit/motifdev/{vax,rt}bin/uil is the 1.0 version of uil. The old uil is available as uil.11. /mit/motifdev/include/{Xm,X11,Mrm,uil} contains the header files from the 1.0 tape. The old include files are available in /mit/motifdev/include.11 /mit/motifdev{vax,rt}bin/uilfilter is a program that will convert your old uil files to the new, improved uil format. This involves changing all the widget and resource names to match those used in C. For example: list_box becomes XmList. Use the program like this: uilfilter < olduilfile > newuilfile Then when you write new uil, remember to use the new naming scheme. Things should have stabilized some at this point, but we will still be getting bug fixes from the OSF and periodic snapshots of Motif 1.1 Sometime soon a locker named "motif" will be created. This locker will contain libraries and executables for availability to all of mit. I will send mail when that locker is set up, and recommend that everyone start to get libraries from there. Let me know if there are problems with the installation of the 1.0 release. -- David Flanagan  1,, Summary-line: 31-Aug bgardner@ATHENA.MIT.EDU #dcc's message on spec., I'm forwarding to rest of us Argus folks. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA19275; Thu, 31 Aug 89 20:12:19 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA25141; Thu, 31 Aug 89 20:12:44 EDT Received: by M11-111-1.MIT.EDU (5.61/4.7) id AA01669; Thu, 31 Aug 89 20:12:04 -0400 Date: Thu, 31 Aug 89 20:12:04 -0400 Message-Id: <8909010012.AA01669@M11-111-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: dcc's message on spec., I'm forwarding to rest of us Argus folks. *** EOOH *** From: Date: Thu, 31 Aug 89 20:12:04 -0400 To: argus2@ATHENA.MIT.EDU Subject: dcc's message on spec., I'm forwarding to rest of us Argus folks. (Message inbox:39) Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17996; Thu, 31 Aug 89 17:24:55 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23421; Thu, 31 Aug 89 17:25:23 EDT Received: by THANATOS.MIT.EDU (5.61/4.7) id AA00309; Thu, 31 Aug 89 17:24:43 -0400 Message-Id: <8908312124.AA00309@THANATOS.MIT.EDU> To: bgardner@ATHENA.MIT.EDU Subject: Initial comments on Argus spec. Date: Thu, 31 Aug 89 17:24:36 EDT I finished my first reading of the Argus design specification. For the most part I'm in the process of learning the concepts and structure that Argus presents, so I haven't too much feedback to give at this point, but one thing did grab my attention. The rule language seems weak, and though your intention is to hide it with a rule editor/browser, you will ultimately be limited by the weakness of the underlying language. One goal is to have a language which is simple and easily interpreted. I support these goals completely, but I think it could be much simpler and yet more powerful. One alternative would be to look at a function language syntactically similar to LISP and EDIFF. Here is a quick attempt to define such a language: function :: (function-name [arg [arg [arg] [...]]]) function-name :: identifier arg :: function | primary primary :: identifier | number | string string :: "identifier" Here is what the example in section 4.1.1 might look like, but remember that there is a lot of flexibility in how function protocols (names and arguments) are defined. (RuleSet (created 619398053) (updated 619398242) (Rule (created 619398053) (updated 619398242) (name SiftStaff) (if (or (contains "To:" "Staff@Athena" CaseInsensitive) (contains "cc:" "Staff@Athena" CaseInsensitive) ) ( (move-to 1) ) ) . . . ) ) There are a few advantages to this approach: (1) full recursion: nested conditionals, subfunctions, looping, macros, etc... would be difficult in the current language, but could be done trivially here. This is not to say that you would have to implement these things now or ever, only that you are free to do so if it becomes useful; (2) extensibility with compatibility: since everything is a function, old programs will always be as valid as new ones, even if new functions are defined. Extending the protocol of an existing function may also be possible, that depends on design of the function and its current protocol, but not on the language; (3) separation of form and function: the form is simple, almost trivial, but functions could be arbitrarily complex; (4) you will need a more complete language if, in the future, you want to intermessage processing. Let me know if this is of interest to you and whether I can be helpful in further investigation.  1,, Summary-line: 1-Sep djf@ATHENA.MIT.EDU #meeting report: graphics for the Cray Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25405; Fri, 1 Sep 89 13:43:38 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08340; Fri, 1 Sep 89 13:43:13 EDT Received: by LEO.MIT.EDU (5.61/4.7) id AA13095; Fri, 1 Sep 89 13:42:31 -0400 Date: Fri, 1 Sep 89 13:42:31 -0400 Message-Id: <8909011742.AA13095@LEO.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: meeting report: graphics for the Cray *** EOOH *** From: Date: Fri, 1 Sep 89 13:42:31 -0400 To: staff@ATHENA.MIT.EDU Subject: meeting report: graphics for the Cray This is a somewhat scatterbrained meeting report. I'd be happy to talk about the issues with anyone. -- David Flanagan ---------------------------------------------------------------------- MEETING REPORT Graphics for the Cray I attended a meeting with Prof. Bob Brown of Chem. E., and head (I think) of the Supercomputer Facility, and Tony Patera, who also has something to do with the cray (though I don't know for sure what). They were having sales reps from 2 high end graphics software firms in. I was there mostly as an observer representing Athena. Some background: Bob emphasises that we have a supercomputer Facility, not a supercomputer Center as other sites have. ("Don't use the 'C' word, use th 'F' word.") What this means is that there is no terminial room with graphics display hardware. Computing at MIT does not radiate out from the Cray, the Cray is just one node in the network. Bob claims that CPU hours on the Cray are so cheap ($125/hr) precisely because it can sit on the network without the overhead of a buiding and staff and simply live in a small room with an air conditioner. What they are looking for is a callable library of high end graphics routines, as well as some presentation graphics capabilities. Contour plots are a big part of what they want. The cray might directly drive X displays, but they are waiting to see if that is feasable with our network bandwidths. What they are more interested in currently is having the Cray produce a compact intermediate format ("Metafile"). The workstation would then run a metafile to X converter. This approach clearly limits severly the interactivity of the graphics, but that is acceptable. Bob and Tony wanted to buy a single CPU license for the graphics package, and a site license for whatever converters were to be used on the workstations. The packages being offered were DI-3000 XPM from Precision Visuals, and CA-DISSPLA from Computer Associates. Both are big Fortran beasts from the late 70's / early 80's. Apparently, these two are the industry leaders. As far as Bob was concerned the packages are functionally equivalent -- he was interested in finding out if they could be made to work in MIT's environment. This setup was confusing to the salesmen who arrived. They were prepared to brag about the hundreds of device drivers they had available, but when they heard that what was wanted was an X and a Postscript driver, one said "Well, we have a DECWindows driver". The other hadn't even heard of X. I emphasized that any metafile to X converter that would run on workstations would have to be very portable to Athena's current and future platforms, as well as VMS installations around MIT. I suggested that we would have to perform some sort of techincal review for portablilty of their driver. I hinted that they would have to rewrite their Fortran in C, that we would want the source, and that we could probably provide a workstation for a week or two for someone if they wanted to come work here. It remains to be seen whether either vendor will come through. If they do and deliver acceptable quotes, Bob will get them to do a demo in our environment. Neither Bob nor Tony were happy about having to buy a big out of date Fortran graphics package, but it seems that it is just about the only game in town. They want to license it on a yearly lease basis, with no initial lump sum payment, so that if something better comes along, they can quickly drop support for it. The issue for us is what should Athena's relationship to all this be? The current plan is to simply use our workstations as display terminals. The support issues for maintaining a metafile to X converter won't be too bad. It would be nice if the same callable graphics library that was available on the Cray ran on our platforms. Then people could debug programs cheaply and only send them to the Cray when they work. The adavantages of a common graphics package/format are obvious. We don't want to deal with these jokers though -- we cannot affort the money or the support headache of the big Fortran packages. We could probably build HOOPS on the Cray (I volunteer if I get an account and free cpu time). This is probably worth doing, but HOOP doen't have the high end functionality needed and won't replace another package. It would also be nice if we could use our workstations to do more than just pre-computed graphics. If the Cray computes the numbers, we should have the ability to display those numbers in a reasonable way. We are moving in the right direction on this, with Jim Rees' plotting widget, and we should contine to go farther. If we do it well enough, Cray users should be easy to convice -- why should they pay for cpu time to display their data if they can do it as well on Athena?  1,, Summary-line: 2-Sep jbs@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02732; Sat, 2 Sep 89 21:23:10 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24753; Sat, 2 Sep 89 21:23:45 EDT Received: by M11-111-2.MIT.EDU (5.61/4.7) id AA02607; Sat, 2 Sep 89 21:23:02 -0400 Date: Sat, 2 Sep 89 21:23:02 -0400 Message-Id: <8909030123.AA02607@M11-111-2.MIT.EDU> To: rap@ATHENA.MIT.EDU *** EOOH *** From: Date: Sat, 2 Sep 89 21:23:02 -0400 To: rap@ATHENA.MIT.EDU Did you get my email? Did you get my check? Give me a call and let me know what is doing. I can tell you all about Salomon Brothers. Jeffrey 212 744-3846  1,, Summary-line: 5-Sep djf@ATHENA.MIT.EDU #HP's proposed 1.1 widget enhancements Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01518; Tue, 5 Sep 89 11:44:32 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19078; Tue, 5 Sep 89 11:44:49 EDT Received: by LEO.MIT.EDU (5.61/4.7) id AA05971; Tue, 5 Sep 89 11:43:57 -0400 Date: Tue, 5 Sep 89 11:43:57 -0400 Message-Id: <8909051543.AA05971@LEO.MIT.EDU> To: uec-comment@osf.org Cc: motif@ATHENA.MIT.EDU Subject: HP's proposed 1.1 widget enhancements *** EOOH *** From: Date: Tue, 5 Sep 89 11:43:57 -0400 To: uec-comment@osf.org Cc: motif@ATHENA.MIT.EDU Subject: HP's proposed 1.1 widget enhancements The single line text widget and simplified menus described in HP's proposal for Motif 1.1 will be of great use to programmers. Equally important, but not mentioned in that proposal are enhancements to the list widget. Currently the multiple selection callbacks of a list widget return an array of the selected compound strings. In a widget that displays the headers of mail messages, for example, the content of the string is not particularly useful. Instead, the position in the list is desired. This functionality is avalable for single selections, but not multiple. In order to get a list widget to do useful things with multiple selections, the programmer is often forced to do awkward and inefficient string comparisons. Adding this functionality will require backwards compatible API changes, but I feel it should be a high priority. David Flanagan office: MIT E40-331 Systems Programmer phone: 617 253-0169 Project Athena E-mail: djf@athena.mit.edu  1,, Summary-line: 5-Sep djf@ATHENA.MIT.EDU #[dana@hpcvxdel.hp.com: Motif 1.1 proposal] Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01539; Tue, 5 Sep 89 11:45:03 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19089; Tue, 5 Sep 89 11:45:04 EDT Received: by LEO.MIT.EDU (5.61/4.7) id AA05974; Tue, 5 Sep 89 11:44:08 -0400 Date: Tue, 5 Sep 89 11:44:08 -0400 Message-Id: <8909051544.AA05974@LEO.MIT.EDU> To: motif@ATHENA.MIT.EDU Subject: [dana@hpcvxdel.hp.com: Motif 1.1 proposal] *** EOOH *** From: Date: Tue, 5 Sep 89 11:44:08 -0400 To: motif@ATHENA.MIT.EDU Subject: [dana@hpcvxdel.hp.com: Motif 1.1 proposal] ------- Forwarded Message To: uec-comment@osf.org, motif-talk@osf.org Cc: bob_group@hpcvlx.hp.com, keith@hp-pcd.cv.hp.com Subject: Motif 1.1 proposal X-Mailer: mh6.5 Date: Fri, 01 Sep 89 09:18:45 PDT From: dana@hpcvxdel.hp.com Sender: uec-comment-request@osf.osf.org HP PROPOSAL FOR MOTIF 1.1 As members of OSF, and as the implementors of Motif 1.0, we at Hewlett-Packard offer this proposal for the next version of the Open Software Foundation User Environment Component. GOALS FOR MOTIF 1.1 The next release of Motif should provide significant improvements to the Motif toolkit, but without modifying the existing Motif API. Limited new functionality should be included in a few key areas. These are our primary goals for Motif 1.1 (regardless of who does the actual implementation): Stability and Conformance. Identify and correct discrepancies between the library, specifications and documenatation. Consider changes which facilitate Motif Style Guide conformance. Backwards compatibility with Motif 1.0 is a must. Improved Performance. Identify and implement modifications to existing widgets and the intrinsics which improve speed, reduce data space or code size. Investigate and possibly implement a few carefully selected new components that offer substantial performance improvements. SUMMARY This list of objectives summarizes our proposal for Motif 1.1. - convert to R4 Xt Intrinsics - use vanilla R4 Xt Intrinsics - reduce space for resolution independent data - improve performance for single line text input - improve performance for simple popup and pulldown menus - improve general space and time performance - facilitate conformance with the Motif Style Guide - improve the visual appearance of Motif - make the Motif widgets more consistent - improve error handling - add new features which are upwardly compatible with Motif 1.0 - manage multiple screens with a single window manager process INTRINSICS Problem: The Motif widgets and window manager depend on Intrinsics features which have changed or are new in R4. Objective: Convert to R4 Xt Intrinsics. Solution: Contribute to the implementation and verification of new and changed intrinsics features required for Motif. - Motif features incorporated with modifications (passive grabs, gadget focus, Shell geometry) - complete support for multiple displays - ICCCM compliance for Shells and selection manager - convert Motif cut & paste code to use standard intrinsics selections and compound text interchange format - add "layout if no resize" logic to SetValuesAlmost of Managers - update Mwm to R4 Problem: Motif depends on a special version of the intrinsics. Objective: Use vanilla R4 Xt Intrinsics. Solution: Move special code to Xm library and eliminate other dependencies. - add start-up hook by providing macro wrappers around Xt initialization functions - move WM_Protocols and VendorShell stuff to Xm - change Position and Dimension back to shorts (see next section) RESOLUTION INDEPENDENCE Problem: Currently Position and Dimension are ints instead of shorts in order to have sufficient space for resolution independent data before in-place conversion to pixels. This requires additional data space and is another reason why Motif requires a special version of the Xt Intrinsics. Another problem is that it is possible for changes to be ignored in SetValues (if identical to current value in pixels) since the arglist is not available. Objective: Reduce space for resolution independent data. Solution: Rework resolution independence to save space and eliminate the need for special Xt Intrinsics. - change Position and Dimension back to shorts - change dimensional resources currently declared as shorts (margins, highlight and shadow thickness, etc.) back to Dimension - convert resolution independent resources directly from arglist in Initialize and SetValues (arglists are passed to these functions in R4) - since arglists used, the incorrect no change problem is fixed NEW WIDGETS Problem: The XmText widget is a powerful, versatile widget with very large overhead. Typical applications employ a substantial proportion of widgets for single line input of alphanumeric data (in forms, property sheets, tables, etc.). Although only a small fraction of XmText functionality is required, the expensive, general XmText widget must be used. Such applications pay a large penalty in time and space performance for unused functionality. Objective: Improve performance for single line text input. Solution: Add a new, simpler, optimized, high performance text input gadget - XmTextGadget. - limit functionality to single line input of simple text - consider optional label, since often used with label above or left - requires enhancement to Manager to support gadget keyboard input - use new text gadget in dialogs (XmSelectionBox, XmCommand) Problem: The menu system is powerful and versatile, but requires many widgets. As a result, applications which only require simple menus pay time and space penalties for unused menu functionality. and are complicated to program. Objective: Improve performance for simple popup and pulldown menus. Solution: Add a new, simpler, optimized, high performance menu widget - XmMenuPane. - limit functionality to single level text menus - adapt multiple compound string management from XmList. - support accelerators and mnemonics PERFORMANCE Problem: Because of interreferences in the code, even very small applications end up linking in most of the Xm library. Code size is also increased by redundant implementations of comparable functionality. Under certain conditions runtime performance would be improved by avoiding unnecessary execution of code. Objective: Improve general space and time performance. Solution: Rework implementation to improve performance. - investigate breaking apart menu system - consider fast popup/popdown of dialogs (XmDialogShell) - eliminate unnecessary redisplay by reworking Resize and SetValues (XmLabel, XmLabelGadget) and changing bit gravity to NW (XmRowColumn) - consider shared menu hierarchies (XmMenuShell, XmRowColumn) - rework geometry management in dialog widgets to eliminate redundant implementation (XmMessageBox, XmSelectionBox) - redesign visual line table functions (XmText) - improve startup and runtime performance by speeding up subresource fetching, adding image caching, changing color usage (Mwm) MOTIF APPEARANCE AND BEHAVIOR Problem: Althought the Motif widget set generally embodies Presentation Manager behavior (as defined by the Motif Style Guide), a few widgets do not conform exactly to the style guide, and some behavior mandated by the style guide is difficult for applications to implement. Objective: Facilitate conformance with the Motif Style Guide. Solution: Implement enhancements which expand support for PM behavior (no API changes are necessary). - change mnemonics to be case insensitive (Keyboard Traversal) - provide modal behavior if window manager not Mwm (XmDialogShell) - add Enter and Escape actions for default selection and cancel; support extended deselection (XmList) - support dynamic modification of default button via traversal; arm and activate help button when selected from keyboard (XmMessageBox and XmSelectionBox) - allow sash manipulation from keyboard (XmPanedWindow) - allow mnemonics in MenuBar without meta modifier (XmRowColumn) - add Next and Prev actions for page increment and decrement (XmScrolledWindow) Problem: Under certain conditions there are visual inconsistencies or other visual problems. Objective: Improve the visual appearance of Motif. Solution: Implement these enhancements for visual improvements (no API changes are necessary). - compress multiple "." and ".." in filenames, or only show leaf nodes in list (XmFileSelectionBox) - add shadow drawing for 3-D frame (XmForm) - fix possible broken shadow conditions when children are clipped (XmRowColumn if MenuBar, XmBulletinBoard and subclasses) - force submenu visibility at edge of screen (XmRowColumn if OptionMenu) - adjust number of visible items in list based on height (XmSelectionBox, XmCommand) - widen shadow in diamond toggle indicator (XmToggleButton, XmToggleButtonGadget) NEW FEATURES Problem: Some features that should have been included in Motif 1.0 for consistency were not included. Other inconsistent features are currently undocumented. Objective: Make the Motif widgets more consistent. Solution: Implement missing features (API changes, if any, are upwardly compatible). - use consistent names for DialogShell parents created by dialog convenience functions, and document these names (XmBulletinBoard and subclasses) - add a resource for default position so that any Manager can be used as a dialog (XmDialogShell) - use translations instead of an event handler (XmDrawingArea) - implement QueryGeometry (XmForm, XmText); calculate initial size in ChangeManaged (XmForm) - build translations at creation (XmRowColumn) - allow initialization of indicator state (XmRowColumn as RadioBox) - see also the visual changes above Problem: Certain errors are not handled by widgets or the window manager. Objective: Improve error handling. Solution: Implement new features (API changes, if any, are upwardly compatible): - improve error handling (XmFileSelectionBox) - handle out-of-color errors (Mwm) Problem: Useful features are not implemented by Motif widgets, or are not accessible to applications. Objective: Add new features which are upwardly compatible with Motif 1.0. Solution: Implement new features (API changes, if any, are upwardly compatible). - provide public functions for automotic color generation - add "real application modal" as another alternative for dialogs (XmBulletinBoard, XmDialogShell, Mwm) - add a resource to control installation of accelerators (XmBulletinBoard) - add a resource to allow/disallow duplicates in history (XmCommand) - support constraints by widget name (XmForm) - add a bitmap mask resource for non-rectangular labels (XmLabel, XmLabelGadget) and corresponding resources to dialogs with labels (XmMessageBox, XmSelectionBox) - add a function to return the baseline of text (XmLabel, XmLabelGadget, XmText) - add functions to return position of item, add/delete multiple items, and to delete multiple items by position (XmList) - add a resource to allow zero-of-many or one-of-many (XmRowColumn as RadioBox) - provide finer granularity than pixel (XmScale) Problem: A different Mwm process is required for each screen managed by an X server. Objective: Manage multiple screens with a single window manager process. Solution: Implement support for multiple screens in Mwm. - rework data structures and algorithms for multiple screens Dana Laursen dana@hp-pcd.hplabs.com ------- End Forwarded Message  1,, Summary-line: 5-Sep mackay@ATHENA.MIT.EDU #Meeting, while Toby is still here Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02956; Tue, 5 Sep 89 13:29:58 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21168; Tue, 5 Sep 89 13:30:34 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00473; Tue, 5 Sep 89 13:29:41 -0400 Message-Id: <8909051729.AA00473@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Meeting, while Toby is still here Date: Tue, 05 Sep 89 13:29:38 EDT *** EOOH *** From: To: argus2@ATHENA.MIT.EDU Subject: Meeting, while Toby is still here Date: Tue, 05 Sep 89 13:29:38 EDT Hi. I've scheduled the small conference room for 3:00 tomorrow. This is Toby's last real day, so please try to be on time. We've got lots to cover. Thanks! Topics: Status on each part of the code Status on user study Comments about the spec Plans for next two weeks Documentation Demonstrations Code freeze Strategizing for design review Strategizing for subsequent work (?) Wendy  1,, Summary-line: 5-Sep mwmoor@ATHENA.MIT.EDU #New "Athena Basics" doc available for review Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03508; Tue, 5 Sep 89 14:04:28 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22219; Tue, 5 Sep 89 14:03:55 EDT Received: by CASSANDRA.MIT.EDU (5.61/4.7) id AA13438; Tue, 5 Sep 89 14:03:00 -0400 Message-Id: <8909051803.AA13438@CASSANDRA.MIT.EDU> To: staff@ATHENA.MIT.EDU From: Mark W. Moormans (Athena Documentation Staff) Subject: New "Athena Basics" doc available for review Date: Tue, 05 Sep 89 14:02:56 EDT Sender: mwmoor@ATHENA.MIT.EDU *** EOOH *** To: staff@ATHENA.MIT.EDU From: Mark W. Moormans (Athena Documentation Staff) Subject: New "Athena Basics" doc available for review Date: Tue, 05 Sep 89 14:02:56 EDT Sender: mwmoor@ATHENA.MIT.EDU There is a new "Athena Basics" doc, now titled "Getting Started on Athena", available for review to all interested parties. A copy of the entire document, in ascii, is available in /mit/mwmoor/doc/olh/getting_started. The help modules, from which it is comprised, have already been installed into olh, so you can also review them online. There are a few minor typos and word changes, but other than that any technical changes you may know of would be appreciated. I will be accepting comments for the next 2 days or so, after which it is important (due to the nature of the doc) to get it out asap to the new students. Please be prompt in reviewing it and sending your comments. Thanks for all your help. Cheers, Mark W. Moormans Athena User Services MIT Bldg E40-371 (253-0117)  1,, Summary-line: 6-Sep kcunning@ATHENA.MIT.EDU #What's in On-Line Help Now? Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13475; Wed, 6 Sep 89 12:25:53 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08640; Wed, 6 Sep 89 12:17:28 EDT Received: by E40-371-1.MIT.EDU (5.61/4.7) id AA15304; Wed, 6 Sep 89 12:16:32 -0400 Message-Id: <8909061616.AA15304@E40-371-1.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: tad_all@ATHENA.MIT.EDU Subject: What's in On-Line Help Now? Date: Wed, 06 Sep 89 12:16:25 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Cc: tad_all@ATHENA.MIT.EDU Subject: What's in On-Line Help Now? Date: Wed, 06 Sep 89 12:16:25 EDT The Athena On-Line Help (OLH) System is finally getting a little content put into it. Here's what's there now for you (just type "help" to get it): Documentation Browser -- Athena Documentation stuff Answers to common questions -- The olc Stock Answers Unix man pages -- Unix man page trees Search by Keyword -- (not very extensive yet) The Documentation Browser is Athena Documentation's branch. Here are the topic areas currently included: Getting Started -- the Getting Started on Athena document Text Processing/Emacs -- incorporates ALL previous athenadoc docs on Emacs Text Processing/Scribe -- currently incorporates MOST previous athenadoc docs on Scribe, will soon include ALL content Release Notes/Athena 6.3 -- the recent Athena 6.3 User Release Notes These documents are currently entirely ASCII (plain text), but we are working on an X-based interface that will support more sophisticated presentation. Many more documents are soon-to-come. We hope that the Documentation Browser branch of OLH will soon (within one or two weeks) entirely supersede the athenadoc locker. As new "documents" are incorporated, I'll let you know. Feel free to review any modules in the tree and give us your feedback (you can even use the "s" option of OLH to send a message to us!) --Kevin Cunningham Athena Documentation  1,,important, Summary-line: 6-Sep tinoue@ATHENA.MIT.EDU #Sayounara minasan, arigatou. (Bye for everyone, thank you) Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA19579; Wed, 6 Sep 89 19:28:38 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA17914; Wed, 6 Sep 89 19:28:21 EDT Received: by E40-334-1.MIT.EDU (5.61/4.7) id AA21312; Wed, 6 Sep 89 19:27:23 -0400 Message-Id: <8909062327.AA21312@E40-334-1.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Sayounara minasan, arigatou. (Bye for everyone, thank you) Date: Wed, 06 Sep 89 19:27:16 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Subject: Sayounara minasan, arigatou. (Bye for everyone, thank you) Date: Wed, 06 Sep 89 19:27:16 EDT Hi, everyone. Now I have to leave Athena very reluctantly. Thank you for everything. I return to Tokyo on Sept. the 7th. Although I could stay here in Boston only 9 months, I could enjoy a lot; especially, to have stayed and worked for Project Athena is absolutely my best memory here in the U.S. I was impressed with many things; I wish I could express my present feelings in English. I am very happy now. Actually, I am visiting Japan and after 2 or 3 weeks, I will be looking for an appartment house around Schenectady N.Y., for I am supposed to work for G.E. from October for 2 years. That town is only 3 or 3 and a half hours' drive from here. Hope to keep in touch. Here is T.I.'s information in Japan. real name : Takeshi Inoue apartment : Yokogawa dorm. 116 2-20-4 Nakacho Musashino-shi Tokyo, 180 Japan Tel 81(422)54-3978 : I will be here until the end of September Office : Yokogawa Electric Corp. CR&D 4.1 2-9-32 Nakacho Musashino-shi Tokyo, 180 Japan Tel 81(422)52-5556 e-mail : I have no e-mail account in Japan but you can send mails to my friend's address, i.e. kddlab!sjc.yokogawa.junet!ohno@uunet.UU.NET !! please send me e-mails!! Family's house: 821 Nakadawara Otawara-shi Tochigi-pref. , 324 Japan tel 81(287)22-2079 My family has been living here more than 200 years, and I think you can reach me even after 20 years...?? Never fail to see you again!! T.I.  1,, Summary-line: 6-Sep rap@ATHENA.MIT.EDU #Grrrrrrr... Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21195; Wed, 6 Sep 89 23:06:09 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21139; Wed, 6 Sep 89 23:06:51 EDT Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA02936; Wed, 6 Sep 89 23:05:55 -0400 Date: Wed, 6 Sep 89 23:05:55 -0400 Message-Id: <8909070305.AA02936@MORPHEUS.MIT.EDU> To: bgardner@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU In-Reply-To: 's message of Wed, 6 Sep 89 05:00:05 -0400 <8909060900.AA03419@PINK.MIT.EDU> Subject: Grrrrrrr... *** EOOH *** From: Date: Wed, 6 Sep 89 23:05:55 -0400 To: bgardner@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU In-Reply-To: 's message of Wed, 6 Sep 89 05:00:05 -0400 <8909060900.AA03419@PINK.MIT.EDU> Subject: Grrrrrrr... From: Date: Wed, 6 Sep 89 05:00:05 -0400 Ok, here a repeat of a previous message... "const char" is NOT okay to use !! Using PROTOTYPE() does NOT protect you from things like: extern const char * AlMsgType_get_name PROTOTYPE((AlMsgType)); The above line is not necessarily valid C code. It will compile under gcc, but not under cc (the normal unix compiler). I copied the above line from /afs/athena.mit.edu/astaff/project/argus/src/working/motif/include/MsgType.h -- Brian As per what we have been doing since the beginning, const should be defined on the compiler line to be nothing like: cc -Dconst= -o foo ... we did this because const is supported by some compilers and not by others, so the compiler line is the best place to deal with it. I hope you haven't been modifying the code by taking out the const's? Wouldn't it seem odd that the compilation would stop working just now even though those consts have been in there since last summer? I personally have never used the const functionality extensively but they are useful in some situations and can be VERY useful in traking down *hard* bugs. I therefore still think we should continue to use them. __Rich.  1,, Summary-line: 7-Sep janej@ATHENA.MIT.EDU #Updated Staff List Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA28739; Thu, 7 Sep 89 16:00:59 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04300; Thu, 7 Sep 89 16:00:20 EDT Received: by E40-337-1.MIT.EDU (5.61/4.7) id AA19947; Thu, 7 Sep 89 15:59:20 -0400 Message-Id: <8909071959.AA19947@E40-337-1.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: janej@ATHENA.MIT.EDU Subject: Updated Staff List Date: Thu, 07 Sep 89 15:59:18 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Cc: janej@ATHENA.MIT.EDU Subject: Updated Staff List Date: Thu, 07 Sep 89 15:59:18 EDT 7 September 1989 * denotes where change was made PROJECT ATHENA STAFF LIST Name Extension Room UserName Anderson, Beth 3-1333 E40-342D beth Arfman, Josina 3-0125 E40-323 josina Avril, Catherine 3-0194 E40-358F cavril Baron, Dennis 3-9393 E19-722 dennis Bean, Gary 3-0128 E40-341 garybean Belville, Sharon 3-8969 E40-338 belville Borthwick-Leslie, Andrew 3-0176 E40-379 aleslie Boutin, Paul 3-0146 E40-355 paul Bruce, Jim 3-3103 10-219 jdb Budzianowski, Roman 3-1308 E40-381 roman Carver, David 3-1506 E40-327 dcc Cattey, Bill 3-0140 E40-349 wdc Champine, George 3-0144 E40-367 champine Coppeto, Thomas 3-1369 E40-358C tjcoppet Correia, Connie 3-0118 E40-359A cc Cunningham, Kevin 3-0177 E40-371 kcunning Davis, Ben 3-0178 E40-353 davis Davis, Don 3-1409 E40-319 don Doherty, John 3-4121 11-226 jjdoher Dryfoos, Gary 3-0184 E40-342G dryfoo Dworkin, Paul 3-0124 E40-319 paulj Dyer, Stephen 3-0127 E40-342A dyer Fermann, Carla 3-0135 E40-338 carla Flanagan, David 3-0169 E40-331 djf Gardner, Brian 3-4277 E40-334 bgardner Garner, Robin 3-0116 E40-358A garner Geer, Dan 3-0155 E40-342F geer Gibson, Mary 3-0120 E40-358B mgibson Harward, Jud 3-7896 E40-381 jud Hodges, Matt 3-1913 E40-333 hodges Hoffmann, Ron 3-4101 E40-311A hoffmann Isgur, Lou 3-4121 11-226 larugsi Johnston, Jane 3-4478 E40-337 janej Karimeddiny, Moezeddin 3-0191 E40-359 moe Kevles, Beth 3-7812 E40-318 kevles Kohl, John 3-1510 E40-351 jtkohl Krikorian, David 3-8651 E40-358A dkk Kubiatowicz, John 3-0510 E40-342C kubitron LaVin, Anne 3-0115 E40-343A lavin Lefort, Lenny 3-6367 W91-102 len Liu, C.C. Aida 3-0101 E40-358D aida Mackay, Wendy 3-0171 E40-366 mackay McKie, Bob 3-5264 E40-329 mckie Melanson, Brian 3-0191 E40-359 bwmelans Mensch, Henry 3-0131 E40-379 henry Merritt, Shirley 3-1348 E40-391 shirl Michon, Brian 3-1528 E40-333 michon Mintz, Toby 3-1358 E40-321 thm Monsarrat, Jon 3-0189 E40-342area drwho Moormans, Mark 3-0117 E40-371 mwmoor Murman, Earll 3-1327 E40-391B murman 3-3284 33-217 Orcutt, Ron 3-1346 E40-391A orcutt Peisach, Ezra 3-0119 E40-321 epeisach Pito, Rich 3-4277 E40-334 rap Powell, Kim 3-1325 E40-358D kapowell Provost, Judith 3-4101 E40-311 judi Raeburn, Ken 3-0113 E40-318 raeburn Ralston, Peter 3-0121 E40-357 invent Rees, James 3-1325 E40-358D jnrees Rochlis, Jon 3-4101 E40-311B jon Roden, Peter 3-0147 E40-355 roden * Roodvoets, Kerry -- E40-391 kerry Rosenstein, Mark 3-1530 E40-331 mar Ryan, Leo 3-7046 W91-107 ljryan Sasnett, Russell 3-5292 E40-351 russ Schiller, Jeff 3-4101 E40-311B jis Schlusselberg, Evelyn 3-0693 E40-353area schluss Schmidt, Naomi 3-0170 E40-343A nschmidt Sommerfeld, Bill 3-0132 E40-342A wesommer Stewart, Jackie 3-5226 E40-339 jstewart Swick, Ralph 3-1506 E40-327 swick * Van Haren, Chris 3-0111 E40-343 vanharen Webster, Michael 3-0153 E40-353area webst Weeks, Carlton 3-0157 E40-359 carlton Zolot, Kenneth 3-4165 E40-342B kzolot Deleted from Staff List: Brandy Bechtel Ian Boardman Rob French Evelynn Hammonds Takeshi Inoue  1,, Summary-line: 8-Sep geer@ATHENA.MIT.EDU #re: XView Toolkit Source Available Now Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA12430; Fri, 8 Sep 89 17:20:38 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29687; Fri, 8 Sep 89 17:16:56 EDT Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA29726; Fri, 8 Sep 89 17:15:51 -0400 Message-Id: <8909082115.AA29726@E40-342F-2.MIT.EDU> To: sysdev@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: re: XView Toolkit Source Available Now Date: Fri, 08 Sep 89 17:15:49 EDT *** EOOH *** From: To: sysdev@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: re: XView Toolkit Source Available Now Date: Fri, 08 Sep 89 17:15:49 EDT will someone get an afs volume and put this in it. please ack to ``sysdev'' if you volunteer - we don't need three copies... --dan ------- Forwarded Message Date: Fri, 8 Sep 89 12:17:31 PDT From: rprobst@sun.com (Richard Probst) To: sun-spots@rice.edu, xpert@expo.lcs.mit.edu Subject: XView Toolkit Source Available Now Sun Microsystems is extremely proud to announce the public availability of the complete source for the XView toolkit, the OLWM window manager, a few sample XView applications, and a collection of commercial-quality Lucida bitmap fonts from Bigelow & Holmes. XView is an X toolkit based on the OPEN LOOK (tm) Graphical User Interface. XView's API is very similar to the API of the SunView toolkit; in practice, most SunView applications can be converted to XView in a few days, although some will take longer. Since there are more than 2000 SunView applications, we expect that releasing XView will immediately create a large base of X11 applications. OLWM is an ICCCM-compliant window manager, also based on the OPEN LOOK GUI. OLWM is a "stand-alone" window manager, not dependent on any toolkit code. We hope that OLWM will become the standard example of an ICCCM-compliant window manager in X11 R4. (Caution: OLWM is not a perfect example of ICCCM behavior yet. It will be.) Also available is the source to three useful applications and fifteen simple example programs. The three XView applications are clock, textedit, and cmdtool/shelltool (a terminal emulator). In addition, we are including a script that helps convert SunView programs to XView by flagging the application code that needs to be changed. The Bigelow & Holmes Lucida bitmap fonts are a collection of different type styles and point sizes in the Lucida typeface. In addition, XView uses "glyph fonts" to accelerate the painting of some OPEN LOOK GUI graphical elements, and these fonts are also being made available. Note that these glyph fonts must be added to your X11 R3 server in order to run XView applications. All of this source will be included in the X11 R4 release, available from MIT later this year (and you will not need to add the glyph fonts to the X11 R4 server). An ALPHA version of the source is available today from expo. Details are given below. A second machine is being arranged on the West Coast, and will be announced shortly. With licensed source products from Sun, source is usually not released until several months after a binary version of the product has shipped. The extra time is used to "clean up" the source for external consumption. In contrast, we are releasing an ALPHA version of XView and OLWM now, before the binary version of XView has shipped. We will continue to fix bugs and portability problems as we find them, and these changes will be made available periodically between now and the release of X11 R4. In particular, this version of XView source does not (ahem, -cough-) lint cleanly. This problem is only partly due to XView's extensive use of varargs. XView source will lint cleanly (with the exception of the varargs complaints) in time for the release of X11 R4. We are releasing an alpha version of the source at this time in order to promote OPEN LOOK, to increase the number of ports of XView ready when X11 R4 ships, and to encourage the notion that X toolkit source should be free. We will update this free source to track changes that Sun makes in XView, including bug fixes, performance improvements, and new features. This is not a one-time "snapshot"; Sun has selected the MIT X11 distribution as our XView source distribution channel. Sun has implemented XView on four architectures: Sun4, Sun3, Sun386i, and DECstation 3100. In addition, there are about a dozen ports under way by other hardware vendors or third-party software vendors. In some cases, Sun is paying for the port and will own the rights to any code changes; we will give these changes away. In other cases, vendors will sell XView on a particular hardware or OS base; obviously, their changes are their added value. We encourage both uses of this source donation. If you discover bugs in XView or OLWM, or if you port them and discover portability problems that you are willing to fix for the X community, please send your bug reports to xviewbugs@sun.com (...!sun!xviewbugs). Bug reports with suggested fixes are obviously the best sort. We will use xviewbugs@sun.com to try to make XView and OLWM as bug-free and portable as possible in time for X11 R4. Open discussion about XView or OLWM ("Anybody figure out how to... ?") should occur on xpert@expo.lcs.mit.edu (or comp.windows.x). We will answer questions of general interest as time permits. Please do not send questions to xviewbugs@sun.com; that is only for bug reports. XView and OLWM are available now via anonymous ftp to expo.lcs.mit.edu in the directory /contrib/XView/ XView.tar.Z libraries, documents, examples, fonts (compressed) --OR the above broken into 8 parts-- XView.tar.1.Z Part 1 of 8, subset of XView.tar.Z (compressed) XView.tar.2.Z Part 2 of 8, subset of XView.tar.Z (compressed) XView.tar.3.Z Part 3 of 8, subset of XView.tar.Z (compressed) XView.tar.4.Z Part 4 of 8, subset of XView.tar.Z (compressed) XView.tar.5.Z Part 5 of 8, subset of XView.tar.Z (compressed) XView.tar.6.Z Part 6 of 8, subset of XView.tar.Z (compressed) XView.tar.7.Z Part 7 of 8, subset of XView.tar.Z (compressed) XView.tar.8.Z Part 8 of 8, subset of XView.tar.Z (compressed) XViewConversion.tar.Z script to help convert SunView programs olwm.tar.Z OLWM Window Manager (compressed) When uncompressed from the tar files, there will be approximately 8.3Mb of toolkit code, examples, fonts and documentation. OLWM will be less than 1Mb. The compressed XView tar file is a single 2.8Mb file (or eight ~500Kb files). The compressed OLWM tar file is a ~100Kb file. Documentation on XView, in PostScript source format, is included in the XView tar file. There are two documents, called XView 1.0 Reference Manual: Summary of the XView API XView 1.0 Reference Manual: Converting SunView Applications Pre-printed versions of these manuals may also be ordered (at the cost of media and shipping) from Sun Microsystems by ordering Part Numbers 800-2482-10 and 800-2483-10. In addition, a comprehensive programmer's reference manual for XView is being prepared by O'Reilly & Associates, Inc. Contact O'Reilly & Associates, Inc. directly to order the XView Programming Manual O'Reilly & Associates, Inc. 632 Petaluma Avenue Sebastopol, CA 95472 (800)338-6887 EMAIL: uunet!ora!xview XView requires the use of an ICCCM-compliant window manager, such as OLWM. Further, XView requires full ICCCM support in Xlib. This will be standard in X11 R4. In order to run with an X11 R3 version of Xlib, you must define the PRE_R4_ICCCM compile-time flag when you compile XView. To build XView, you must also have the X Window System source. XView requires standard utilities from the X Window System source tree, such as imake, bdftosnf, and mkfontdir. Please direct comments or questions about this source donation to xpert@expo.lcs.mit.edu (or comp.windows.x). And thank you for your support. --Richard Probst (rprobst@sun.com) ------- End of Forwarded Message  1,, Summary-line: 10-Sep mackay@ATHENA.MIT.EDU #Missing Toby Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA26153; Sun, 10 Sep 89 21:31:24 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07041; Sun, 10 Sep 89 21:32:12 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00665; Sun, 10 Sep 89 21:30:59 -0400 Message-Id: <8909110130.AA00665@E40-368-1.MIT.EDU> To: rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU Cc: mackay@ATHENA.MIT.EDU Subject: Missing Toby Date: Sun, 10 Sep 89 21:30:57 EDT *** EOOH *** From: To: rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU Cc: mackay@ATHENA.MIT.EDU Subject: Missing Toby Date: Sun, 10 Sep 89 21:30:57 EDT Rich and Brian, I met with Toby today... You both seem to have forgotten the meeting. He's off to Paris and left an address. Let's try to meet on Tuesday -- this should really be crunch time to get this software out. Will you both be done by Friday? Wendy  1,, Summary-line: 11-Sep jtkohl@ATHENA.MIT.EDU #Re: afs and nfs lockers Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA29677; Mon, 11 Sep 89 10:27:05 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15883; Mon, 11 Sep 89 10:27:53 EDT Received: by LYCUS.MIT.EDU (5.61/4.7) id AA25888; Mon, 11 Sep 89 10:26:44 -0400 Date: Mon, 11 Sep 89 10:26:44 -0400 From: John T Kohl Message-Id: <8909111426.AA25888@LYCUS.MIT.EDU> To: Cc: argus2@ATHENA.MIT.EDU In-Reply-To: Wendy E. Mackay's message of Sun, 10 Sep 89 21:28:23 EDT, <8909110128.AA00654@E40-368-1.MIT.EDU> Subject: Re: afs and nfs lockers X-Us-Snail: MIT Room E40-351, 1 Amherst St., Cambridge, MA 02139 USA *** EOOH *** Date: Mon, 11 Sep 89 10:26:44 -0400 From: John T Kohl To: Cc: argus2@ATHENA.MIT.EDU In-Reply-To: Wendy E. Mackay's message of Sun, 10 Sep 89 21:28:23 EDT, <8909110128.AA00654@E40-368-1.MIT.EDU> Subject: Re: afs and nfs lockers X-Us-Snail: MIT Room E40-351, 1 Amherst St., Cambridge, MA 02139 USA It's hard to debug without information as to the error messages involved. If you have some sort of protections on your directories, such that only certain users can read/list/run programs there, then you need to make sure that the user is registered with AFS [not all Athena users are yet registered; send mail to 'afsreq' with the names of people who aren't registered, asking them to be registered]. To check if a user is registered, type /afs/athena/system/afsuser/@sys/prs check If it prints out something like "User or group doesn't exist" then you need to be registered with AFS. If the user is registered, but they still don't have access, they may need to authenticate to the AFS cell, by typing nfsid -cell athena.mit.edu If the problem is not related to permissions, something else may be screwy. John  1,, Summary-line: 11-Sep bgardner@ATHENA.MIT.EDU #help documentation Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06104; Mon, 11 Sep 89 16:21:06 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA25255; Mon, 11 Sep 89 16:22:00 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA01446; Mon, 11 Sep 89 16:20:51 -0400 Date: Mon, 11 Sep 89 16:20:51 -0400 Message-Id: <8909112020.AA01446@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: help documentation *** EOOH *** From: Date: Mon, 11 Sep 89 16:20:51 -0400 To: argus2@ATHENA.MIT.EDU Subject: help documentation The style guide for the command line switch options, objects, arguments and other -help info formating, is now in: /afs/athena.mit.edu/astaff/project/argus/doc/programmers.guide/help_command.mss and /afs/athena.mit.edu/astaff/project/argus/doc/programmers.guide/help_command.PS This "may" have some additional programming/function definition type stuff added soon. But it is complete enough in its current state. Of course, help.h can be found in: /afs/athena/astaff/project/argus/src/working/motif/include/help.h and helpc can be found in: /afs/athena/astaff/project/argus/src/working/src/help.c along with the binary help.o file. The help.h file is well documented, and includes an example. -- Brian  1,, Summary-line: 11-Sep tower@CS.BU.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08450; Mon, 11 Sep 89 19:00:55 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28982; Mon, 11 Sep 89 19:01:53 EDT Received: by CS.BU.EDU (5.58/4.7) id AA12085; Mon, 11 Sep 89 19:01:21 EDT Date: Mon, 11 Sep 89 19:01:21 EDT From: tower@CS.BU.EDU (Leonard H. Tower Jr.) Message-Id: <8909112301.AA12085@CS.BU.EDU> To: aps@cs.bu.edu, mds@cs.bu.edu, sciore@cs.bu.edu, alpert@cs.bu.edu, york@cs.bu.edu, rwd@cs.bu.edu, gene@cs.bu.edu, robotron@cs.bu.edu, hoffer@cs.bu.edu, susskind@cs.bu.edu, yates@cs.bu.edu, rap@cs.bu.edu, gale@cs.bu.edu, lynch@cs.bu.edu, maurice@cs.bu.edu, raymond@cs.bu.edu, cesar@cs.bu.edu, composer@cs.bu.edu, wehrli@cs.bu.edu, tamale@cs.bu.edu, tak@cs.bu.edu, chungf@cs.bu.edu, atkins@cs.bu.edu, joshua5@cs.bu.edu, dermer@cs.bu.edu, pravin@cs.bu.edu, carter@cs.bu.edu, cobra@cs.bu.edu, adb@cs.bu.edu, connell@cs.bu.edu, ebraude@cs.bu.edu, anne@cs.bu.edu, tiuryn@cs.bu.edu, ven@cs.bu.edu, tasos@cs.bu.edu Cc: bugs@CS.BU.EDU, mer@CS.BU.EDU In-Reply-To: Ra's message of Mon, 11 Sep 89 00:22:09 EDT <8909110422.AA14908@CS\ *** EOOH *** Date: Mon, 11 Sep 89 19:01:21 EDT From: tower@CS.BU.EDU (Leonard H. Tower Jr.) To: aps@cs.bu.edu, mds@cs.bu.edu, sciore@cs.bu.edu, alpert@cs.bu.edu, york@cs.bu.edu, rwd@cs.bu.edu, gene@cs.bu.edu, robotron@cs.bu.edu, hoffer@cs.bu.edu, susskind@cs.bu.edu, yates@cs.bu.edu, rap@cs.bu.edu, gale@cs.bu.edu, lynch@cs.bu.edu, maurice@cs.bu.edu, raymond@cs.bu.edu, cesar@cs.bu.edu, composer@cs.bu.edu, wehrli@cs.bu.edu, tamale@cs.bu.edu, tak@cs.bu.edu, chungf@cs.bu.edu, atkins@cs.bu.edu, joshua5@cs.bu.edu, dermer@cs.bu.edu, pravin@cs.bu.edu, carter@cs.bu.edu, cobra@cs.bu.edu, adb@cs.bu.edu, connell@cs.bu.edu, ebraude@cs.bu.edu, anne@cs.bu.edu, tiuryn@cs.bu.edu, ven@cs.bu.edu, tasos@cs.bu.edu Cc: bugs@CS.BU.EDU, mer@CS.BU.EDU In-Reply-To: Ra's message of Mon, 11 Sep 89 00:22:09 EDT <8909110422.AA14908@CS\ .BU.EDU> Subject: bu-cs disks Date: Mon, 11 Sep 89 00:22:09 EDT From: root@CS.BU.EDU (Ra) /usr16 is 99 percent full (1410 free) Please clean up unneeded files under your home directory. The file system you home directory is on is about to overflow. thanx -len  1,, Summary-line: 11-Sep tower@CS.BU.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08465; Mon, 11 Sep 89 19:03:27 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29022; Mon, 11 Sep 89 19:04:25 EDT Received: by CS.BU.EDU (5.58/4.7) id AA12163; Mon, 11 Sep 89 19:03:30 EDT Date: Mon, 11 Sep 89 19:03:30 EDT From: tower@CS.BU.EDU (Leonard H. Tower Jr.) Message-Id: <8909112303.AA12163@CS.BU.EDU> To: aps@cs.bu.edu, mds@cs.bu.edu, sciore@cs.bu.edu, alpert@cs.bu.edu, york@cs.bu.edu, rwd@cs.bu.edu, gene@cs.bu.edu, robotron@cs.bu.edu, hoffer@cs.bu.edu, susskind@cs.bu.edu, yates@cs.bu.edu, rap@cs.bu.edu, gale@cs.bu.edu, lynch@cs.bu.edu, maurice@cs.bu.edu, raymond@cs.bu.edu, cesar@cs.bu.edu, composer@cs.bu.edu, wehrli@cs.bu.edu, tamale@cs.bu.edu, tak@cs.bu.edu, chungf@cs.bu.edu, atkins@cs.bu.edu, joshua5@cs.bu.edu, dermer@cs.bu.edu, pravin@cs.bu.edu, carter@cs.bu.edu, cobra@cs.bu.edu, adb@cs.bu.edu, connell@cs.bu.edu, ebraude@cs.bu.edu, anne@cs.bu.edu, tiuryn@cs.bu.edu, ven@cs.bu.edu, tasos@cs.bu.edu Cc: bugs@CS.BU.EDU, mer@CS.BU.EDU In-Reply-To: Ra's message of Mon, 11 Sep 89 00:22:09 EDT <8909110422.AA14908@CS\ *** EOOH *** Date: Mon, 11 Sep 89 19:03:30 EDT From: tower@CS.BU.EDU (Leonard H. Tower Jr.) To: aps@cs.bu.edu, mds@cs.bu.edu, sciore@cs.bu.edu, alpert@cs.bu.edu, york@cs.bu.edu, rwd@cs.bu.edu, gene@cs.bu.edu, robotron@cs.bu.edu, hoffer@cs.bu.edu, susskind@cs.bu.edu, yates@cs.bu.edu, rap@cs.bu.edu, gale@cs.bu.edu, lynch@cs.bu.edu, maurice@cs.bu.edu, raymond@cs.bu.edu, cesar@cs.bu.edu, composer@cs.bu.edu, wehrli@cs.bu.edu, tamale@cs.bu.edu, tak@cs.bu.edu, chungf@cs.bu.edu, atkins@cs.bu.edu, joshua5@cs.bu.edu, dermer@cs.bu.edu, pravin@cs.bu.edu, carter@cs.bu.edu, cobra@cs.bu.edu, adb@cs.bu.edu, connell@cs.bu.edu, ebraude@cs.bu.edu, anne@cs.bu.edu, tiuryn@cs.bu.edu, ven@cs.bu.edu, tasos@cs.bu.edu Cc: bugs@CS.BU.EDU, mer@CS.BU.EDU In-Reply-To: Ra's message of Mon, 11 Sep 89 00:22:09 EDT <8909110422.AA14908@CS\ .BU.EDU> Subject: bu-cs disks Date: Mon, 11 Sep 89 00:22:09 EDT From: root@CS.BU.EDU (Ra) /usr16 is 99 percent full (1410 free) Please clean up unneeded files under your home directory. The file system your home directory is on is about to overflow. thanx -len  1,, Summary-line: 11-Sep ilham@ATHENA.MIT.EDU #lpd-palladium gateway on Calvin Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09543; Mon, 11 Sep 89 20:50:26 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01249; Mon, 11 Sep 89 20:50:20 EDT Received: by GARFIELD.MIT.EDU (5.61/4.7) id AA00736; Mon, 11 Sep 89 20:49:08 -0400 Date: Mon, 11 Sep 89 20:49:08 -0400 Message-Id: <8909120049.AA00736@GARFIELD.MIT.EDU> From: Ilhamuddin Ahmed Sender: ilham@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Cc: geer@ATHENA.MIT.EDU, pss-dev@ATHENA.MIT.EDU, ilham@ATHENA.MIT.EDU Subject: lpd-palladium gateway on Calvin Reply-To: ilham@ATHENA.MIT.EDU Us.Snail: 211 Walcott, 3 Ames St. Cambridge, MA 02139 (617)-225-6256 *** EOOH *** Date: Mon, 11 Sep 89 20:49:08 -0400 From: Ilhamuddin Ahmed Sender: ilham@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Cc: geer@ATHENA.MIT.EDU, pss-dev@ATHENA.MIT.EDU, ilham@ATHENA.MIT.EDU Subject: lpd-palladium gateway on Calvin Reply-To: ilham@ATHENA.MIT.EDU Us.Snail: 211 Walcott, 3 Ames St. Cambridge, MA 02139 (617)-225-6256 The lpd-palladium gateway has been installed on calvin (the printer in between the watchmaker and consultant area). To try this, do : lpr -Pcalvin filename This will queue your job to the *palladium* printer named (coincidentally) calvin. You can also query all jobs by doing : lpq -Pcalvin This will return sometime like : HOBBES.MIT.EDU... "calvin" is actually a Palladium logical printer "calvin" Service provider = ravs No Jobs You can also remove jobs by first doing a lpq (and noting the Local Job Id) and then by issuing an : lprm -Pcalvin jobno Please note that the gateway will not be the primary means of printing to Palladium but rather for use in the transition from the Berkeley spooler to the Palladium Print system so please also keep using pdpr and Co. Also not all the arguments to lpr, lpq and lprm will not work. All that is being provided is the bare essentials necessary to print from Berkeley spooler to a palladium server. Please try it out and send me mail if you find any problems with it. - Ilham Ahmed Athena Watchmaker  1,, Summary-line: 12-Sep orcutt@ATHENA.MIT.EDU #Visitor Center Use Guidelines Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13441; Tue, 12 Sep 89 09:52:09 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10406; Tue, 12 Sep 89 09:51:26 EDT Received: by E40-391A-2.MIT.EDU (5.61/4.7) id AA20260; Tue, 12 Sep 89 09:50:15 -0400 Message-Id: <8909121350.AA20260@E40-391A-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Visitor Center Use Guidelines Date: Tue, 12 Sep 89 09:50:10 EDT From: Ronald L. Orcutt *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: Visitor Center Use Guidelines Date: Tue, 12 Sep 89 09:50:10 EDT From: Ronald L. Orcutt Folks, The purposes of the Visitor Center in E40 are to disseminate knowledge about Project Athena's goals, results, etc. throughout higher education and industry, and to facilitate the Project's discussions with potential sponsors through demonstrations. Other uses are secondary and must not unduly interfere with the Center's main functions. Secondary uses include development, live video presentations, et. al. Occasionally other uses have interfered with following visits. A few groundrules should suffice to allow everyone to use the Center's facilities effectively. So . . . 1. Catherine Avril manages the Center and is responsible for its main functions. If you want to use the Center, please make sure she both knows and OK's your use in advance. She's adept at juggling many visitors, and should be able to fit you in with advanced notice. 2. In case advanced notice and approval are not possible, please inform Catherine that you've used the Center. It's particularly important to alert Catherine to your consumption of the many documents we hand out to visitors, and if any are running low. 3. Please restore the Center to proper working condition when you're done. This applies not only to the computer and projection equipment, but also to a locker outer door, grow lights on the plants, all projectors powered off. 4. Working equipment -- including all demonstration software -- should be treated with the same care as courseware applications in the field. If you're doing work that will break demonstrations (including video development, system upgrades, scheduled server outages), please notify and work with Catherine so that she can reschedule demos, test new software, etc. I believe these guidelines are reasonable and workable in our environment. I'd be happy to discuss them or receive suggestions for improving them. -- Ron  1,, Summary-line: 12-Sep jik@ATHENA.MIT.EDU #new versions of delete software Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17482; Tue, 12 Sep 89 14:04:34 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16718; Tue, 12 Sep 89 14:03:23 EDT Received: by VULCAN.MIT.EDU (5.61/4.7) id AA23583; Tue, 12 Sep 89 14:02:08 -0400 Date: Tue, 12 Sep 89 14:02:08 -0400 Message-Id: <8909121802.AA23583@VULCAN.MIT.EDU> From: Jonathan I. Kamens Sender: jik@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: new versions of delete software *** EOOH *** Date: Tue, 12 Sep 89 14:02:08 -0400 From: Jonathan I. Kamens Sender: jik@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: new versions of delete software I am working on substantial revisions to the delete software for the next release. I really want the new versions to get severely banged on so any bugs in them come out before it is time for the release. As such, I would appreciate it if staff members who use delete and associated programs would use my new versions. They are located in /afs/athena/user/j/jik/{vax,rt,decmips}bin, so if you either add that to your path or alias delete, etc. to /afs/athena/user/j/jik/${hosttype}bin/{delete,undelete,etc} you will get the new versions. I will be periodically updating these versions. Any bug reports should go directly to me and now to bugs (or anywhere else, for that matter). Thank you for any help (and bug reports) you supply. jik P.S. You should find the new expunge, purge, undelete and lsdel much faster and more reliable than the release versions. They also do better error reporting.  1,answered,, Summary-line: 13-Sep hindus@media-lab.media.mi #AIDs walk check not cashed ... Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02697; Wed, 13 Sep 89 15:27:33 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA13489; Wed, 13 Sep 89 15:27:52 EDT Received: by media-lab (5.57/4.8) id AA04419; Wed, 13 Sep 89 15:25:50 EDT Date: Wed, 13 Sep 89 15:25:50 EDT From: Debby Hindus Message-Id: <8909131925.AA04419@media-lab> To: rap@ATHENA.MIT.EDU Subject: AIDs walk check not cashed ... *** EOOH *** Date: Wed, 13 Sep 89 15:25:50 EDT From: Debby Hindus To: rap@ATHENA.MIT.EDU Subject: AIDs walk check not cashed ... Hi, how was Italy? Do you know anything about that check? Thanks. - Debby  1,answered,, Summary-line: 13-Sep bgardner@ATHENA.MIT.EDU #New stuff isn't quite right somehow. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA07671; Wed, 13 Sep 89 21:42:02 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21243; Wed, 13 Sep 89 21:43:05 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA02070; Wed, 13 Sep 89 21:41:49 -0400 Date: Wed, 13 Sep 89 21:41:49 -0400 Message-Id: <8909140141.AA02070@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: New stuff isn't quite right somehow. *** EOOH *** From: Date: Wed, 13 Sep 89 21:41:49 -0400 To: rap@ATHENA.MIT.EDU Subject: New stuff isn't quite right somehow. When compiling my code, I got: rulebrowser.c: In function AlRsb_insert_callback: rulebrowser.c:702: warning: assignment of pointer from integer lacks a cast Undefined: _RE_debug1 _RapList_parse_into_darray *** Exit 1 Line number 702 reads: the_rule = AlRule_create_default_rule(); where the_rule is defined as: AlRule the_rule;  1,, Summary-line: 13-Sep murman@ATHENA.MIT.EDU #Special seminar on Monday Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09577; Thu, 14 Sep 89 02:50:28 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA14315; Wed, 13 Sep 89 16:04:33 EDT Received: by E40-391B-2.MIT.EDU (5.61/4.7) id AA00794; Wed, 13 Sep 89 16:02:20 -0400 Message-Id: <8909132002.AA00794@E40-391B-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: hollan@cogsci.ucsd.edu, malone@xv, mory@ATHENA.MIT.EDU, tfweiss@ATHENA.MIT.EDU Subject: Special seminar on Monday Date: Wed, 13 Sep 89 16:02:10 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Cc: hollan@cogsci.ucsd.edu, malone@xv, mory@ATHENA.MIT.EDU, tfweiss@ATHENA.MIT.EDU Subject: Special seminar on Monday Date: Wed, 13 Sep 89 16:02:10 EDT Interfaces As Languages and Metaphors Dr. Jim Hollan Department of Cognitive Sciences, University of California, San Diego Computers are the most plastic medium yet invented for the representation and propagation of information. They can mimic the behaviors of other information media and manifest behaviors not possible in any other media. They enable interactive representational systems of revolutionary consequence for mediation of our thoughts and actions. The epistemological, psychological, and technological consequences of this new plastic medium are of the utmost scientific importance. In this talk I draw upon experiences in the design of interface tools to support construction of interfaces to dynamic simulations and knowledge-based systems to argue for the central importance of metaphors and a language perspective for interface design. Date: September 18, 1989 Time: 4:30 pm Place: MIT, E40-498  1,, Summary-line: 14-Sep vanharen@ATHENA.MIT.EDU #MotifUtilities addition... Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13165; Thu, 14 Sep 89 12:14:44 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04927; Thu, 14 Sep 89 12:15:18 EDT Received: by FRIES.MIT.EDU (5.61/4.7) id AA01665; Thu, 14 Sep 89 12:13:52 -0400 Message-Id: <8909141613.AA01665@FRIES.MIT.EDU> To: motif@ATHENA.MIT.EDU From: Chris VanHaren Subject: MotifUtilities addition... Date: Thu, 14 Sep 89 12:13:49 EDT Sender: vanharen@ATHENA.MIT.EDU *** EOOH *** To: motif@ATHENA.MIT.EDU From: Chris VanHaren Subject: MotifUtilities addition... Date: Thu, 14 Sep 89 12:13:49 EDT Sender: vanharen@ATHENA.MIT.EDU I've added another function to the Mu library that Hyun-Ju started. It's basically the same as MuErrorSync and MuWarningSync, but it's called MuHelpSync. The only difference is that this is a synchronous version of an information dialog, for those times that you want the little "i" in the corner of the dialog box instead of the error bitmap or the warning bitmap. The documentation file ( /mit/motifdev/projects/util/document ) has been updated to include the information that follows. If there are any other convenience routines that anyone wants, let me know, and I'll add them if I have time. Thanks, Chris VanHaren ************************************************************************* void MuErrorSync(string) char *string void MuWarningSync(string) char *string void MuHelpSync(string) char *string MuWarningSync and MuErrorSync are synchronous versions of the MuWarning and MuError functions. MuHelpSync is similar to MuWarningSync and MuErrorSync, but not similar to MuHelp at all. MuHelpSync does not provide multiple help dialogs the way MuHelp does, it provides only one, synchronous dialog box the way that MuErrorSync and MuWarningSync do. They popup up and wait for the user to click on "OK" before continuing with the next line of code (which may well be "exit()"). This is accomplished by invoking a recursive copy of XtMainLoop inside of the utility routine and using longjmp() from the Ok callback to abort from the recursive copy. They are great for dealing with fatal errors and the like -- in the event of a fatal error where the user cannot continue the program, you can warn the person before taking down the program using MuErrorSync or MuWarningSync (the function will wait for the OK button, then exit or do whatever you want it to do).  1,, Summary-line: 14-Sep vanharen@ATHENA.MIT.EDU #bug with the scrolled list instance of the list widget. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22990; Thu, 14 Sep 89 23:57:33 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10858; Thu, 14 Sep 89 16:40:02 EDT Received: by FRIES.MIT.EDU (5.61/4.7) id AA01814; Thu, 14 Sep 89 16:37:56 -0400 Message-Id: <8909142037.AA01814@FRIES.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Subject: bug with the scrolled list instance of the list widget. Date: Thu, 14 Sep 89 16:37:53 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Subject: bug with the scrolled list instance of the list widget. Date: Thu, 14 Sep 89 16:37:53 EDT OSF UEC Problem Report ================================= Submitter Information --------------------- Submitter Name: Chris VanHaren Organization: MIT Project Athena Email Address: vanharen@athena.mit.edu Phone: (617) 253-0111 Hardware/Software Configuration ------------------------------- Offering and Version: Motif 1.0 Component (Module): Toolkit, Scrolled List, (Xm/List.c, I think) OSF License Number: - Client Hardware: DEC VS II/RC, 5Meg ram, 16Meg swap. Client Software: Unix 4.3BSD w/athena ext., X11r3 Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: pcc Problem Description ------------------- Severity Level: Minor -- represents a cosmetic type problem. Date of First Occurrence: 9/14/89 One Line Description: Scrolled List widget ignores the XmNscrollBarPlacement resource. Full Description: Apparently, the XmNscrollBarPlacement resource is ignored in the scrolled list widget. I attempted to set the value of this resource to XmBOTTOM_LEFT, but when the application runs, the vertical scrollbar appears on the right side. Repeat By: Create a scrolled list widget and attempt to put the scrollbars in some other place besides the bottom_right (default). Here are the attributes that I hvae set, in case there is some strange interaction going on that I missed. n=0; XtSetArg(args[n], XmNlistMarginWidth, NORMAL_SPACING); n++; XtSetArg(args[n], XmNlistMarginHeight, NORMAL_SPACING); n++; XtSetArg(args[n], XmNlistSpacing, NORMAL_SPACING); n++; XtSetArg(args[n], XmNselectionPolicy, XmSINGLE_SELECT); n++; XtSetArg(args[n], XmNscrollBarDisplayPolicy, XmAS_NEEDED); n++; XtSetArg(args[n], XmNscrollBarPlacement, XmBOTTOM_LEFT); n++; XtSetArg(args[n], XmNtopAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNleftAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNrightAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNbottomAttachment, XmATTACH_FORM); n++; w_list = XmCreateScrolledList(w_list_frame, "list", args, n); XtAddCallback(w_list, XmNsingleSelectionCallback, olc_topic_select, NULL); XtManageChild(w_list); Proposed Solution: From a quick glance at .../src/.../lib/Xm/List.c, it appears that XmNscrollBarPlacement was left out of the resources. I don't see that it is inherited from the Primitive or Core widgets, either. I don't know what all needs to be done in order to make it work...  0,unseen,, Summary-line: 14-Sep mgibson@ATHENA.MIT.EDU #Volunteers needed for the United Way Campaign Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24167; Fri, 15 Sep 89 02:06:51 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11582; Thu, 14 Sep 89 17:28:23 EDT Received: by E40-358B-2.MIT.EDU (5.61/4.7) id AA09110; Thu, 14 Sep 89 17:26:04 -0400 Message-Id: <8909142126.AA09110@E40-358B-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Volunteers needed for the United Way Campaign Date: Thu, 14 Sep 89 17:25:48 EDT We would like to ask for a volunteer for the position of "Chief Solicitor" within Project Athena for the United Way Campaign. If you feel that you would like to be involved in this year's campaign, please respond to me by Email. Thank you. Mary  1,, Summary-line: 15-Sep rap@ATHENA.MIT.EDU #ruleeditor Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27268; Fri, 15 Sep 89 11:25:35 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA26484; Fri, 15 Sep 89 11:26:19 EDT Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA07499; Fri, 15 Sep 89 11:24:44 -0400 Date: Fri, 15 Sep 89 11:24:44 -0400 Message-Id: <8909151524.AA07499@MORPHEUS.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: ruleeditor *** EOOH *** From: Date: Fri, 15 Sep 89 11:24:44 -0400 To: argus2@ATHENA.MIT.EDU Subject: ruleeditor is out. Unfortunately only the predicate part is 'complete'. Bang on it, It'll probably break. Anyway I spent all night tracking down insensible bugs which only appear on the rt. I hate computers(!!). Anyway, don't forget your two new profile components. Here are mine as an example FieldTypesThatShowOperators: Date, Any-Case-Text-with-commas-as-ORs EasyAccessFieldTypes: Any-Case-Text-with-commas-as-ORs, Date, Integer, Boolean and these appear in the system profile. I am going to recompile all the applications os they won't choke on the new profile but can't stay to watch them finish, so could somebody take the vax versions out of the src dir and put into 0.6/vax. Don;t mind rt for now. Well, I wish it were better, but I spent lots 'o time chasing bugs in motif or the rt or whatever. Anyway, the simple-complex button stuff isn't finished but it works. Delete is bound to Meta-d. The rest is all there. __Rich. I'll be in on saturday a bit and sunday.  1,, Summary-line: 15-Sep cavril@ATHENA.MIT.EDU #"Windows on Athena" book available to staff Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27954; Fri, 15 Sep 89 12:15:31 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27481; Fri, 15 Sep 89 12:13:17 EDT Received: by PANDORA.MIT.EDU (5.61/4.7) id AA13452; Fri, 15 Sep 89 12:11:43 -0400 Message-Id: <8909151611.AA13452@PANDORA.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: "Windows on Athena" book available to staff Date: Fri, 15 Sep 89 12:11:34 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Subject: "Windows on Athena" book available to staff Date: Fri, 15 Sep 89 12:11:34 EDT It's here! This collection of articles written by faculty members about Athena courseware has just come out. Single copies are available to staff members at this time. Pending our working out the details of distribution, we are not yet making these available outside Athena. Please see the secretary in Room 391 for your copy. Only one per person please.  1,, Summary-line: 15-Sep bgardner@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02496; Fri, 15 Sep 89 20:11:41 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA00871; Fri, 15 Sep 89 15:23:40 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA02978; Fri, 15 Sep 89 15:19:37 -0400 Date: Fri, 15 Sep 89 15:19:37 -0400 Message-Id: <8909151919.AA02978@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU *** EOOH *** From: Date: Fri, 15 Sep 89 15:19:37 -0400 To: rap@ATHENA.MIT.EDU (Message inbox:129) Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21043; Thu, 14 Sep 89 21:08:28 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15302; Thu, 14 Sep 89 21:09:09 EDT Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21020; Thu, 14 Sep 89 21:07:32 EDT Date: Thu, 14 Sep 89 21:07:32 EDT From: Mail Delivery Subsystem Subject: Returned mail: Service unavailable Message-Id: <8909150107.AA21020@ATHENA-PO-2.MIT.EDU> To: ----- Transcript of session follows ----- pop: unable to vfork 554 ... Service unavailable ----- Unsent message follows ----- Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21016; Thu, 14 Sep 89 21:07:32 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15289; Thu, 14 Sep 89 21:08:26 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA02602; Thu, 14 Sep 89 21:06:58 -0400 Date: Thu, 14 Sep 89 21:06:58 -0400 Message-Id: <8909150106.AA02602@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: ReSaveFunc *AlRsb_save_func(editor_id, rule, closure) You have the save and quit functions declared as ReSaveFunc *save_func; ReQuitFunc *quit_func; In your documentation...This says that the functions (my save & quit functions) must be functions that return a pointewr to a ReSaveFunc or ReQuitFunc. But I have no way of returning one odf those. (I don't even know what it is.) Should it have been "void save_func();" ?? Or something like that ? What should my functions say, instead of: ReSaveFunc *AlRsb_save_func(editor_id, rule, closure) reid editor_id; AlRule rule; VOIDP closure; { ... do stuff ... return( ?? ); }; I suspect I'm doing something wrong here. Thanks for the help. -- Brian  1,answered,, Summary-line: 15-Sep bgardner@ATHENA.MIT.EDU #Major problems with the ruleeditor. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA04225; Fri, 15 Sep 89 21:18:36 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07238; Fri, 15 Sep 89 20:54:31 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA03066; Fri, 15 Sep 89 18:07:19 -0400 Date: Fri, 15 Sep 89 18:07:19 -0400 Message-Id: <8909152207.AA03066@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: Major problems with the ruleeditor. *** EOOH *** From: Date: Fri, 15 Sep 89 18:07:19 -0400 To: rap@ATHENA.MIT.EDU Subject: Major problems with the ruleeditor. Hi Rich. I'm trying to use re_OpenEditor, but it is dumping core. My call looks like: editor_id = re_OpenEditor(Bool_FALSE, rule_link->rule, AlRsb_save_func, /* SaveFunction */ AlRsb_quit_func, /* QuitFunction */ 0, NULL, "Rule#", NULL, callback_struct); The dbx debug looks like: (dbx) where GetResources(0x12c800, 0x12c800, 0x7fffd484, 0x7fffd2f4, 0xd1000, 0x38, 0x7fffd1 64, 0x12c500, 0x6) at 0x56e19 XtGetResources(0x12c800, 0x12c500, 0x6) at 0x57169 _XtCreate(0x4402, 0x43fc, 0xa1b34, 0x0, 0xd7d4059e, 0x12c500, 0x6, 0x0) at 0x502 fd XtAppCreateShell(0x4402, 0x43fc, 0xa1b34, 0x0, 0x12c500, 0x6) at 0x508ba d2_create(0x125200) at 0x4501 re_OpenEditor(0x0, 0xd60c0, 0x1a54, 0x1c04, 0x0, 0x0, 0x1915, 0x0, 0xe7b80) at 0 x42f2 AlRsb_edit_callback(0xf0000, 0xe7b80, 0x7fffdcbc) at 0x1a47 _XtCallCallbacks(0xf10c8, 0x7fffdcbc) at 0x4dec8 XtWidgetCallCallbacks(0xf10c0, 0x7fffdcbc) at 0x4e1c6 PushB.BtnUp(0xf0000, 0x7fffe1e8, 0x0, 0xf1bec) at 0x1ffde _XtTranslateEvent(0xf0000, 0xf0038, 0x7fffe1e8) at 0x5dda7 DispatchEvent(0x7fffe1e8, 0xf0000, 0x8) at 0x51da0 DecideToDispatch(0x7fffe1e8) at 0x5208f XtDispatchEvent(0x7fffe1e8) at 0x520c4 XtAppMainLoop(0xbb400) at 0x52463 main(0x2, 0x7fffe2b4, 0x7fffe2c0) at 0x3472 (dbx) Could you please take a look into this. I'm at abit of a stand-still until this is solved. Thanks. -- Brian  1,, Summary-line: 16-Sep ackerman@ATHENA.MIT.EDU #fyi Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11427; Sat, 16 Sep 89 15:41:35 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA18942; Sat, 16 Sep 89 15:41:24 EDT Received: by BOOM.MIT.EDU (5.57/4.7) id AA17783; Sat, 16 Sep 89 15:40:03 EDT Message-Id: <8909161940.AA17783@BOOM.MIT.EDU> To: staff@ATHENA.MIT.EDU, lens-developers-at-mit@xv.mit.edu Subject: fyi Date: Sat, 16 Sep 89 15:40:02 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU, lens-developers-at-mit@xv.mit.edu Subject: fyi Date: Sat, 16 Sep 89 15:40:02 EDT This was the motd on Media-Lab. I can't vouch that this quote is true, but if it is, it's really terrifying. Ack --------- In an August 11 interview on Cable Network News, the head of the National Space Council, Vice President Dan Quayle, explained why the US should undertake a manned mission to Mars: "Mars is essentially in the same orbit. Mars is somewhat the same distance from the sun, which is very important. We have seen pictures where there are canals, we believe, and water. If there is water, there is oxygen. If oxygen, that means we can breathe."  1,, Summary-line: 16-Sep mackay@ATHENA.MIT.EDU #ruleeditor bugs Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA14886; Sat, 16 Sep 89 21:16:17 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23246; Sat, 16 Sep 89 21:17:25 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA01031; Sat, 16 Sep 89 21:16:03 -0400 Message-Id: <8909170116.AA01031@E40-368-1.MIT.EDU> To: rap@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: ruleeditor bugs Date: Sat, 16 Sep 89 21:15:59 EDT *** EOOH *** From: To: rap@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: ruleeditor bugs Date: Sat, 16 Sep 89 21:15:59 EDT After converting from complex to simple (it should come up in simple mode), I selected a field and pressed "delete". I got the following: pixel=1 X Protocol error: BadDrawable, invalid Pixmap or Window parameter Major opcode of failed request: 70 (X_PolyFillRectangle) Minor opcode of failed request: 0 Resource id in failed request: 0xe00086 Serial number of failed request: 2298 Current serial number in output stream: 2326 Error with ruleeditor. [1] Exit 1 rsedit sifter Wendy  1,, Summary-line: 16-Sep mackay@ATHENA.MIT.EDU #Bug Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15874; Sat, 16 Sep 89 23:42:31 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24954; Sat, 16 Sep 89 23:43:40 EDT Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA02911; Sat, 16 Sep 89 23:42:15 -0400 Message-Id: <8909170342.AA02911@E40-368-1.MIT.EDU> To: rap@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: Bug Date: Sat, 16 Sep 89 23:42:10 EDT *** EOOH *** From: To: rap@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: Bug Date: Sat, 16 Sep 89 23:42:10 EDT I used the old rule editor and changed a rule to check to see if a message had already been moved, as follows: $created 622006486 $updated 622006486 $name $if "From:" "%contains" "mackay" "Any-Case-Text" %0 "Number of Times Moved" "=" "0" "Integer" %4 %and 2 $then "siftme" %move-to 1 $end It gave me the following error message: Assertion failed: file predeval.c: line 224: 0 Illegal instruction Ideas? Wendy  1,,bug-motif, Summary-line: 17-Sep vanharen@ATHENA.MIT.EDU #bug with the scrolled list instance of the list widget. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20063; Sun, 17 Sep 89 16:53:00 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04037; Sun, 17 Sep 89 16:54:09 EDT Received: by FRIES.MIT.EDU (5.61/4.7) id AA06242; Sun, 17 Sep 89 16:52:44 -0400 Message-Id: <8909172052.AA06242@FRIES.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Subject: bug with the scrolled list instance of the list widget. Date: Sun, 17 Sep 89 16:52:39 EDT *** EOOH *** From: To: motif-bugs@ATHENA.MIT.EDU Subject: bug with the scrolled list instance of the list widget. Date: Sun, 17 Sep 89 16:52:39 EDT This mail bounced back to me... it was also delivered to part of the list, but not all, so I am resending it. Please excuse me if you received two copies. ------- Forwarded Message Received: by E40-PO.MIT.EDU (5.45/4.7) id AA04276; Thu, 14 Sep 89 23:57:37 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10858; Thu, 14 Sep 89 16:40:02 EDT Received: by FRIES.MIT.EDU (5.61/4.7) id AA01814; Thu, 14 Sep 89 16:37:56 -0400 Message-Id: <8909142037.AA01814@FRIES.MIT.EDU> To: motif-bugs@ATHENA.MIT.EDU Subject: bug with the scrolled list instance of the list widget. Date: Thu, 14 Sep 89 16:37:53 EDT OSF UEC Problem Report ================================= Submitter Information - --------------------- Submitter Name: Chris VanHaren Organization: MIT Project Athena Email Address: vanharen@athena.mit.edu Phone: (617) 253-0111 Hardware/Software Configuration - ------------------------------- Offering and Version: Motif 1.0 Component (Module): Toolkit, Scrolled List, (Xm/List.c, I think) OSF License Number: - Client Hardware: DEC VS II/RC, 5Meg ram, 16Meg swap. Client Software: Unix 4.3BSD w/athena ext., X11r3 Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: pcc Problem Description - ------------------- Severity Level: Minor -- represents a cosmetic type problem. Date of First Occurrence: 9/14/89 One Line Description: Scrolled List widget ignores the XmNscrollBarPlacement resource. Full Description: Apparently, the XmNscrollBarPlacement resource is ignored in the scrolled list widget. I attempted to set the value of this resource to XmBOTTOM_LEFT, but when the application runs, the vertical scrollbar appears on the right side. Repeat By: Create a scrolled list widget and attempt to put the scrollbars in some other place besides the bottom_right (default). Here are the attributes that I hvae set, in case there is some strange interaction going on that I missed. n=0; XtSetArg(args[n], XmNlistMarginWidth, NORMAL_SPACING); n++; XtSetArg(args[n], XmNlistMarginHeight, NORMAL_SPACING); n++; XtSetArg(args[n], XmNlistSpacing, NORMAL_SPACING); n++; XtSetArg(args[n], XmNselectionPolicy, XmSINGLE_SELECT); n++; XtSetArg(args[n], XmNscrollBarDisplayPolicy, XmAS_NEEDED); n++; XtSetArg(args[n], XmNscrollBarPlacement, XmBOTTOM_LEFT); n++; XtSetArg(args[n], XmNtopAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNleftAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNrightAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNbottomAttachment, XmATTACH_FORM); n++; w_list = XmCreateScrolledList(w_list_frame, "list", args, n); XtAddCallback(w_list, XmNsingleSelectionCallback, olc_topic_select, NULL); XtManageChild(w_list); Proposed Solution: From a quick glance at .../src/.../lib/Xm/List.c, it appears that XmNscrollBarPlacement was left out of the resources. I don't see that it is inherited from the Primitive or Core widgets, either. I don't know what all needs to be done in order to make it work... ------- End of Forwarded Message  1,,bug-motif, Summary-line: 18-Sep vanharen@ATHENA.MIT.EDU #problem with text widget, I think. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24162; Mon, 18 Sep 89 01:19:52 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11694; Mon, 18 Sep 89 01:21:03 EDT Received: by FRIES.MIT.EDU (5.61/4.7) id AA07176; Mon, 18 Sep 89 01:19:38 -0400 Message-Id: <8909180519.AA07176@FRIES.MIT.EDU> To: uec-defect@osf.osf.org Cc: motif-bugs@ATHENA.MIT.EDU Subject: problem with text widget, I think. Date: Mon, 18 Sep 89 01:19:33 EDT *** EOOH *** From: To: uec-defect@osf.osf.org Cc: motif-bugs@ATHENA.MIT.EDU Subject: problem with text widget, I think. Date: Mon, 18 Sep 89 01:19:33 EDT OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: Chris VanHaren Organization: MIT Project Athena Email Address: vanharen@athena.mit.edu Phone: (617) 253-0111 Hardware/Software Configuration ------------------------------- Offering and Version: Motif 1.0 Component (Module): Text.c? Not sure. OSF License Number: -- Client Hardware: VS II/RC, 5M ram, 16M swap. Client Software: Unix 4.3BSD w/athena extensions, X11r3. Server Hardware: SAME AS CLIENT Server Software: SAME AS CLIENT Compiler: pcc Problem Description ------------------- Severity Level: Critical -- represents a problem which resulted in software malfunction or a feature failure and has no work-around. Date of First Occurrence: 9/14/89 One Line Description: Setting the XmNmappedWhenManaged resource to FALSE in a form containing a multi-line text widget causes the text widget to misbehave (at best), or not work at all (at worst). Full Description: Setting the XmNmappedWhenManaged resource to FALSE in the widget that contains a multi-line text widget causes the text widget to behave it strange ways. The text-insertion cursor does not show up at all. One is able to type into the text widget, however, to move the cursor to another position, one must use the middle mouse button. Selecting text for pasting into another widget is strange, as well. The selection works correctly, as can be seen by pasting in another window, but the highlighting is either incorrect or invisible most of the time. Repeat By: Create a form or frame (or even a dialog shell) that contains a text widget as a child. I have only experienced this problem with the multi-line text widget, though I believe another person has experienced it with a single line widget. I have not personally investigated that case. Set XmNmappedWhenManaged to FALSE in the parent widget, but Manage the widget. Then, map the widget to the screen. Notice that the cursor is not visible. Attempt to enter text into the widget, and try to move the cursor with the left mouse button, as it is supposed to. Click in another location with the middle mouse button and type. The new text will show up in that place. Try highlighting some text, either by dragging with the left mouse button, or double-, triple-, or quad-clicking. The strange behavior is most easily seen if there is already a large amount of text in the text widget. Proposed Solution: I dunno. A psuedo-workaround that I am using is this: Avoid using the XmNmappedWhenManaged resource. Instead, create the parent widget, and manage it whenever you need it on the screen, and unmanage it when you want it to "pop down". This is not the best solution, as I would much rather Manage the widget when I create it, and Map and Unmap as I please, since that would be faster.  1,, Summary-line: 19-Sep vanharen@ATHENA.MIT.EDU #request for new feature: horizontal panes in addition to vertical Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA14877; Tue, 19 Sep 89 13:29:37 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA20894; Tue, 19 Sep 89 13:30:44 EDT Received: by FRIES.MIT.EDU (5.61/4.7) id AA10325; Tue, 19 Sep 89 13:29:10 -0400 Message-Id: <8909191729.AA10325@FRIES.MIT.EDU> To: uec-defect@osf.osf.org Cc: motif-bugs@ATHENA.MIT.EDU From: Chris VanHaren Subject: request for new feature: horizontal panes in addition to vertical Date: Tue, 19 Sep 89 13:28:59 EDT Sender: vanharen@ATHENA.MIT.EDU *** EOOH *** To: uec-defect@osf.osf.org Cc: motif-bugs@ATHENA.MIT.EDU From: Chris VanHaren Subject: request for new feature: horizontal panes in addition to vertical Date: Tue, 19 Sep 89 13:28:59 EDT Sender: vanharen@ATHENA.MIT.EDU OSF UEC Problem Report ================================= Submitter Information (Include if not in News/mail headers) --------------------- Submitter Name: Chris VanHaren Organization: MIT Project Athena Email Address: vanharen@athena.mit.edu Phone: (617) 253-0111 Hardware/Software Configuration ------------------------------- Offering and Version: Motif 1.0 Component (Module): Paned Window widget (PanedW.[ch]) OSF License Number: -- Client Hardware: -- Client Software: -- Server Hardware: -- Server Software: -- Compiler: -- Problem Description ------------------- Severity Level: Enhancement -- represents a request for enhancement of the software. One Line Description: It would be nice to have a horizontal paned widget in addition to the vertical paned widget. Full Description: I would like to be able to put objects into a paned widget in a horizontal format as well as in a vertical format. It would be nice to be able to lay out children in a horizontally tiled format. The Pane widget would function in much the same way, except that children would be added from left to right instead of top to bottom. Repeat By: --- Proposed Solution: Add a resource to the Pane widget, XmNorientation, similar to the resource for the separator widget. Have it default to vertical, so that no-one's existing applications break. Or perhaps you'd rather have the default be called XmHORIZONTAL, to be consistent with the separator widget resource, but have the orientation refer to the layout of the line between the children, and not the children, if you know what I mean. I'll leave that decision to you.  1,, Summary-line: 19-Sep geer@ATHENA.MIT.EDU #Athena Look&Feel Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17477; Tue, 19 Sep 89 16:10:18 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24712; Tue, 19 Sep 89 16:00:33 EDT Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA03411; Tue, 19 Sep 89 15:59:03 -0400 Date: Tue, 19 Sep 89 15:59:03 -0400 Message-Id: <8909191959.AA03411@E40-342F-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Athena Look&Feel *** EOOH *** From: Date: Tue, 19 Sep 89 15:59:03 -0400 To: staff@ATHENA.MIT.EDU Subject: Athena Look&Feel In the interest of developing a readily recognizable Athena Look&Feel (something worth suing over), let me suggest the following. As we move to 3d buttons, scrollbars, and other gadgets, you may note that they all exhibit their 3d-ness by shadowing. This shadowing is accomplished by behaving as if there were a light source at some fixed location, almost always above the screen on the left side. My suggestion is that the light source be like the sun - i.e. it rise, move through the sky, and set. But on what time scale does this sun rise and set? (I hear you cry) Needless to say, I am suggesting that it correspond to the lifetime of one's ticket-granting-ticket. In that way, at ``nightfall'', you kinit to start a new ``day''. On color displays, suitable color should also be added, perhaps extracted by subscribing to the weather instance... Purple from the strain, I am Very nearly yours, Dan  1,, Summary-line: 19-Sep henry@MIT.EDU #Re: Athena Look&Feel Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17633; Tue, 19 Sep 89 16:16:21 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24842; Tue, 19 Sep 89 16:05:24 EDT Received: by GARP.MIT.EDU with sendmail-5.61/4.7 id ; Tue, 19 Sep 89 16:03:50 -0400 Message-Id: <8909192003.AA21005@GARP.MIT.EDU> From: Henry Mensch To: Cc: staff@ATHENA.MIT.EDU Subject: Re: Athena Look&Feel In-Reply-To: Your message of Tue, 19 Sep 89 15:59:03 -0400. <8909191959.AA03411@E40-342F-2.MIT.EDU> Date: Tue, 19 Sep 89 16:03:48 EDT Sender: henry@GARP.MIT.EDU *** EOOH *** From: Henry Mensch To: Cc: staff@ATHENA.MIT.EDU Subject: Re: Athena Look&Feel In-Reply-To: Your message of Tue, 19 Sep 89 15:59:03 -0400. <8909191959.AA03411@E40-342F-2.MIT.EDU> Date: Tue, 19 Sep 89 16:03:48 EDT Sender: henry@GARP.MIT.EDU > From: > On color displays, suitable color should also > be added, perhaps extracted by subscribing to the > weather instance... nah. your root window should reflect the color of your mood, as determined by the temperature of your skin where it touches the keyboard and mouse (remember mood rings?) -- henry --------  1,, Summary-line: 19-Sep geer@ATHENA.MIT.EDU #re: X FIPS NOT Delayed Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA18128; Tue, 19 Sep 89 16:42:38 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA25591; Tue, 19 Sep 89 16:32:19 EDT Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA03449; Tue, 19 Sep 89 16:30:43 -0400 Message-Id: <8909192030.AA03449@E40-342F-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: re: X FIPS NOT Delayed Date: Tue, 19 Sep 89 16:30:41 EDT *** EOOH *** From: To: staff@ATHENA.MIT.EDU Subject: re: X FIPS NOT Delayed Date: Tue, 19 Sep 89 16:30:41 EDT ------- Forwarded Message Date: Tue, 19 Sep 89 15:36:40 EDT From: Kuhn Organization: National Institute of Standards and Technology Formerly: National Bureau of Standards Sub-Organization: National Computer and Telecommunications Laboratory To: xpert@expo.lcs.mit.edu Subject: X FIPS NOT Delayed A piece of rotten, irresponsible, and inept journalism on the front page of Government Computer News, Sept. 18, proclaims "NIST Delays X Window FIPS." Nothing could be further from the truth. NIST intends to move ahead on our original schedule to adopt X as a Federal Information Processing Standard. The article also states that the three week extension in the public comment period is "to help clear up what an agency official called confusion over the issue." This is incorrect. The extension was granted at the request of two organizations that needed more time to formulate their comments. It is quite common for the comment period to be extended. In fact, we always accept comments received in a reasonable amount of time after the expiration of the comment period. The adoption of a FIPS is not a balloting process as is done within ANSI or IEEE. Comments are requested to determine the opinions of agencies and companies w.r.t. the proposed FIPS, and also to solicit constructive criticism of the content and wording of the document. Many helpful comments we have received will be incorporated into the final document that we submit for Commerce Department approval. For example, many people suggested that X11 R4 should be considered. We concur. In fact it has always been our intent to adopt R4 as soon as it is ready. The process will continue on the original schedule. We expect to have a FIPS based on X in early 1990. Rick Kuhn NIST ------- End of Forwarded Message  1,, Summary-line: 19-Sep djf@ATHENA.MIT.EDU #UEC SIG trip report Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA19468; Tue, 19 Sep 89 17:52:15 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27704; Tue, 19 Sep 89 17:52:04 EDT Received: by LEO.MIT.EDU (5.61/4.7) id AA27506; Tue, 19 Sep 89 17:50:27 -0400 Date: Tue, 19 Sep 89 17:50:27 -0400 Message-Id: <8909192150.AA27506@LEO.MIT.EDU> To: sysdev@ATHENA.MIT.EDU, motif@ATHENA.MIT.EDU Subject: UEC SIG trip report *** EOOH *** From: Date: Tue, 19 Sep 89 17:50:27 -0400 To: sysdev@ATHENA.MIT.EDU, motif@ATHENA.MIT.EDU Subject: UEC SIG trip report I spent Monday and Tuesday in Merrimack, NH at a Motif SIG meeting. I was involved with the UIL/UIMS working group. The highlights: Several IDT (interactive design tool) and UIMS (user interface management system) vendors made presenations about their products. They were pretty interesting, but nothing really that we need to be too interested in. UIMX from Visual Edge gave what was really a sales pitch. UIMX does really look good. I guess it will be supplied by hardware vendors, so maybe we can get our hands on it, but I'm sure we can't afford it otherwise. We were told that UIMX "has only one coding defect per 10,000 lines of code". Two of the 4 systems used C++ at least partially. One, called TAE Plus is out of NASA and is available for a nominal fee. It grew out of an old ASCII based system. It's kind of interesting, but probably a bit overwhelming and restrictive for us. If you want details, you can talk to Roman or I. I gave a 15min talk about the Xt server Barry has written. A lot of people asked good questions and people took the 50 copies of the paper I was distributing. A new version of UIL will be available in early November. Reportedly, this version will allow your UIL program to include only the widgets it uses, rather than always linking with all of the widgets. This version will also come with a compiler compiler, so you can add support for your own widgets to the compiler. This could be useful for the widgets we are writing here, and for the athena widgets. You feed a description of your widgets into it, and it spits out a UIL compiler, and widget documentation (in troff mm macros). Almost like magic! In the more distant future, we may see some more useful changes to UIL. These will include the ability to have the compiler generate an X resources file containing the resources you want the user to be able to override. Any substantial changes to UIL, including a macro or template facility, or dialog management features are on hold, probably permanently. Adding too many features to UIL would screw up the people who want to use it as an interchange language for IDTs. The Digital plant is huge. Lots of trees, lakes, a helioport, and flocks of migrating geese. The roads around the parking lots are named "Peripheral Lane", "Memory Drive", "Interface Way" and stuff like that. I got to watch someone from HP argue that UIL was too buggy and someone from DEC argue that the widgets were too buggy. Then the conversion turned to a discussion of testing philosophies and cooled off. I learned to be glad that I don't work in the corporate world. All the representatives from corporate members of the OSF had money at stake in the success of Motif. They also stood to lose customers if Motif was buggy. So they were uptight about things. Digital's cafeteria uses all styrofoam plates and bowls -- great for the ozone layer. Merimack, NH is home to an Anheiser/Busch factory. Everything else was deathly boring. -- djf  1,,system, Summary-line: 19-Sep jik@ATHENA.MIT.EDU #motif-talk-athena mailing list Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23835; Tue, 19 Sep 89 23:47:37 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04779; Tue, 19 Sep 89 23:47:44 EDT Received: by PIT-MANAGER.MIT.EDU (5.61/1.0JIK) id ; Tue, 19 Sep 89 23:46:09 -0400 Date: Tue, 19 Sep 89 23:46:09 -0400 Message-Id: <8909200346.AA16227@PIT-MANAGER.MIT.EDU> From: Jonathan I. Kamens Sender: jik@PIT-MANAGER.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: motif-talk-athena mailing list *** EOOH *** Date: Tue, 19 Sep 89 23:46:09 -0400 From: Jonathan I. Kamens Sender: jik@PIT-MANAGER.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: motif-talk-athena mailing list I have arranged a mailing list called motif-talk-athena, which is public and to which (therefore) anyone can add themselves. It will serve as the local feed for the motif-talk@osf.osf.org mailing list, which is sort of the motif analogue of xpert. Please feel free to add yourself to the mailing list. Submissions to motif-talk should get sent to motif-talk@osf.osf.org, *not* motif-talk-athena@athena.mit.edu. jik  1,,system, Summary-line: 20-Sep wdc@ATHENA.MIT.EDU #Andrew EZ News. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24035; Wed, 20 Sep 89 00:11:24 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05124; Wed, 20 Sep 89 00:11:29 EDT Received: by OGLALA.MIT.EDU (5.61/4.7) id AA09111; Wed, 20 Sep 89 00:09:58 -0400 Received: from Messages.7.10.N.CUILIB.3.45.SNAP.NOT.LINKED.oglala.rt.r3 via MS.5.6.oglala.rt_r3; Wed, 20 Sep 89 00:09:58 -0400 (EDT) Message-Id: Date: Wed, 20 Sep 89 00:09:58 -0400 (EDT) From: Bill Cattey To: staff@ATHENA.MIT.EDU Subject: Andrew EZ News. Cc: candrew@ATHENA.MIT.EDU *** EOOH *** Date: Wed, 20 Sep 89 00:09:58 -0400 (EDT) From: Bill Cattey To: staff@ATHENA.MIT.EDU Subject: Andrew EZ News. Cc: candrew@ATHENA.MIT.EDU There is now a mailing list andrew-news Which you can add yourself to for news about andrew. I'm recommending ALL andrew users add themselves. I'm soon going to stop sending Andrew news items to the staff mailing list and start sending it to andrew-news. This way users, who are not staff, will get the news. ---- News Item: nandrew supports greek, and math, and symbols. Using the two new styles symbol and symbola, you can incorporate mathematical symbols and greek letters into your text document. This is not yet support for foreign accents which turns out even harder, since the accents aren't in the Andrew fonts and they are hard to get out of troff. Even so, I am working on providing this support. In the mean time, try out the two new fonts, and enjoy bullets partials, greek letters, etc. Share and enjoy, -wdc  1,, Summary-line: 20-Sep jfc@ATHENA.MIT.EDU #XView toolkit from Sun Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25470; Wed, 20 Sep 89 06:26:32 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09950; Wed, 20 Sep 89 06:25:44 EDT Received: by ACHATES.MIT.EDU (5.61) id AA05084; Wed, 20 Sep 89 06:24:13 -0400 Message-Id: <8909201024.AA05084@ACHATES.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: XView toolkit from Sun Date: Wed, 20 Sep 89 06:24:12 EDT From: John Carr *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: XView toolkit from Sun Date: Wed, 20 Sep 89 06:24:12 EDT From: John Carr The XView demo programs have been installed in /afs/athena/astaff/project/XView/bin. This is most definitely an alpha software release, and many things don't work as well as they should. However, those interested in toolkits (either as users or programmers) should take a look at these programs at some point. I have set up an account on my workstation to show off a few programs (the workstation is in the watchmaker zone -- the one with all the displays connected to it); login as user "XView". If you use it yourself, you will need to run "xset fp+ /afs/athena/astaff/project/XView/lib/font" in order to use the XView fonts. For more information about XView, send me mail. --John Carr  1,answered,, Summary-line: 20-Sep probe@ATHENA.MIT.EDU #Personal AFS groups Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA28131; Wed, 20 Sep 89 11:49:53 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15348; Wed, 20 Sep 89 11:50:27 EDT Received: by CRONOS.MIT.EDU (5.61/4.7) id AA08190; Wed, 20 Sep 89 11:48:54 -0400 Date: Wed, 20 Sep 89 11:48:54 -0400 Message-Id: <8909201548.AA08190@CRONOS.MIT.EDU> To: shanzer@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU, dpeisach@ATHENA.MIT.EDU, djf@ATHENA.MIT.EDU, eichin@ATHENA.MIT.EDU Cc: probe@ATHENA.MIT.EDU Subject: Personal AFS groups Reply-To: Richard Basch Address: 3 Ames Street Cambridge, MA 02139 Phone: (617) 225-6355 *** EOOH *** From: Date: Wed, 20 Sep 89 11:48:54 -0400 To: shanzer@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU, dpeisach@ATHENA.MIT.EDU, djf@ATHENA.MIT.EDU, eichin@ATHENA.MIT.EDU Cc: probe@ATHENA.MIT.EDU Subject: Personal AFS groups Reply-To: Richard Basch Address: 3 Ames Street Cambridge, MA 02139 Phone: (617) 225-6355 It is planned in the near future to have AFS controlled by Moira and to update the AFS protection database from Moira. However, there are some groups with id's that may conflict with the range that Moira would assign. These groups include: djf:motifdev dpeisach:kurita eichin:virushunters rap:argus shanzer:jove It is a simple matter to re-assign id's to these groups; all it requires is: prs delete prs create prs add prs add etc. However, there is one catch. Internally to AFS, the directory ACLs contain the protection database id's, not the strings. This means that whatever directories depended on these ACLs need to have the following commands done on them: fs cleanacl fs sa Of course, if the only administrator of a directory is the , you would first want to add yourself as an administrator before destroying and re-creating the group. I expect that it is planned that we will be keeping the id's in the non-assignable range, but I do not know how feasible it is to keep the id's that may conflict with Moira. If the system:administrators of the cell have to do this conversion, there is a risk that we may not get it quite the same as you had it set up, so we are asking you for assistance in the re-assigning of personal group id's. Thanks, -Richard  1,, Summary-line: 20-Sep probe@ATHENA.MIT.EDU #Re: Personal AFS groups Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08163; Wed, 20 Sep 89 21:33:02 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29653; Wed, 20 Sep 89 21:34:26 EDT Received: by CRONOS.MIT.EDU (5.61/4.7) id AA08485; Wed, 20 Sep 89 21:32:56 -0400 Date: Wed, 20 Sep 89 21:32:56 -0400 Message-Id: <8909210132.AA08485@CRONOS.MIT.EDU> To: rap@ATHENA.MIT.EDU In-Reply-To: Rich Pito's message of Wed, 20 Sep 89 18:27:38 -0400, <8909202227.AA09787@MORPHEUS.MIT.EDU> Subject: Re: Personal AFS groups Reply-To: Richard Basch Address: 3 Ames Street Cambridge, MA 02139 Phone: (617) 225-6355 *** EOOH *** From: Date: Wed, 20 Sep 89 21:32:56 -0400 To: rap@ATHENA.MIT.EDU In-Reply-To: Rich Pito's message of Wed, 20 Sep 89 18:27:38 -0400, <8909202227.AA09787@MORPHEUS.MIT.EDU> Subject: Re: Personal AFS groups Reply-To: Richard Basch Address: 3 Ames Street Cambridge, MA 02139 Phone: (617) 225-6355 Within in a week... The only thing I found of yours depending on that group was in /afs/athena/astaff/project/argus/doc/exec.summary/ There may be more, but I didn't see anything else. -Richard  1,, Summary-line: 21-Sep awa.junet!ti@uunet.UU.NET #T.I.'s comments on Motif Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA10085; Thu, 21 Sep 89 00:59:48 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02656; Thu, 21 Sep 89 01:00:25 EDT Received: from kddlab .UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA19823; Thu, 21 Sep 89 00:58:44 -0400 Received: from titcca.cc.titech.junet by kddlab.kddlabs.co.jp (4.0/6.2Junet) id AA16071; Thu, 21 Sep 89 13:15:23 JST Received: by titcca.cc.titech.junet (5.61/6.4J.1) id AA05967; Thu, 21 Sep 89 13:11:56 +0900 Received: by dclsic.dcl.junet (5.51/6.4J.6-DCL/Master) with UUCP id AA19649; Thu, 21 Sep 89 13:09:02+0900 Received: by sjc.yokogawa.junet (5.51/6.4J.5-YOKOGAWA-R/GW) id AA03670; Thu, 21 Sep 89 12:43:14 JST Date: Thu, 21 Sep 89 12:43:14 JST From: kddlab!yokogawa.junet!ti@uunet.UU.NET (Takeshi Inoue) Return-Path: Message-Id: <8909210343.AA03670@sjc.yokogawa.junet> To: roman%athena.mit.edu@kddlab.kddlabs.co.jp Subject: T.I.'s comments on Motif Cc: djf%athena.mit.edu@kddlab.kddlabs.co.jp, jstewart%athena.mit.edu@kddlab.kddlabs.co.jp, motif%athena.mit.edu@kddlab.kddlabs.co.jp, ti%yokogawa.junet@uunet.UU.NET *** EOOH *** Date: Thu, 21 Sep 89 12:43:14 JST From: kddlab!yokogawa.junet!ti@uunet.UU.NET (Takeshi Inoue) Return-Path: To: roman%athena.mit.edu@kddlab.kddlabs.co.jp Subject: T.I.'s comments on Motif Cc: djf%athena.mit.edu@kddlab.kddlabs.co.jp, jstewart%athena.mit.edu@kddlab.kddlabs.co.jp, motif%athena.mit.edu@kddlab.kddlabs.co.jp, ti%yokogawa.junet@uunet.UU.NET Hello, how are you? Thank you for everything while I was in Project Athena. I've been working in Tokyo for 2 weeks now. I had a lot of red tape and I am sorry to be late to send this mail. Here I made my comments on Motif. I wrote things I want Motif to be able to do, but I might be misunderstanding something, so, could you tell me if there are ways to do, if I am missing something or if you have any comments? I will be here in the Tokyo office until at least the middle of October and my e-mail address is: ti%yokogawa.junet@uunet.uu.net T.I.'s comments on Motif. 1. concept is very good A new concept fot X-window programming is very good and acceptable. The UIL grammar was easily understood for me. Sometimes, applications and user interfaces cannot be divided perfectly, but fundamentally, they should be divided and developed independently; I appreciate to have introduced this new concept. 2. versatility Widget name and Widget class: Essentially, what programmers can specify in C programms for widgets, should be done also in UIL programms except for some functionalities, i.e. dynamic resource value changing, etc. In terms of that goal, UIL is well designed. I hope there be one other ability. I hope programmers can write widget specs whose number varies according to the environment. For example, when I developed the 'mxfonts', I had to write the font display window creations in C source because the number of available fonts depends on users' environment. Now we can write only fixed number of widgets in UIL files, but I think it is common case to vary the widgets' number depending on the environments or users file contents, e.g. menu items, directory contents display, etc. One can say this part should be in the application and should be written in C, but the other should say it should also be involved in user interface. By introducing new grammar, UIL can manipulate that kind of widgets I guess. 3. UIL's familiality to C applications One big differrence between C and UIL is UIL is name oriented, i.e. a widget is identified by name whereas it is done by widget ID in C. In UIL, different widgets must have different name whereas they can have the same name in C. This difference affects resource files writing. Without UIL, resource values used to be set for plural widgets by a widget name if they have the same name. In this kind of case, they say class names should be used in place of widget names. However, we want set the same name for some part of widgets in the same class. Suppose you make a calendar program and you want to change the color of Sundays and Saturdays different from weekday colors provided all day widgets are in the same class and have same parent. At present, we have to specify each day widgets color in a resource file. If all Sunday widgets can have the same name, we can set the color of the widgets using only one line. I am not sure if this functionality should be realized but I think it is worth discussing. 4. Mamory consuming. As all members of this project should have noticed, all motif programms are very very big. For now, users cannot run motif programms as background processes simultaneously because most of working space is used by them. This serious problem must be solved. The more UIL functions, i.e. 'Mu....', become available in the future, the bigger the size of load modules will be, I am afraid. In addition, performance is also bad especially, widget fetching process takes time a lot. 5. for whom the toolkit is? This is not a question only for Motif but also for all toolkit developers. Do the programmers have to know well about Xlib? Is the toolkit for Xlib experts to facilitate to program? Or, should the toolkit be for programmers who has no or a little knowledge about Xlib? If it is the latter case, what should programmers know about Xlib? 6. Familiarity to programmers The more the number of widget classes exist, the more convenient for programming, but on the other hand, it will get harder for programmers to grasp precise feature of each widget class. Even now I sometimes hesitate which widget I should use, and cannot easily understand the differences between 2 or 3 widgets' characteristics. Documentation should be more easy to read and it should use more diagrams. Widgets experts may be necessary or, expert systems to choose proper widget classes are needed when the number of widgets grows more and more. 7. resource manipulation policy I think the resource management policy is not clear. The motif style guide is for user interface consistency check and there is no such kind of guide specifying how to write C-code, UIL-code and resource files. Sould resource values be written in C, UIL or resource files? Resource values which users are allowed to customize should be written in resource files. For now, in the first phase of development, all resources are specified in C and UIL, and in the secound phase, some of resources are transfered to resource files. Another question is how the motif tools should be distributed. Now most of programms in ..../motif/projects consist of a c-load module and uid files, and most of resource values are fixed. In this case, users cannot change resource values since the values in rosurce files do not override C or UIL. If tools are distributed with a c-load module, uid files and resource files, users have to use 'xrdb' command or 'setenv XENVIRONMENT' command everytime the session starts. 8. I had sent e-mails to motif-bugs for detailed parts. Other detailed comments had been sent to motif-bugs. That's all for now. Thank you for reading. See you again. T.I.  1,, Summary-line: 21-Sep awa.junet!ti@uunet.UU.NET #Please send e-mails to T.I.'s new address. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA10126; Thu, 21 Sep 89 01:01:00 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02648; Thu, 21 Sep 89 01:00:03 EDT Received: from kddlab .UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA19778; Thu, 21 Sep 89 00:58:26 -0400 Received: from titcca.cc.titech.junet by kddlab.kddlabs.co.jp (4.0/6.2Junet) id AA16070; Thu, 21 Sep 89 13:15:16 JST Received: by titcca.cc.titech.junet (5.61/6.4J.1) id AA05960; Thu, 21 Sep 89 13:11:52 +0900 Received: by dclsic.dcl.junet (5.51/6.4J.6-DCL/Master) with UUCP id AA19643; Thu, 21 Sep 89 13:08:48+0900 Received: by sjc.yokogawa.junet (5.51/6.4J.5-YOKOGAWA-R/GW) id AA03466; Thu, 21 Sep 89 11:59:37 JST Date: Thu, 21 Sep 89 11:59:37 JST From: kddlab!yokogawa.junet!ti@uunet.UU.NET (Takeshi Inoue) Return-Path: Message-Id: <8909210259.AA03466@sjc.yokogawa.junet> To: staff%athena.mit.edu@kddlab.kddlabs.co.jp Subject: Please send e-mails to T.I.'s new address. *** EOOH *** Date: Thu, 21 Sep 89 11:59:37 JST From: kddlab!yokogawa.junet!ti@uunet.UU.NET (Takeshi Inoue) Return-Path: To: staff%athena.mit.edu@kddlab.kddlabs.co.jp Subject: Please send e-mails to T.I.'s new address. How are you? I will be here in Tokyo until the end of October. My schedule to go to G.E. has been delayed because of visa acquisition. Now I have my own account for e-mail receiving and please send e-mails address to : ti%yokogawa.junet@uunet.uu.net Thank you. See you. T.I.  1,, Summary-line: 21-Sep wdc@ATHENA.MIT.EDU #Changes to nandrew symbol support. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA10523; Thu, 21 Sep 89 01:49:58 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA03306; Thu, 21 Sep 89 01:42:12 EDT Received: by OGLALA.MIT.EDU (5.61/4.7) id AA14745; Thu, 21 Sep 89 01:40:40 -0400 Received: from Messages.7.10.N.CUILIB.3.45.SNAP.NOT.LINKED.oglala.rt.r3 via MS.5.6.oglala.rt_r3; Thu, 21 Sep 89 01:40:36 -0400 (EDT) Message-Id: <0Z67FIAGG047MrpqIF@athena.mit.edu> Date: Thu, 21 Sep 89 01:40:36 -0400 (EDT) From: Bill Cattey To: staff@ATHENA.MIT.EDU Subject: Changes to nandrew symbol support. Cc: andrew-news@ATHENA.MIT.EDU, candrew@ATHENA.MIT.EDU *** EOOH *** Date: Thu, 21 Sep 89 01:40:36 -0400 (EDT) From: Bill Cattey To: staff@ATHENA.MIT.EDU Subject: Changes to nandrew symbol support. Cc: andrew-news@ATHENA.MIT.EDU, candrew@ATHENA.MIT.EDU The next message on the state of andrew will not go to staff, it will go to andrew-news, so add yourself NOW! If you need help, send me mail. I decided that users would need more help with symbols than just the existance of two new menu items. I also decided that people using symbols should go through the trouble of LEARNING how to use them before proceeding. The symbols are easy to use, but do require instruction. If you want to use symbols: In an empty ez buffer, choose the "Add Template" menu item from the "File" menu card. Give the name "symbol" when prompted at the bottom of the screen. The symbol template, when read into an empty ez buffer, not only adds menu items for the two symbol fonts, it lists all the working characters, tells why there are missing characters, tells what the correspondances are between the keyboard keys and the supported symbols are, and provides the actual symbols if the user chooses to use them by cutting them. If the symbol template is read into a non-empty ez buffer, it will add the symbol menus, but not insert any help text, or symbol text into the buffer. ---- This is not the perfect user interface, but it makes the best of a strange situation: telling a user how to specify special symbols without a little plastic thing to go over the keyboard, and the fact that the printer does not support all the codes that the screen font does. NOTE: I am still working on adding foreign accents. At least we really can put symbols and greek in running text, which several people complained about. -wdc  1,, Summary-line: 21-Sep bgardner@ATHENA.MIT.EDU #LOTS OF PROBLEMS !!! Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13741; Thu, 21 Sep 89 11:00:27 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08672; Thu, 21 Sep 89 11:01:49 EDT Received: by PINK.MIT.EDU (5.61/4.7) id AA05257; Thu, 21 Sep 89 11:00:13 -0400 Date: Thu, 21 Sep 89 11:00:13 -0400 Message-Id: <8909211500.AA05257@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: LOTS OF PROBLEMS !!! *** EOOH *** From: Date: Thu, 21 Sep 89 11:00:13 -0400 To: rap@ATHENA.MIT.EDU Subject: LOTS OF PROBLEMS !!! I'm having tons of problems with this new code. Like: Assertion failed: file ruleset.c: line 233: index < rs->rule_count and ruleeditor: the field type Case appearing in the profile component FieldTypePresentationOrder is not valid. ruleeditor: the field type Case appearing in the profile component FieldTypePresentationOrder is not valid. ruleeditor: the field type Case appearing in the profile component FieldTypePresentationOrder is not valid. ruleeditor: the field type Case appearing in the profile component FieldTypePresentationOrder is not valid. pixel=1 etc, etc, etc. If you get a chance, can you fix this. I'm unable to do any more development at this point. Thanks. - Brian  1,, Summary-line: 21-Sep rap@ATHENA.MIT.EDU #bnew object Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA19322; Thu, 21 Sep 89 16:32:47 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA17631; Thu, 21 Sep 89 16:34:05 EDT Received: by E40-334-3.MIT.EDU (5.61/4.7) id AA26461; Thu, 21 Sep 89 16:32:28 -0400 Date: Thu, 21 Sep 89 16:32:28 -0400 Message-Id: <8909212032.AA26461@E40-334-3.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: bnew object *** EOOH *** From: Date: Thu, 21 Sep 89 16:32:28 -0400 To: argus2@ATHENA.MIT.EDU Subject: bnew object I have been working in the background (while things compile) on a new text object which allows you to open a 'message' file and retreive messages from it by name. There is a new profile component to go along with this called MessageDirectory which is the name of a directory where the object will look for its message files. This will make editing and updating textual messages (like for help) much easier and not require any recompiles (it will also make it easier to port to foreign languages (!!!) (the implication is a joke, but it really would)). If anybody is interested its called text.c and doesn't yet live in src. __Rich  1,, Summary-line: 21-Sep beth@ATHENA.MIT.EDU #who's-in-charge-of-what on the Consulting team Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22719; Thu, 21 Sep 89 20:39:20 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA23648; Thu, 21 Sep 89 20:39:41 EDT Received: by KLEE.MIT.EDU (5.61/4.7) id AA00746; Thu, 21 Sep 89 20:38:04 -0400 Message-Id: <8909220038.AA00746@KLEE.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: who's-in-charge-of-what on the Consulting team Date: Thu, 21 Sep 89 20:37:58 EDT From: Beth Anderson (Consulting Manager) *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: who's-in-charge-of-what on the Consulting team Date: Thu, 21 Sep 89 20:37:58 EDT From: Beth Anderson (Consulting Manager) FYI: _______________________________________________________________________________ PARTIAL WHO'S-IN-CHARGE-OF-WHAT ON THE CONSULTING TEAM Prepared by: Beth Anderson 9-21-89 _______________________________________________________________________________ budget ....................................... beth cluster consulting ........................... kevles 'consult' software bin ....................... jfc Consultants' Office .......................... kevles Consultants' Handbook ........................ kevles Consultants' Meeting agendae ................. kevles, carla, beth Consulting Hotline ........................... kevles consulting schedule .......................... kevles Consulting "support" policy .................. beth Consulting workstations (11-115 and E40) ..... kevles w/drmorris cref [on-line consultants' reference tree] ... carla "for now" discuss meetings OLC .................................. carla other ................................ kevles interface to AppDev ............................... carla contingent consultants ............... kevles Documentation ........................ beth Faculty Liaison ...................... kevles, carla, beth Information Systems .................. carla Operations ........................... kevles SIPB ................................. kevles Systems Development .................. TBD Training ............................. kevles User Accounts ........................ carla knowledge database ........................... carla OLC .......................................... carla -- includes stock answers, Manual, stats, Volunteers, releases, et cetera polls of consultants ......................... beth recruiting student consultants ............... kevles Seminar Series [continuing c education] ..... TBD training new consultants ..................... kevles supervising student consultants "new consultants" .................... kevles "old consultants" .................... carla _______________________________________________________________________________  1,,athena, Summary-line: 22-Sep geer@ATHENA.MIT.EDU #palladium review on wednesday Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27808; Fri, 22 Sep 89 09:34:39 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04574; Fri, 22 Sep 89 09:35:30 EDT Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA20164; Fri, 22 Sep 89 09:33:52 -0400 Message-Id: <8909221333.AA20164@E40-342F-2.MIT.EDU> To: sysdev@ATHENA.MIT.EDU, directors@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: palladium review on wednesday Date: Fri, 22 Sep 89 09:33:49 EDT *** EOOH *** From: To: sysdev@ATHENA.MIT.EDU, directors@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: palladium review on wednesday Date: Fri, 22 Sep 89 09:33:49 EDT Reminder: A review of the Version 2.0 Design Document for the Palladium Printing System will be held in E40-382, 10:00 AM - 3:00 PM on September 27, 1989. Hardcopy of the document is available now from me. Please give this careful attention, and come to the review. If you cannot attend in person, written comments to me by the close of Tuesday, please. --dan  1,filed,, Summary-line: 22-Sep friedman@harvard.harvard. #Re: Ciao! Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01656; Fri, 22 Sep 89 13:26:29 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10417; Fri, 22 Sep 89 13:27:55 EDT Message-Id: <8909221727.AA10417@ATHENA.MIT.EDU> Received: by harvard.harvard.edu (5.54/a0.25) (for rap@ATHENA.MIT.EDU) id AA27119; Fri, 22 Sep 89 13:28:13 EDT Received: by endor.HARVARD.EDU; Fri, 22 Sep 89 13:28:00 EDT Date: Fri, 22 Sep 89 13:28:00 EDT From: friedman@harvard.harvard.edu (Joyce Friedman) To: rap@ATHENA.MIT.EDU Subject: Re: Ciao! *** EOOH *** Date: Fri, 22 Sep 89 13:28:00 EDT From: friedman@harvard.harvard.edu (Joyce Friedman) To: rap@ATHENA.MIT.EDU Subject: Re: Ciao! Take T or #1 bus to Harvard Square: Go through Yard to get to Science Center (new, white, shaped like camera). Go past the short side of the Science Center, past Paine Hall (Music), toward Langdell Hall (huge white law building). Now you are in the Law Quad. Go diagonallly across the Law Quad to Aiken (the Computation Center). It is a small 2-story building. I am in rm. 234. The address, which is not too relevant, is 33 Oxford Street. See you at 3pm.  1,, Summary-line: 22-Sep carla@ATHENA.MIT.EDU #New OLC Volunteer! Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06221; Fri, 22 Sep 89 17:08:36 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16972; Fri, 22 Sep 89 17:07:46 EDT Received: by M11-115-4.MIT.EDU (5.61/4.7) id AA18619; Fri, 22 Sep 89 17:06:01 -0400 Message-Id: <8909222106.AA18619@M11-115-4.MIT.EDU> To: consultants@ATHENA.MIT.EDU, olc_volunteers@ATHENA.MIT.EDU Cc: jstewart@ATHENA.MIT.EDU, orcutt@ATHENA.MIT.EDU, murman@ATHENA.MIT.EDU Subject: New OLC Volunteer! Date: Fri, 22 Sep 89 17:05:50 EDT From: Carla Fermann *** EOOH *** To: consultants@ATHENA.MIT.EDU, olc_volunteers@ATHENA.MIT.EDU Cc: jstewart@ATHENA.MIT.EDU, orcutt@ATHENA.MIT.EDU, murman@ATHENA.MIT.EDU Subject: New OLC Volunteer! Date: Fri, 22 Sep 89 17:05:50 EDT From: Carla Fermann I'm pleased to announce that Hal Birkeland (hkbirke), has joined us as an OLC volunteer. Hal is most noted for "fixing xterm" and his work at the Media Lab. Please join me in welcoming him. Carla  0,unseen,, Summary-line: 22-Sep rap@ATHENA.MIT.EDU #Error checking Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06253; Fri, 22 Sep 89 17:09:10 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA17063; Fri, 22 Sep 89 17:10:23 EDT Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA10576; Fri, 22 Sep 89 17:08:42 -0400 Date: Fri, 22 Sep 89 17:08:42 -0400 Message-Id: <8909222108.AA10576@MORPHEUS.MIT.EDU> To: mackay@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU In-Reply-To: 's message of Fri, 22 Sep 89 14:39:10 EDT <8909221839.AA02133@E40-368-1.MIT.EDU> Subject: Error checking From: Date: Fri, 22 Sep 89 14:39:10 EDT Dan suggested that we use a checksum to indicate whether a rule had been created by the ruleeditor. This would give us a way to exit gracefully if the rule doesn't work, rather than seeing: Field Type "Any-Case-Text" does not exist Assertion failed: file al.c: line 46: 0 Illegal instruction What do you think? Wendy Undfortunately this is not dying in the rule editor. It is dying when the rule object is attempting to read in the rule from disk. It cannot create the rule because the FieldTypeRegistry object doesn't recognixe the string. Having the rule language be certain that it created it wouldn't help us. The field type names could still change in the future (but I beleive they shouldn't change much more). Even so, there is the simmilar problem of field operator name changes. So, problem: name changes to constant objects, solution: aliases or versioning. Checksums really wouldn't help us. What we could do more realistically (which is probably what Dan meant) was to version the rules and update the version when we change names. Good idea. Aliases are also not a bad idea, but less clear on how to impliment them... I'll add it to the things to do....(at the bottom somewhere). __Rich.  0,unseen,, Summary-line: 22-Sep rap@ATHENA.MIT.EDU #BUG Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06368; Fri, 22 Sep 89 17:12:59 EDT From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA17203; Fri, 22 Sep 89 17:14:20 EDT Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA10579; Fri, 22 Sep 89 17:12:44 -0400 Date: Fri, 22 Sep 89 17:12:44 -0400 Message-Id: <8909222112.AA10579@MORPHEUS.MIT.EDU> To: mackay@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU In-Reply-To: 's message of Fri, 22 Sep 89 15:03:56 EDT <8909221904.AA02205@E40-368-1.MIT.EDU> Subject: BUG From: Date: Fri, 22 Sep 89 15:03:56 EDT Rich, I just changed everything to "Case Sensitive with Commas as ORs" and got the following: % runrules sifter +inbox Assertion failed: file predeval.c: line 224: 0 Illegal instruction % It managed to move two messages first, though. W BUG isn't the right prognosis--MISSING CODE is. Aparently as new states were added, code was not. Runrules simply cannot handle certain states(!). Pretty shocking I know. I'll get to work on it... __Rich.  1,, Summary-line: 23-Sep jbf@CS.BU.EDU #ACL Call for Papers Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15235; Sat, 23 Sep 89 22:06:06 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA06453; Sat, 23 Sep 89 22:07:36 EDT Received: from BUCSE.BU.EDU by CS.BU.EDU (5.58/4.7) id AA01687; Sat, 23 Sep 89 22:07:56 EDT Received: by bucse.bu.edu (5.31/4.7) id AA15114; Sat, 23 Sep 89 22:08:50 EDT Date: Sat, 23 Sep 89 22:08:50 EDT From: jbf@CS.BU.EDU Message-Id: <8909240208.AA15114@bucse.bu.edu> To: rap@CS.BU.EDU Subject: ACL Call for Papers *** EOOH *** Date: Sat, 23 Sep 89 22:08:50 EDT From: jbf@CS.BU.EDU To: rap@CS.BU.EDU Subject: ACL Call for Papers ACL papers are due by 16 dec. Authors should submit 12 copies of preliminary version of the paper, not to exceed 3200 words (exclusive of references). .. To get a copy of the call for papers you could email walker@flash.bellcore.com Probably he can email a copy of it back to you. The meeting in 6-9 June 1990 in Pittsburgh. Good luck. JF  1,, Summary-line: 25-Sep awa.junet!ti@uunet.UU.NET #I am resending this. Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22309; Mon, 25 Sep 89 01:59:10 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22072; Mon, 25 Sep 89 02:00:03 EDT Received: from kddlab .UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA00027; Mon, 25 Sep 89 01:58:13 -0400 Received: from titcca.cc.titech.junet by kddlab.kddlabs.co.jp (4.0/6.2Junet) id AA22849; Mon, 25 Sep 89 14:49:56 JST Received: by titcca.cc.titech.junet (5.61/6.4J.1) id AA08338; Mon, 25 Sep 89 14:46:13 +0900 Received: by dclsic.dcl.junet (5.51/6.4J.6-DCL/Master) with UUCP id AA03223; Mon, 25 Sep 89 14:10:32+0900 Received: by sjc.yokogawa.junet (5.51/6.4J.5-YOKOGAWA-R/GW) id AA08811; Mon, 25 Sep 89 13:48:57 JST Date: Mon, 25 Sep 89 13:48:57 JST From: kddlab!yokogawa.junet!ti@uunet.UU.NET (Takeshi Inoue) Return-Path: Message-Id: <8909250448.AA08811@sjc.yokogawa.junet> To: roman%athena.mit.edu@kddlab.kddlabs.co.jp Subject: I am resending this. Cc: djf%athena.mit.edu@kddlab.kddlabs.co.jp, jstewart%athena.mit.edu@kddlab.kddlabs.co.jp, motif%athena.mit.edu@kddlab.kddlabs.co.jp *** EOOH *** Date: Mon, 25 Sep 89 13:48:57 JST From: kddlab!yokogawa.junet!ti@uunet.UU.NET (Takeshi Inoue) Return-Path: To: roman%athena.mit.edu@kddlab.kddlabs.co.jp Subject: I am resending this. Cc: djf%athena.mit.edu@kddlab.kddlabs.co.jp, jstewart%athena.mit.edu@kddlab.kddlabs.co.jp, motif%athena.mit.edu@kddlab.kddlabs.co.jp I had sent following message one week ago but it seemed not to reach and returned to me; I do not know why, or did you get that? Anyway, I am sending this again. Could you tell me if you get this mail? I am very sorry to bother you. --------- Hello, how are you? Thank you for everything while I was in Project Athena. I've been working in Tokyo for 2 weeks now. I had a lot of red tape and I am sorry to be late to send this mail. Here I made my comments on Motif. I wrote things I want Motif to be able to do, but I might be misunderstanding something, so, could you tell me if there are ways to do, if I am missing something or if you have any comments? I will be here in the Tokyo office until at least the middle of October and my e-mail address is: ti%yokogawa.junet@uunet.uu.net T.I.'s comments on Motif. 1. concept is very good A new concept fot X-window programming is very good and acceptable. The UIL grammar was easily understood for me. Sometimes, applications and user interfaces cannot be divided perfectly, but fundamentally, they should be divided and developed independently; I appreciate to have introduced this new concept. 2. versatility Widget name and Widget class: Essentially, what programmers can specify in C programms for widgets, should be done also in UIL programms except for some functionalities, i.e. dynamic resource value changing, etc. In terms of that goal, UIL is well designed. I hope there be one other ability. I hope programmers can write widget specs whose number varies according to the environment. For example, when I developed the 'mxfonts', I had to write the font display window creations in C source because the number of available fonts depends on users' environment. Now we can write only fixed number of widgets in UIL files, but I think it is common case to vary the widgets' number depending on the environments or users file contents, e.g. menu items, directory contents display, etc. One can say this part should be in the application and should be written in C, but the other should say it should also be involved in user interface. By introducing new grammar, UIL can manipulate that kind of widgets I guess. 3. UIL's familiality to C applications One big differrence between C and UIL is UIL is name oriented, i.e. a widget is identified by name whereas it is done by widget ID in C. In UIL, different widgets must have different name whereas they can have the same name in C. This difference affects resource files writing. Without UIL, resource values used to be set for plural widgets by a widget name if they have the same name. In this kind of case, they say class names should be used in place of widget names. However, we want set the same name for some part of widgets in the same class. Suppose you make a calendar program and you want to change the color of Sundays and Saturdays different from weekday colors provided all day widgets are in the same class and have same parent. At present, we have to specify each day widgets color in a resource file. If all Sunday widgets can have the same name, we can set the color of the widgets using only one line. I am not sure if this functionality should be realized but I think it is worth discussing. 4. Mamory consuming. As all members of this project should have noticed, all motif programms are very very big. For now, users cannot run motif programms as background processes simultaneously because most of working space is used by them. This serious problem must be solved. The more UIL functions, i.e. 'Mu....', become available in the future, the bigger the size of load modules will be, I am afraid. In addition, performance is also bad especially, widget fetching process takes time a lot. 5. for whom the toolkit is? This is not a question only for Motif but also for all toolkit developers. Do the programmers have to know well about Xlib? Is the toolkit for Xlib experts to facilitate to program? Or, should the toolkit be for programmers who has no or a little knowledge about Xlib? If it is the latter case, what should programmers know about Xlib? 6. Familiarity to programmers The more the number of widget classes exist, the more convenient for programming, but on the other hand, it will get harder for programmers to grasp precise feature of each widget class. Even now I sometimes hesitate which widget I should use, and cannot easily understand the differences between 2 or 3 widgets' characteristics. Documentation should be more easy to read and it should use more diagrams. Widgets experts may be necessary or, expert systems to choose proper widget classes are needed when the number of widgets grows more and more. 7. resource manipulation policy I think the resource management policy is not clear. The motif style guide is for user interface consistency check and there is no such kind of guide specifying how to write C-code, UIL-code and resource files. Sould resource values be written in C, UIL or resource files? Resource values which users are allowed to customize should be written in resource files. For now, in the first phase of development, all resources are specified in C and UIL, and in the secound phase, some of resources are transfered to resource files. Another question is how the motif tools should be distributed. Now most of programms in ..../motif/projects consist of a c-load module and uid files, and most of resource values are fixed. In this case, users cannot change resource values since the values in rosurce files do not override C or UIL. If tools are distributed with a c-load module, uid files and resource files, users have to use 'xrdb' command or 'setenv XENVIRONMENT' command everytime the session starts. 8. I had sent e-mails to motif-bugs for detailed parts. Other detailed comments had been sent to motif-bugs. That's all for now. Thank you for reading. See you again. T.I. -------- This was what I sent you one week ago. So long.  1,answered,, Summary-line: 25-Sep LER-DAEMON@ATHENA.MIT.EDU #Returned mail: User unknown Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA26620; Mon, 25 Sep 89 12:26:29 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29796; Mon, 25 Sep 89 12:27:56 EDT Date: Mon, 25 Sep 89 12:27:56 EDT From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <8909251627.AA29796@ATHENA.MIT.EDU> To: *** EOOH *** Date: Mon, 25 Sep 89 12:27:56 EDT From: Mail Delivery Subsystem Subject: Returned mail: User unknown To: ----- Transcript of session follows ----- >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown ----- Unsent message follows ----- Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29792; Mon, 25 Sep 89 12:27:56 EDT From: Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA12521; Mon, 25 Sep 89 12:26:08 -0400 Date: Mon, 25 Sep 89 12:26:08 -0400 Message-Id: <8909251626.AA12521@MORPHEUS.MIT.EDU> To: walken@flash.bellcore.com Subject: call for papers for ACL meeting of June 1990 I was informed that you could send me a copy of the call for papers (or perhaps email me one). I would greatly appreciate it if you could do so or give my name and address to those people who do. Thank you, Richard Pito 857 Beacon St. #31 Boston, MA 02215 rap@athena.mit.edu or rap@bu-cs.bu.edu  1,, Summary-line: 25-Sep rap@ATHENA.MIT.EDU #in the interest... Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA00704; Mon, 25 Sep 89 16:11:09 EDT Received: from MORPHEUS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA05914; Mon, 25 Sep 89 16:12:35 EDT From: rap@ATHENA.MIT.EDU Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA12575; Mon, 25 Sep 89 16:10:47 -0400 Date: Mon, 25 Sep 89 16:10:47 -0400 Message-Id: <8909252010.AA12575@MORPHEUS.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: in the interest... *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Mon, 25 Sep 89 16:10:47 -0400 To: argus2@ATHENA.MIT.EDU Subject: in the interest... of keeping our development spirit alive I offer you a brief discussion about the resource files of the Argus system: As it currently stands, I have set up the resource file system so that one resource file is opened upon creation of the first Argus X application. This resource file is called 'Argus' and is created in the XDisplayintialize routine (or XInitializeDisplay, I forget). Anyway, I set precedent by having parent X applications (in this case the rule browser) pass the display to their spawned X applications (in this cas the rule editor). It all sounds hunky dory, but it means that all our reource specifications are in one file. Since there is a profile component specifying the location of the 'Argus' file and since I have been making the rule editor reources user modifiable, we should expect users will want to tinker with X resources. This is X. Only problem is that it isn't nice to tinker with and it isn't nice to develope with. (in this scenerio we pass around a Display). There is another approach which would allow us to maintain a resource file for each application. Prehaps they could be called 'Argus-' i.e. 'Argus-ruleeditor'. This would make tinkering and developing a lot easier BUT, it would mean a resource file would have to be read in and interpreted by each spawned Argus X application. Instead of initializing a display once we would do it each time a X application was invoked, that way we could keep seperate resource files. The tradeoff is time. Unfortunatley we can't make a decent decision because I don't know how much time we're looking at. (in this scenerio we pass around an ApplicationContext). I'll at it to the dream list... If anybody feels strongly one way or another PLEASE speak up. This is a programming AND a UI issue. __Rich.  1,, Summary-line: 26-Sep bgardner@ATHENA.MIT.EDU #default: move-to "" Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08859; Tue, 26 Sep 89 03:41:42 EDT Received: from PINK.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA17832; Tue, 26 Sep 89 03:43:13 EDT From: bgardner@ATHENA.MIT.EDU Received: by PINK.MIT.EDU (5.61/4.7) id AA08130; Tue, 26 Sep 89 03:41:21 -0400 Date: Tue, 26 Sep 89 03:41:21 -0400 Message-Id: <8909260741.AA08130@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: default: move-to "" *** EOOH *** From: bgardner@ATHENA.MIT.EDU Date: Tue, 26 Sep 89 03:41:21 -0400 To: argus2@ATHENA.MIT.EDU Subject: default: move-to "" I was experimenting with running rules made by Argus, pretending to be a new user. I came across something (two, actually) which we might want to think abit about. I was considering, "What if someone created a rule and added fields, but didn't delete the default ones (thinking,'if the program put them there, it might be important, so I won't delete them'...this also applies if a user can't figure out how to delete them... which incidently, I actually couldn't figure out!) The results are this: (1) The default rule fired on almost every message in my folder. (2) The move-to "" action attempted to fire on almost every message in my folder. Since it can't move a msg to "" as a folder, it generated an error message (as it should've) on almost every message. We might want to re-think this. I think the predicate firing on everything is probably ok (though, it seems abit scary). The default move-to oblivion action doesn't seem quite right, somehow, though. -- Brian PS: I was unable to figure out how to delete a field at all, even after considerable time of playing with the ruleeditor. When attempting to do logical operators ("and" boxes, "not" boxes, etc) there were no cues that these functions existed (my first problem). Next, I thought, "Well, adding an AND, OR, or NOT box would make the rule more complex", so I tried to create it by clicking on the button marked "Complex". -- I didn't think to click on the button marked "Add", because I didn't want to add anything, I just wanted to group the things I already had. My next problem was that I couldn't get the Logical operators submenu to popup...until Rich showed me how. (Rich said its a Motif "feature", not a bug...so we may be screwed here). Then, I could not place a box. I clicked for the left corner on the box, and then it went away and didn't come back. This I didn't figure out, but apparently, I was supposed to "drag" the mouse to see the elastic box and place the other corner...there was no visual clue that I was supposed to do this, however...nor was there any visual clues as to why it failed (which would've enabled the user to realize what s/he did wrong the first time and retry it sucessfully the second time...so the user who doesn't figure it out the first is doomed to never know. ) Next, after I did *KNOW* how to make & place the box, I couldn't do it. (It took me 7 tries to succeed). rich says that this is a bug which will go away soon. After I made several of these boxes, the ruleeditor died mysteriously. I'll try playing user again in a couple days, but I just wanted everyone to know the results of my first try. It could be that in some sense I'm a more naive user than more ("alittle bit of knowledge being a dangerous thing") typical users, but I suspect they'll have at least afew of the same problems. We might want to hash out abit of this before it goes out on a release tape.  1,, Summary-line: 26-Sep bgardner@ATHENA.MIT.EDU #Re: runrules, predeval, etc Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08898; Tue, 26 Sep 89 03:49:42 EDT Received: from PINK.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA17870; Tue, 26 Sep 89 03:51:13 EDT From: bgardner@ATHENA.MIT.EDU Received: by PINK.MIT.EDU (5.61/4.7) id AA08145; Tue, 26 Sep 89 03:49:25 -0400 Date: Tue, 26 Sep 89 03:49:25 -0400 Message-Id: <8909260749.AA08145@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Re: runrules, predeval, etc *** EOOH *** From: bgardner@ATHENA.MIT.EDU Date: Tue, 26 Sep 89 03:49:25 -0400 To: argus2@ATHENA.MIT.EDU Subject: Re: runrules, predeval, etc Just to clearify... The missing code to which Rich is referring is not missing from "runrules". It is missing from other code, called by code, which is called by code, which is called by runrules. (i.e. in the predicate evaluation code). I am currently testing the new runrules, and expect that it will be placed in the 0.6 bin sometime tomorrow (er...well, "today" technically... its 4:00am again...my how time flies ... :-) -- Brian  1,, Summary-line: 26-Sep bgardner@ATHENA.MIT.EDU #runrules and rulebrowser are in working/src Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09364; Tue, 26 Sep 89 06:47:25 EDT Received: from PINK.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA18746; Tue, 26 Sep 89 06:48:58 EDT From: bgardner@ATHENA.MIT.EDU Received: by PINK.MIT.EDU (5.61/4.7) id AA09751; Tue, 26 Sep 89 06:47:11 -0400 Date: Tue, 26 Sep 89 06:47:11 -0400 Message-Id: <8909261047.AA09751@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: runrules and rulebrowser are in working/src *** EOOH *** From: bgardner@ATHENA.MIT.EDU Date: Tue, 26 Sep 89 06:47:11 -0400 To: argus2@ATHENA.MIT.EDU Subject: runrules and rulebrowser are in working/src The new runrules (fully completed) is now in working/source and should be in 0.6 after the next compilation. The new rulebrowser has all of the functionality of the old rsedit, plus quite abit, and has also been moved into the working/src directory soon to be in 0.6. The "move rule" feature (the hand icon) is NOT implimented in this version. (But, then, that functionality didn't exist in "rsedit", either. So, I feel ok about moving into the working src directory for use.) I didn't test these programs as thoroughly as I usually do. (Though, I did test them quite abit.) So, please bang on them abit. You may wish to test out the "-o" option to runrules. For example: runrules -o ruleset +inbox | zwrite myself & Also, the error messages has been considerably improved. -- Brian PS: Its 7:00am ...I can't believe I'm still here! -- Yuck.  1,answered,, Summary-line: 26-Sep friedman@HARVARD.HARVARD. #Knowledge Representation Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA16680; Tue, 26 Sep 89 15:54:42 EDT Received: from CS.BU.EDU by ATHENA.MIT.EDU with SMTP id AA28902; Tue, 26 Sep 89 15:56:15 EDT Received: from BUCSF.BU.EDU by CS.BU.EDU (5.58/4.7) id AA02347; Tue, 26 Sep 89 15:56:24 EDT Received: from CS.BU.EDU (cs.bu.edu.ARPA) by bucsf (4.12/4.7) id AA21408; Tue, 26 Sep 89 15:55:41 edt Received: from HARVARD.HARVARD.EDU by CS.BU.EDU (5.58/4.7) id AA02339; Tue, 26 Sep 89 15:56:17 EDT Message-Id: <8909261956.AA02339@CS.BU.EDU> Received: by harvard.harvard.edu (5.54/a0.25) (for rap@bucsf.bu.edu) id AA18158; Tue, 26 Sep 89 15:55:40 EDT Received: by endor.HARVARD.EDU; Tue, 26 Sep 89 15:55:23 EDT Date: Tue, 26 Sep 89 15:55:23 EDT From: friedman@HARVARD.HARVARD.EDU (Joyce Friedman) To: rap@ATHENA.MIT.EDU, rap@CS.BU.EDU, rap%bucsf.BU.EDU@CS.BU.EDU Subject: Knowledge Representation *** EOOH *** Date: Tue, 26 Sep 89 15:55:23 EDT From: friedman@HARVARD.HARVARD.EDU (Joyce Friedman) To: rap@ATHENA.MIT.EDU, rap@CS.BU.EDU, rap%bucsf.BU.EDU@CS.BU.EDU Subject: Knowledge Representation From friedman Tue Sep 26 15:53:30 1989 Date: Tue, 26 Sep 89 15:53:20 EDT From: MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: User unknown To: friedman Status: R ----- Transcript of session follows ----- 550 rap... User unknown ----- Unsent message follows ----- From: friedman (Joyce Friedman) To: rap Subject: Knowledge Representation I have talked around about this and have found the following: U. Toronto has Hector Levesque and Ray Reiter. Both are very good. Toronto is overall a first-rate department. Rochester has James Allen, and is overall pretty good. Brown has Tom Dean in KR. He will give a colloq here at Harvard at 4pm on Oct 26, so you can see for yourself. Now that you know how to find Aiken. Don Perlis was also mentioned, but don't know where he is. Incidentally, John McCarthy of Stanford will give the colloq on Oct 2. He is worth seeing and hearing. 4pm Aiken.  1,, Summary-line: 26-Sep jstewart@ATHENA.MIT.EDU #focus mtg on motif development Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA18794; Tue, 26 Sep 89 17:55:35 EDT Received: from FUTURE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA02295; Tue, 26 Sep 89 17:56:57 EDT Received: by FUTURE.MIT.EDU (5.61/4.7) id AA03233; Tue, 26 Sep 89 17:55:07 -0400 Message-Id: <8909262155.AA03233@FUTURE.MIT.EDU> To: yaypoo@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU, phils@ATHENA.MIT.EDU, vanharen@ATHENA.MIT.EDU, djpan@ATHENA.MIT.EDU, jmooi@ATHENA.MIT.EDU, timo@ATHENA.MIT.EDU, vagarwal@ATHENA.MIT.EDU, hvega@ATHENA.MIT.EDU, dpmcnagg@ATHENA.MIT.EDU, djpan@ATHENA.MIT.EDU Cc: jstewart@ATHENA.MIT.EDU, roman@ATHENA.MIT.EDU Subject: focus mtg on motif development Date: Tue, 26 Sep 89 17:55:00 EDT From: Jacqueline A. Stewart *** EOOH *** To: yaypoo@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU, phils@ATHENA.MIT.EDU, vanharen@ATHENA.MIT.EDU, djpan@ATHENA.MIT.EDU, jmooi@ATHENA.MIT.EDU, timo@ATHENA.MIT.EDU, vagarwal@ATHENA.MIT.EDU, hvega@ATHENA.MIT.EDU, dpmcnagg@ATHENA.MIT.EDU, djpan@ATHENA.MIT.EDU Cc: jstewart@ATHENA.MIT.EDU, roman@ATHENA.MIT.EDU Subject: focus mtg on motif development Date: Tue, 26 Sep 89 17:55:00 EDT From: Jacqueline A. Stewart I am trying to arrange a focus meeting with Motif developers & our Watzman & Keyes graphics designers consultants. It will last two hours. Proposed times are a two hour block between 1 & 4 pm either this friday, 29 Sept OR Monday, 2 Oct OR Friday 6 Oct. Students will get paid for attendance (submit timecard). Please indicate your availability in the form below (Type 'X' as appropriate) )& return to me. Your input is very important. Also, any of you that can help implement some cleanup changes to the programs before we ship to OSF (code cutoff here is ~ 9 Oct) pls. advise me ASAP; else we will have to touch your code. ------------------------- Can't come at all: Please indicate all you are available for. We will only schedule a single 2 hr block. Prefer: Fri 29 Sept Mon 2 Oct Fri 6 Oct 1 pm 2 pm 3 pm --------------------------------- Thank you for your attention, Jackie Stewart  1,, Summary-line: 26-Sep mackay@ATHENA.MIT.EDU #Rule Browser Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20554; Tue, 26 Sep 89 19:46:45 EDT Received: from E40-368-1.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA04689; Tue, 26 Sep 89 19:48:16 EDT From: mackay@ATHENA.MIT.EDU Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA20244; Tue, 26 Sep 89 19:46:26 -0400 Message-Id: <8909262346.AA20244@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Rule Browser Date: Tue, 26 Sep 89 19:46:22 EDT *** EOOH *** From: mackay@ATHENA.MIT.EDU To: argus2@ATHENA.MIT.EDU Subject: Rule Browser Date: Tue, 26 Sep 89 19:46:22 EDT Just tried the rule browser in /src/bardner (didn't find one in 0.6). It looks as though you're using the third (far right) mouse button to select -- this doesn't match anything else. It should be consistently first (left) mouse button to select. (Also, does it grab control of everything? All my other windows on the screen were frozen.) W  1,, Summary-line: 26-Sep mackay@ATHENA.MIT.EDU #default rule Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22421; Tue, 26 Sep 89 22:11:21 EDT Received: from E40-368-1.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA07327; Tue, 26 Sep 89 22:12:56 EDT From: mackay@ATHENA.MIT.EDU Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA20356; Tue, 26 Sep 89 22:11:07 -0400 Message-Id: <8909270211.AA20356@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: default rule Date: Tue, 26 Sep 89 22:11:04 EDT *** EOOH *** From: mackay@ATHENA.MIT.EDU To: argus2@ATHENA.MIT.EDU Subject: default rule Date: Tue, 26 Sep 89 22:11:04 EDT I noticed that the DefaultRuleMessageType in lens.profile.1.1 specifies "MSG" rather than "RULE". We created "RULE" so that it wouldn't have extraneous fields (especially FROM:). Now the question is, which fields should the RULE message type have? It currently lists: To: Subject: as the fields most commonly used in rules. One could argue that a better one would be: To: Cc: Date: Subject: But this has the disadvantage of requiring people to delete more extraneous fields. What do you think? Wendy  1,, Summary-line: 26-Sep mackay@ATHENA.MIT.EDU #"lens" profile Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22889; Tue, 26 Sep 89 22:36:41 EDT Received: from E40-368-1.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA07849; Tue, 26 Sep 89 22:38:13 EDT From: mackay@ATHENA.MIT.EDU Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA20388; Tue, 26 Sep 89 22:36:22 -0400 Message-Id: <8909270236.AA20388@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: "lens" profile Date: Tue, 26 Sep 89 22:36:18 EDT *** EOOH *** From: mackay@ATHENA.MIT.EDU To: argus2@ATHENA.MIT.EDU Subject: "lens" profile Date: Tue, 26 Sep 89 22:36:18 EDT I just created argusprofile.1.0, which removes references to lens and has some more comments about what each profile component does. I placed the "not supported in this release" items, as well as the anyone server items, at the bottom of the file. We should consider removing these. Somebody needs to: Change LensDirectory to ArgusDirectory. Check my comments. Check that the "not supported" items are really not supported. (and that the ones I left in are). Also, we need to change whatever file looks for lens.profile. Wendy  1,, Summary-line: 27-Sep roman@ATHENA.MIT.EDU #motif and uil (long) Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25540; Wed, 27 Sep 89 08:49:20 EDT Received: from E40-381-3.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA12826; Wed, 27 Sep 89 08:49:58 EDT Received: by E40-381-3.MIT.EDU (5.61/4.7) id AA11582; Wed, 27 Sep 89 08:48:08 -0400 Message-Id: <8909271248.AA11582@E40-381-3.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: motif and uil (long) Date: Wed, 27 Sep 89 08:48:06 EDT From: Roman J. Budzianowski *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: motif and uil (long) Date: Wed, 27 Sep 89 08:48:06 EDT From: Roman J. Budzianowski ------- Forwarded Message UIMS Working Group Meeting Minutes List of Attendees at the UIMS Working Group meeting: Michael Maggio Nixdorf decvax!linus!nixbur!maggio Kevin Brophy Nixdorf decvax!linus!nixbur!brophy Ross Faneuf Digital uunet!decwrl.dec.com!faneuf%rtl.DEC Patrick Daly Concurrent uunet!masscomp!daly Shap Shapiro Sequent sequent!shap Frank Hall HP frank@hpcvix.hp.com Abbas Birjandi OSF abbase@osf.org Catie Watson McDonnell Douglas uunet!mdcbbs!watson John Amason Landmark Graphics uunet!jma!jma Mike Pinette Digital Karl Wolf Century Computing (vendor) Marti Szcur NASA/GSFC (vendor) David Flanagan MIT Project Athena Roman Budzianowski MIT Project Athena roman@athena.mit.edu Martin Cody Caset Corportion (vendor) Terry Palmer Caset Corportion (vendor) Ken Faubel HP/Apollo faubel@apollo.com Ludwig Zink Siemens uunet!unido!siuix!zink Charles White Cadlab/Nixdorf chas@cadlab.de Kent Lundberg Telelogic kent@progys Andrew Dove Landmark Graphics uunet!lgc!andrew Jon Siegel Shell Development siegel@shell.com Mark Antionelli ICS mark@ics.com Mitch Trachtenberg OSF mitch@osf.org Scott Smith Digital Huy Lien IBM uunet!ibmswpt!hclien Mike Foody Visual Edge (vendor) John Spencer Visual Edge (vendor) Jacques Davy Bull davy@my.bull.fr Vania Joloboff OSF vania@osf.org Summary of UIMS Working Group Findings & Recommendations It is the recommendation of the UIMS working group that the OSF incorporate only those changes of the "Proposals for UIL/Mrm Futures" document, organized by Ellis Cohen, that were identified by the working group as approriate. The following is an edited version of that document. Proposals for Uil/Mrm Futures Futures for Uil/Mrm are organized into the following categories: - UIL Source Code Clarity - Straightforward additions to allow more radable UIL source. - Direct Extensions -- These are straightforward additions to sujpport the existing Motif toolkit. - Power & Expressiveness -- These are major extensions which would significantly extend the power and expressiveness of UIL - Binding Time -- These extensions would provide flexibility in the time and ways in which resource values are bound - Performance - Software Engineering UIL Source Code Clarity ----------------------- Allow names to be assigned to objects wherever they are defined. Objects defined in UIL without explicit names should have names composed form their parent, class and order within their parent's definition. Support deferred creation of subtrees (with parent specified). Application startup time can be reduced by fetching at startup only those widgets which are needed immediately. In the present UIL, subtree fetching may be deferred only by not listing the top of a subtree in the controls list of any parent. There is no provision in UIL for indicating the intended parent of a subtree without causing that subtree to be fetched together with its parent. A "deferred" keyword would enable the UIL programmer to cleanly show the application hierarchy without sacrificing the speed advantage of deferred fetching. Direct Extensions ----------------- Provide support for a character type. Motif has character resources (XmNmnemonic) which must currently be entered in UIL as an integer. Use $LANG to specify to the UIL compiler teh base chanracter set in which a UIL file is written, and thus the byte encoding to be used when reading it. Provide support for all character sets specified by the X Consortium for use with Compound Text. Provide UIL syntax for specifying a top-level shell, including support for multiple application contexts, and multiple displays. (The viability of including this enhancement is to be investigated by the OSF) Power & Expressiveness ---------------------- Allow use of resolution modifiers in specifying integers and floating point literal (inches, mms, fontunits). (This enhancement was to be provided if resolution modifiers are specified in the toolkit) Binding Time ------------ Enhance X defaults / UIL / UID format interoperability: Support UIL compiler output of selected information (e.g. based on specified subtree & resources) as X defaults information. Provide tools that convert (selected information) between UIL/UID format and X defaults format. Performance ----------- Decrease the minimum size of UID files. The present UIL implementatin always uses a large miniumum buffer size and outputs several buffers for even teh smalestg UIL file. The result is that timy interfaces yield large, sparesely populated UID files. Separate modules so that functions which write uid files are not linked with applications. Mrm is bulit on an indexed database facility which has both read and write capability. The write capability is never used by the current Mrm implementation, and there is no reason to link its code. Software Engineering -------------------- Improve error messages. Support a verbose mode for the compiler, providing information specifically suited to helping locate the cause of crashes when porting UIL. It is also recommended that the OSF adopt the description of UIL that Ross Faneuf offered at the previous SIG meeting ( the description was modified by the working group and is the version included in this summary) [ A copy of that description should be included here] Again, it is the recommendation of the UIMS Working Group that the OSF communicate to the UIMS Working Group its intentions regarding the recommendations outlined above. The working group stands ready to assist with futher discussion on any of the issues and welcomes any feedback. UIMS Working Group Plans Two subcommittees were organized to study and present finding at the next UIMS working group meeting (probably JAN 18th & 19th) the following: - IDT interchange format - UIL futures The members of the IDT subcommittee included: Ross Faneuf Mitch Trachtenberg Scott Smith Abbas Birgandi Mark Antonelli Shap Shapiro Jody Roberts Mike Foody (vendor) (subcommittee leader) - this may not be allowed or desired Marti Szczer (vendor) - this may not be allowed or desired Terry Palmewr (vendor) - this may not be allowed or desired The members of the UIL subcommittee included: Mitch Trachtenberg Scoot Smith ( subcommittee leader ) Catie Watson Abbas Birjandi Judy Roberts Mike Foody ( vendor) this may not be allowed or desired Vendor's that incorporate dialog management in their products will be invited to present an architectural overview of their product, discuss the pro's and con's of dialog management, and join in a working group discussion addressing the merits of providing dialog management for Motif, when, and how. Organize a Dialog management BOF for the UIST conference. Coordinate with the UEC Internationalion working group to insure that the requirements they define are consistant with present and planned implementations of UIL. The preliminary agenda for September UIMS Working Group meeting is as follows: Review the latest release of UIL and its enhancements Review OSF response to the UIMS Working Group recommendations UIMS vendor presentations on dialog management ( vendors that have express an interest in presenting are Visual Edge, Seimens, TeleLogic, and HP/Apollo) Discuss with vendors dialog management Presentation of IDT subcommittee findings Presentation of UIL subcommittee findings Develop list of recommendations Develop plan for future meetings Raveling Dialog form from the UIMS Working Group meeting A block diagram showing the input files and generated output files associated with the new UIL compiler compiler was described by Vania Joloboff. The new compiler will be available for members before the November members meeting. Vania indicated that the OSF believes that the issues of a UIL test suite, portability, QA, and naming convention issues ( issues oultined in the June '89 UIMS working group meeting minutes) are being adequately addressed. Vania also indicated that the OSF was continuing to work on the follwing two problems: - generation of a unique id number used in the uid file - development of MrmInitialize, a function for selective loading of widgets Presentations by IDT vendors Nixdorf, NASA/GSFC, Visual Edge, and Caset were then given. UIL is a presentation language The working group is still concerned that the OSF describes UIL using language tha tsuggest it can be extended to provide support for IDT's and UIMS's - a fact not yet proven to be true. UIL is part of Motif Stability is an inportant factor that UIL must demonstrate before inclusion in the AES should be considered. UILK is userful as a base level support for Motif. Mrm is superior to xrm. There was little interest in contiuing to extend UIL, rather a new language with UIL compatiblity should be developed. The working group should focus on the requirements of a new language - not on extending UIL. ------- End of Forwarded Message  1,, Summary-line: 27-Sep geer@ATHENA.MIT.EDU # Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25819; Wed, 27 Sep 89 09:22:00 EDT Received: from E40-342F-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA13179; Wed, 27 Sep 89 09:22:32 EDT From: geer@ATHENA.MIT.EDU Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA28957; Wed, 27 Sep 89 09:20:44 -0400 Message-Id: <8909271320.AA28957@E40-342F-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Date: Wed, 27 Sep 89 09:20:41 EDT *** EOOH *** From: geer@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Date: Wed, 27 Sep 89 09:20:41 EDT ------- Forwarded Message Received: by E40-PO.MIT.EDU (5.45/4.7) id AA10837; Mon, 25 Sep 89 20:37:26 EDT Received: from EXPO.LCS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA11995; Mon, 25 Sep 89 20:39:00 EDT Received: from expire.lcs.mit.edu by expo.lcs.mit.edu; Mon, 25 Sep 89 20:27:01 EDT Received: by expire.lcs.mit.edu; Mon, 25 Sep 89 20:26:59 EDT Message-Id: <8909260026.AA00413@expire.lcs.mit.edu> To: xpert@EXPO.LCS.MIT.EDU Subject: Call for Participation in the 4th Annual X Technical Conference Date: Mon, 25 Sep 89 20:26:57 -0400 From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler) The 4th annual Technical Conference on the X Window System will be held on January 15-17, 1990 at the Marriott Copley Place Hotel in Boston, MA. The conference, sponsored by the MIT X Consortium, will bring together experts from industry and academia to present and discuss leading edge research and development in the X environment. This is an ideal opportunity to learn about the very latest X technology, and to talk individually with a variety of developers. As with last year, there will be tutorials on the first day. If you are interested in giving a tutorial, please contact us. We are particularly interested in topics which have not been given before, or which have had only limited attendance. Tutorials on commerical products are allowed, although we reserve the right to have the material "(un)slanted" appropriately for the conference. The second two days will be devoted to talks, in a single track. Presentations can be anywhere from 5 to 50 minutes, and video tape is welcome. Written papers are welcome, but not required; but, we would like to reproduce any slides and written materials in advance for distribution at the conference. There is no set "theme" for the conference; we are interested in submissions covering all aspects of X. Presentations on both research and commercial developments are welcome. On all three days, there will be "Birds of a Feather" sessions for general discussion of areas of specific interest to the attendees. If there are particular BOFs you would like to see or run, please let us know. As usual, there will no "trade show" attached to this conference. If you would like to give a tutorial, make a presentation, or run a BOF, send details to: xconference@expo.lcs.mit.edu or Bob Scheifler Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139 Network mail is preferred. Please include your name, net and postal address, phone number, affiliation, a reasonably detailed outline of what you want to present, what your relationship is to the work (e.g. project manager, principal designer, lead engineer, me-myself-and-I), how much time you need, and what A/V facilities you need. The deadline for submissions is November 17; receipt will be acknowledged. However, we will not wait for this deadline before making decisions on tutorials, so the earlier you get your tutorial proposal in, the better your chances are. Due to the costs of holding the conference off campus (we've outgrown MIT's facilities), there will be a registration fee of $50, covering the entire conference (this is not to make a profit, but to keep the X Consortium subsidy within reason). Exceptions will be made for students who cannot afford the fee. Since there will be a fee this year, registration will not be handled by electronic mail. Please do *not* send inquiries about registration yet; we'll send out registration and hotel information a little later. However, if you believe your network mail is unreliable and are concerned that you might not see later announcements in this forum, you can be placed on a mailing list to receive information by post by writing to: X Technical Conference c/o MIT Conference Services Room 7-111 77 Massachusetts Ave Cambridge, MA 02139 ------- End of Forwarded Message  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA04227; Wed, 27 Sep 89 18:31:18 EDT Received: from FRIES.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA25827; Wed, 27 Sep 89 18:31:58 EDT Received: by FRIES.MIT.EDU (5.61/4.7) id AA17740; Wed, 27 Sep 89 18:29:37 -0400 Message-Id: <8909272229.AA17740@FRIES.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: sysdev@ATHENA.MIT.EDU From: Chris VanHaren Subject: XOLC is now ready for testing. Date: Wed, 27 Sep 89 18:29:30 EDT Sender: vanharen@ATHENA.MIT.EDU *** EOOH *** To: staff@ATHENA.MIT.EDU Cc: sysdev@ATHENA.MIT.EDU From: Chris VanHaren Subject: XOLC is now ready for testing. Date: Wed, 27 Sep 89 18:29:30 EDT Sender: vanharen@ATHENA.MIT.EDU Hello all! After many hours of banging, retuning, and recoding, I have wound up with what I believe is close to what "xolc" will finally be. I would appreciate any testing that you may be able to do on it. You can run it by typing: attach motif /mit/motif/${hosttype}bin/xolc It is available on the RT and VAX platforms. Motif does not yet run on the decmips platform (XUniqueContext undefined or something...). For those of you who haven't heard of it yet, xolc is: - the X-based interface to OLC, the On-Line Consulting program. - what I've been working on most of the summer. - built using the Motif toolkit from OSF. - not yet perfect. RE: that last line -- here are the things that I know are still wrong with it: - if you already have an active instance "0" in olc when you start up xolc, you will continue with that instance. If you wish to ask another question (and you are allowed to do so), you will not be able to. There is not a good resolution to this problem yet. For consultants and volunteers, wait for the xolcr client. Normal users are not allowed to have more than one question (for now). - speed. Always an issue. I am working on making startup faster. The first time you use it, it can take 30 seconds or so to start. After that, the AFS cache helps, but even so, I am trying to make it faster. No guarantees, though. - if you select text in a text widget, then scroll so that the highlighted text is off-screen, then scroll back, it is not always redrawn (highlighted) correctly. This is a bug with the Motif toolkit. I am still trying to track down the exact cause. - Highlighting in general is weird. If you make a selection, with one of the following: - double-click: select word. - triple-click: select line. - quad-click: select entire buffer. - drag left-mouse-button: area of drag. it actually makes the selection, it just may not be displayed correctly. You can paste into other windows, though. - Pasting into a motif text widget is slightly different. You paste with the middle-button, but the text will be pasted at the point where the MOUSE cursor is, not the text cursor. This is standard Motif behavior. Don't expect it to change any time soon. - The text widgets have auto-wrap enabled, which makes things look nice on-screen. However, when you send the message, it is sent as one big long string. This is handled fine if you are viewing the replay from xolc, as the replay text widget will wrap, too. However, it looks awful on a tty display. I'll probably end up parsing the text into lines myself, but this has not yet been done. - If you "cancel" or "done" your question, you are forced to leave the application (after receiving notice that your request was successful). This should probably not be the default behavior. Instead the user should be asked if he would like to quit OLC. If not, the user would be able to use the "save log" feature, or even continue sending messages to the consultant. - The cursor in some of the dialog boxes is the standard "X" cursor (under uwm -- under mwm it works fine!). This is an easy fix, to be done soon. - The "send" window should have a "include file" button on it, to allow users to easily insert a file into the send buffer. Should be easy to implement. For now, insert using cut&paste (note different method of pasting, above). - The fonts for things will be changing, soon. This is to conform to the "Athena standard" for motif programs. We will be shipping everything back to OSF, and we want our programs to "look alike". This is a trivial change to the resource file. The icon will be changing as well. - No man page (yet). It shouldn't really need one, though. It's a point-and-click interface, after all. And, there is context-sensitive help available. So, then, here's what I want to know from you all... what do you think? What do you like? What would you like to see different? What features would you like to see added? How's the layout of the screen(s)? How should the scrollbar behave? Found any bugs (I'd appreciate core dumps if you can reproduce it...) ? Whatever you can think of. Let me hear it. This is being considered for the spring release, so if you have comments, get them in now. Send mail to me (vanharen@athena.mit.edu). I'll try to set up some place to put the messages I receive... a discuss meeting or something. Bang away! -Chris.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09151; Wed, 27 Sep 89 23:11:56 EDT Received: from E40-368-1.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA01210; Wed, 27 Sep 89 23:13:35 EDT From: mackay@ATHENA.MIT.EDU Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA00647; Wed, 27 Sep 89 23:10:58 -0400 Message-Id: <8909280310.AA00647@E40-368-1.MIT.EDU> To: bgardner@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: Re: Down to the wire Date: Wed, 27 Sep 89 23:10:57 EDT *** EOOH *** From: mackay@ATHENA.MIT.EDU To: bgardner@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: Re: Down to the wire Date: Wed, 27 Sep 89 23:10:57 EDT Brian and Rich, re: -help ... I just hadn't been able to get to the rulebrowser, so I hadn't seen the new help stuff. I just tried it now and it looks great. (I'll add it to the documentation.) I want to thank both of you again for the work you've each done to make user interface changes easier. The -help format, the messages file and the argus resources have made it much easier to edit and makes everything look much more professional. This has been one hell of a project and I think you both deserve alot of credit for pulling it off under trying circumstances. Hundreds of people will see Argus, so I think you'll find the effort worthwhile. Wendy  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA10865; Thu, 28 Sep 89 02:58:56 EDT Received: from E40-368-1.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA04170; Thu, 28 Sep 89 03:00:30 EDT From: mackay@ATHENA.MIT.EDU Received: by E40-368-1.MIT.EDU (5.61/4.7) id AA01045; Thu, 28 Sep 89 02:58:31 -0400 Message-Id: <8909280658.AA01045@E40-368-1.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Error messages Date: Thu, 28 Sep 89 02:58:26 EDT *** EOOH *** From: mackay@ATHENA.MIT.EDU To: argus2@ATHENA.MIT.EDU Subject: Error messages Date: Thu, 28 Sep 89 02:58:26 EDT I got a chance to look at some error messages when I tried to run Argus with the new profile. Is there a central place for error messages for runrules? I'd like to suggest some changes. For example, instead of: runrules :: Error in Rule Set. Bad rule set file specified: sifter How about: runrules :: Error in ruleset. Could not find the ruleset named sifter in /mit/mackay/argus/rulesets. By the way, I've been using "ruleset" as one word throughout the documentation. Wendy  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA26762; Fri, 29 Sep 89 03:36:21 EDT Received: from PINK.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA27053; Fri, 29 Sep 89 03:38:06 EDT From: bgardner@ATHENA.MIT.EDU Received: by PINK.MIT.EDU (5.61/4.7) id AA00824; Fri, 29 Sep 89 03:36:08 -0400 Date: Fri, 29 Sep 89 03:36:08 -0400 Message-Id: <8909290736.AA00824@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: Ruleeditor *** EOOH *** From: bgardner@ATHENA.MIT.EDU Date: Fri, 29 Sep 89 03:36:08 -0400 To: rap@ATHENA.MIT.EDU Subject: Ruleeditor I am unable to create new rules with the ruleeditor. The rule being returned by the save function has a bogus predicate. Also, any efforts to group fields will wipe their values. And several combinations of grouping have bombed the ruleeditor. -- Brian  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA28031; Fri, 29 Sep 89 09:30:12 EDT Received: from E40-391-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA28834; Fri, 29 Sep 89 09:30:34 EDT From: frederpa@ATHENA.MIT.EDU Received: by E40-391-2.MIT.EDU (5.61/4.7) id AA01253; Fri, 29 Sep 89 09:28:38 -0400 Message-Id: <8909291328.AA01253@E40-391-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Meetings on Print Quota and Release Date: Fri, 29 Sep 89 09:28:34 EDT *** EOOH *** From: frederpa@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: Meetings on Print Quota and Release Date: Fri, 29 Sep 89 09:28:34 EDT There will be meetings on Release and Print Quota on Tuesday, October 3rd, as follows: Release Meeting: From 11:00-12:00 in Conference Room 382. Print Quota Meeting: From 3:30-5:00 in Conference Room 382. All staff are invited. Please review the documentation for these two meetings prior to attendance. You can pickup documents from Dan Geer in room 342F.--------  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06468; Fri, 29 Sep 89 17:22:48 EDT Received: from [18.72.0.86] by ATHENA.MIT.EDU with SMTP id AA09934; Fri, 29 Sep 89 17:01:02 EDT From: rap@ATHENA.MIT.EDU Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA14191; Fri, 29 Sep 89 16:58:59 -0400 Date: Fri, 29 Sep 89 16:58:59 -0400 Message-Id: <8909292058.AA14191@MORPHEUS.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: well, I've had it... *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Fri, 29 Sep 89 16:58:59 -0400 To: argus2@ATHENA.MIT.EDU Subject: well, I've had it... I'm done wrestling today untill Sunday, I'm mucho tired and there are some mighty weird bugs still in the rule editor. One is motif functionality that I'm trying to get around. When you change a field from simple to complex or back the focus gets changed from widget to widget due to my remaking of the tab groups so you can move correctly around the screen with the new complex field there (or new simple field there). The problem is, as I redo the tab groups motif is sending out focusIn events whioch are no problem except that the last one they do is incomplete in some way and keyboard traversal is dead untill, get this, you use the mouse to popup a menu. I'm not done yet and am, I feel, very close to a workaround, I just won't do it today (my plan is to send an enterwindow event to simulate the menu action, as if you care). The second bug is a douzy. I've been hung on it for a day. The data of the 3rd field in the IF part is getting corrupted somehow. I can't get saber to accept our code. Toby had a workaround but I don't know it. Whewhh. I'm not happy, mostly becuse I could have not even come in today (at 6am) and things would be the same as they are now. Sigh. __Rich. Ahm, you can get around the first bug by immediatly deleting the third field. I'll put the code in working src and set it to compile but I can't stay to move it into vaxbin. __Rich  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA06645; Fri, 29 Sep 89 17:37:40 EDT Received: from KLEE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA10568; Fri, 29 Sep 89 17:33:14 EDT From: beth@ATHENA.MIT.EDU Received: by KLEE.MIT.EDU (5.61/4.7) id AA09754; Fri, 29 Sep 89 17:31:17 -0400 Date: Fri, 29 Sep 89 17:31:17 -0400 Message-Id: <8909292131.AA09754@KLEE.MIT.EDU> To: rfrench@ATHENA.MIT.EDU, sethg@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: looking for Mandelbrot or Julia set generating programs *** EOOH *** From: beth@ATHENA.MIT.EDU Date: Fri, 29 Sep 89 17:31:17 -0400 To: rfrench@ATHENA.MIT.EDU, sethg@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: looking for Mandelbrot or Julia set generating programs A user has asked Consulting how he can locate Mandelbrot or Julia set generating programs on Athena, but we don't know. If you know, would you please get back to him (mbgordy@athena) cc me, or let me know so I can pass it along to him? Thank you! -- Beth ------------------------------------------------------------------------------ ref: Question: I'm interested in chaos simulations. Are there any Mandelbrot or Julia set generating programs available on Athena? In general, what is a good way to find out about user-written software on the network, particularly graphics software?  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08418; Fri, 29 Sep 89 19:44:14 EDT Received: from PINK.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA13127; Fri, 29 Sep 89 19:46:00 EDT From: bgardner@ATHENA.MIT.EDU Received: by PINK.MIT.EDU (5.61/4.7) id AA01327; Fri, 29 Sep 89 19:44:03 -0400 Date: Fri, 29 Sep 89 19:44:03 -0400 Message-Id: <8909292344.AA01327@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: Bug in re_UpdateTitle *** EOOH *** From: bgardner@ATHENA.MIT.EDU Date: Fri, 29 Sep 89 19:44:03 -0400 To: rap@ATHENA.MIT.EDU Subject: Bug in re_UpdateTitle I just used re_UpdateTitle for the first time, and found that it doesn't work. It seems not to do anything at all. I put a trace on it and got: Rulebrowser: calling re_UpdateTitle(1299968, "Ruleset: demorules, Rule #2"); Rulebrowser: calling re_UpdateTitle(1504256, "Ruleset: demorules, Rule #3"); Rulebrowser: calling re_UpdateTitle(1299968, "Ruleset: demorules, Rule #1"); Rulebrowser: calling re_UpdateTitle(1504256, "Ruleset: demorules, Rule #2"); Rulebrowser: calling re_UpdateTitle(1299968, "Ruleset: demorules, Rule #1"); Rulebrowser: calling re_UpdateTitle(1504256, "Ruleset: demorules, Rule #2"); So, I know that I am calling it, and passing it sensible values. But the label does seem to be updating at all. Could you check into this? (Oh, in the above trace, rules #3 and #4 trickle up the ruleset into positions #1 and #2 respectively.) -- Brian  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA08904; Fri, 29 Sep 89 20:29:35 EDT Received: from PINK.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA13794; Fri, 29 Sep 89 20:31:18 EDT From: bgardner@ATHENA.MIT.EDU Received: by PINK.MIT.EDU (5.61/4.7) id AA01453; Fri, 29 Sep 89 20:29:20 -0400 Date: Fri, 29 Sep 89 20:29:20 -0400 Message-Id: <8909300029.AA01453@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: Oooops!! I screwed up. *** EOOH *** From: bgardner@ATHENA.MIT.EDU Date: Fri, 29 Sep 89 20:29:20 -0400 To: rap@ATHENA.MIT.EDU Subject: Oooops!! I screwed up. Sorry, but I went to do a make all and it died on the rulebrowser claiming it didn't know how to make it. So, I went in an tried to add the rulebrowser to the Makefile. I screwed up, though, and on compiling, got: Undefined: _ruleeditor_Usage _ruleeditor_Cleanup _DefaultMsgType_GR _CurrentMsgTypeName_GR _CurrentMsgType_GR _LoadMsgType_GR _AsClient_GR _RuleSetName_GR _RuleSet_GR _EditOrCreate_GR _RuleNumber_GR _Rule_GR etc,etc,etc. Could you possibly repair this back into working order ? -- Brian  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21519; Sun, 1 Oct 89 19:18:07 EDT Received: from HARVARD.HARVARD.EDU by ATHENA.MIT.EDU with SMTP id AA04090; Sun, 1 Oct 89 19:19:53 EDT Message-Id: <8910012319.AA04090@ATHENA.MIT.EDU> Received: by harvard.harvard.edu (5.54/a0.25) (for rap@athena.mit.edu) id AA18243; Sun, 1 Oct 89 19:19:47 EDT Received: by endor.HARVARD.EDU; Sun, 1 Oct 89 19:19:42 EDT Date: Sun, 1 Oct 89 19:19:42 EDT From: friedman@HARVARD.HARVARD.EDU (Joyce Friedman) To: rap@ATHENA.MIT.EDU, rap@CS.BU.EDU, rap@bucsf.bu.edu Subject: FYI *** EOOH *** Date: Sun, 1 Oct 89 19:19:42 EDT From: friedman@HARVARD.HARVARD.EDU (Joyce Friedman) To: rap@ATHENA.MIT.EDU, rap@CS.BU.EDU, rap@bucsf.bu.edu Subject: FYI From lewitter@BBN.COM Sun Oct 1 14:43:11 1989 Received: by harvard.harvard.edu (5.54/a0.25) (for friedman@endor) id AA13503; Sun, 1 Oct 89 14:43:06 EDT Received: from IZAR.BBN.COM by CS.BU.EDU (5.58/4.7) id AA03680; Sun, 1 Oct 89 14:42:45 EDT Message-Id: <8910011842.AA03680@CS.BU.EDU> Received: from PROPHET.BBN.COM by IZAR.BBN.COM id aa20820; 1 Oct 89 13:31 EDT Date: Sun, 1 Oct 89 13:37:51 EDT From: Fran Lewitter To: biotech@BBN.COM Cc: ai-seminar@BBN.COM Subject: Biotech/AI Seminar 10/3/89 Status: R Joint Biotechnology and Artificial Intelligence Seminar Series BBN Laboratories Science Development Program Topic: PRODIGY: An Integrated Reasoning Architecture Speaker: Jaime Carbonell, Ph.D. Department of Computer Science Carnegie Mellon University Location: 2nd Floor Large Conference Room 6/273 10 Moulton Street, Cambridge Date & Time: Tuesday October 3, 1989 - 3 pm Integrated reasoning architectures are the major intellectual focus of Artificial Intelligence research at Carnegie Mellon University, with Newell's SOAR, Mitchell's THEO, Carbonell's PRODIGY, and VanLehn's TETON. The presentation focuses on the PRODIGY architecture and its component parts: the universal problem solver, the explanation-based learning method, the abstraction learner for hierarchical planning, the derivational analogy case-builder, and the experimentation module. Examples are drawn from several application domains, such as machine-shop scheduling, robotic planning and specialized domains such as telescope making. It is argued that PRODIGY can provide a flexible substrate for the next generation of knowledge-based systems in planning-intensive tasks. If time permits, the presentation will address implementation issues, such as fast matching algorithms for large knowledge bases, and the utility of this technology beyond PRODIGY (e.g. to aspects of bibliographic matching, and human-genome sequence matching).  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23902; Mon, 2 Oct 89 00:02:04 EDT Received: from MORPHEUS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA07554; Mon, 2 Oct 89 00:03:53 EDT From: rap@ATHENA.MIT.EDU Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA15022; Mon, 2 Oct 89 00:01:48 -0400 Date: Mon, 2 Oct 89 00:01:48 -0400 Message-Id: <8910020401.AA15022@MORPHEUS.MIT.EDU> To: bgardner@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: RCS locks *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Mon, 2 Oct 89 00:01:48 -0400 To: bgardner@ATHENA.MIT.EDU Cc: argus2@ATHENA.MIT.EDU Subject: RCS locks e40-334-3:/afs/athena.mit.edu/astaff/project/argus/src/working/motif/include> -> co -l FieldType.h RCS/FieldType.h,v --> FieldType.h co error: revision 10.0 already locked by bgardner PLease check in. I want to fix that annoying gcc warning. Also, I have a nice script called /mit/rap/scripts/findcod which (no, it doesn't find all the cod on your keyboard, or return true if you've eaten cod in the last hour) finds all the files which you have checked out. do findcod while you are in the direcroy that it should check for the checked out files. This thing is not clever so you might want to do a mnanual search as well. __Rich.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25111; Mon, 2 Oct 89 03:05:11 EDT Received: from MORPHEUS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA08938; Mon, 2 Oct 89 03:06:58 EDT From: rap@ATHENA.MIT.EDU Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA15064; Mon, 2 Oct 89 03:04:50 -0400 Date: Mon, 2 Oct 89 03:04:50 -0400 Message-Id: <8910020704.AA15064@MORPHEUS.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: message types and the rule editor *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Mon, 2 Oct 89 03:04:50 -0400 To: argus2@ATHENA.MIT.EDU Subject: message types and the rule editor I have implimented a basic scheme to allow for storring of the message type of a rule. Now, here's my question: lets say someone loads in a rule wih a message type or even changes the message type of the rule while editing. Now, she adds a field, or deletes a field. Do we play along and keep the message type as was or does the message type revert to ''?? ++Rich  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25377; Mon, 2 Oct 89 03:56:23 EDT Received: from E40-334-3.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA09262; Mon, 2 Oct 89 03:58:13 EDT From: rap@ATHENA.MIT.EDU Received: by E40-334-3.MIT.EDU (5.61/4.7) id AA04426; Mon, 2 Oct 89 03:56:04 -0400 Date: Mon, 2 Oct 89 03:56:04 -0400 Message-Id: <8910020756.AA04426@E40-334-3.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: verb name changes *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Mon, 2 Oct 89 03:56:04 -0400 To: argus2@ATHENA.MIT.EDU Subject: verb name changes I know it sucks, but we gotta' go through this again. Here are the name changes: set -> set user property clear -> clear user property add -> add to user property subtract-> subtract from user property permanent -> make user property permanent nonpermanent -> make user property temporary delete -> delete current message move-to -> move to copy-to -> copy to system -> shell with message as stdin systembody -> shell with message body as stdin sendme -> < doesn't exist any more > shell -> formatted shell command remail -> remail current message to I hope yous all likes 'em all. __Rich.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25725; Mon, 2 Oct 89 05:12:11 EDT Received: from MORPHEUS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA09599; Mon, 2 Oct 89 05:14:01 EDT From: rap@ATHENA.MIT.EDU Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA15118; Mon, 2 Oct 89 05:11:57 -0400 Date: Mon, 2 Oct 89 05:11:57 -0400 Message-Id: <8910020911.AA15118@MORPHEUS.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: new verb names *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Mon, 2 Oct 89 05:11:57 -0400 To: argus2@ATHENA.MIT.EDU Subject: new verb names I had to change the rule format on disk to accomodate the new verb names. You will have to not only change your old verb names but you will have to quote the new verbs as well. i.e. an old rule $created 623321902 $updated 623321902 $name hello $if "Message Type:" "" "MSG" "Integer" %0 "To:" "contains" "" "Case Insensitive with Commas as ORs" %0 "Subject:" "contains" "" "Case Insensitive with Commas as ORs" %0 "Cc:" "contains" "" "Case Insensitive with Commas as ORs" %0 "Date:" "is before" "" "Date" %0 %and 5 $then "foo %rf" %shell 1 $end and its new equivalent. $created 623321902 $updated 623321902 $name hello $if "Message Type:" "" "MSG" "Integer" %0 "To:" "contains" "" "Case Insensitive with Commas as ORs" %0 "Subject:" "contains" "" "Case Insensitive with Commas as ORs" %0 "Cc:" "contains" "" "Case Insensitive with Commas as ORs" %0 "Date:" "is before" "" "Date" %0 %and 5 $then "foo %rf" %"formatted shell command" 1 $end I am recompiling all the new stuff now. The executables in 1.0 still use the old version. Whoever updates the new executables should also copy /mit/rap/.argus.profile to .../argus/argusprofile1.0 and change the NextProfilePath component to $(HOME)/.argus.profile. I don't suspext anybody should do this untill I get back (probably sometime today around 1 or 2). But I'm telling you in case you get antsy. __Rich.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25780; Mon, 2 Oct 89 05:27:38 EDT Received: from MORPHEUS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA09654; Mon, 2 Oct 89 05:29:28 EDT From: rap@ATHENA.MIT.EDU Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA15123; Mon, 2 Oct 89 05:27:26 -0400 Date: Mon, 2 Oct 89 05:27:26 -0400 Message-Id: <8910020927.AA15123@MORPHEUS.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: ruleeditor *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Mon, 2 Oct 89 05:27:26 -0400 To: argus2@ATHENA.MIT.EDU Subject: ruleeditor Ohh, I moved the new ruleeditor into working (and its recompiling now) but the boxer stuff is in an intermediate state so you can't make boxes. Not a bug, just not finished. __Rich  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA29682; Mon, 2 Oct 89 12:25:36 EDT Received: from E40-391A-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA15377; Mon, 2 Oct 89 12:26:43 EDT Received: by E40-391A-2.MIT.EDU (5.61/4.7) id AA16818; Mon, 2 Oct 89 12:24:41 -0400 Message-Id: <8910021624.AA16818@E40-391A-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Change to Tuesday Meetings Date: Mon, 02 Oct 89 12:24:39 EDT From: Ronald L. Orcutt *** EOOH *** To: staff@ATHENA.MIT.EDU Subject: Change to Tuesday Meetings Date: Mon, 02 Oct 89 12:24:39 EDT From: Ronald L. Orcutt Tuesday, 11-12 Release meeting RESCHEDULED to Thursday, Oct. 5, noon-1:30 pm in Room 382. If we need it, this meeting will followed with a second meeting on Friday, Oct. 6, same time, same place. This meeting is open to all staff who wish to comment on proposed release items for next Spring. Please prep by reading Ken Raeburn's "Proposal #3," which will be available in quantity outside Dan's door by the end of today. I am particularly interested in your identifying important items not included in the current proposal, or in linkages between items proposed and other activities such as documentation, consulting, etc. Given the size of 382, I'd ask various groups to do some delegation. Tuesday 3:30-5:00, Room 382. STILL ON. This meeting is to garner staff comments on what print quota mechanisms we need to implement for the Spring. It is NOT a review of the Palladium code, but rather, of the reporting, late-night-limit-hitting mechanisms, and last, funds payment mechanisms we need. Please read Dan's "quota_server_proposal," available outside his door. The results of these meetings will be reviewed by the managers on Tuesday, Oct. 10. Policy-level items will be reviewed with Earll.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA00896; Mon, 2 Oct 89 13:22:12 EDT Received: from MOZART.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA16770; Mon, 2 Oct 89 13:21:49 EDT From: nschmidt@ATHENA.MIT.EDU Received: by MOZART.MIT.EDU (5.61/4.7) id AA23228; Mon, 2 Oct 89 13:19:46 -0400 Message-Id: <8910021719.AA23228@MOZART.MIT.EDU> To: staff@ATHENA.MIT.EDU, cfyi@ATHENA.MIT.EDU Subject: Faculty Liaison Mailing List Date: Mon, 02 Oct 89 13:19:44 EDT *** EOOH *** From: nschmidt@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU, cfyi@ATHENA.MIT.EDU Subject: Faculty Liaison Mailing List Date: Mon, 02 Oct 89 13:19:44 EDT In the future, if you wish to send mail both to Anne and myself you can sent it to the mailing list F_L (for Faculty Liaison) rather than to both our names. Naomi  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01211; Mon, 2 Oct 89 13:34:17 EDT Received: from GEVALT.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA16826; Mon, 2 Oct 89 13:23:27 EDT From: amgreene@ATHENA.MIT.EDU Received: by GEVALT.MIT.EDU (5.61/4.7) id AA22880; Mon, 2 Oct 89 13:21:00 -0400 Date: Mon, 2 Oct 89 13:21:00 -0400 Message-Id: <8910021721.AA22880@GEVALT.MIT.EDU> To: sipb@ATHENA.MIT.EDU, gli@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU, tex-hackers@ATHENA.MIT.EDU, savoyards@ATHENA.MIT.EDU Subject: Mail. Lots of mail. Gone. *** EOOH *** From: amgreene@ATHENA.MIT.EDU Date: Mon, 2 Oct 89 13:21:00 -0400 To: sipb@ATHENA.MIT.EDU, gli@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU, tex-hackers@ATHENA.MIT.EDU, savoyards@ATHENA.MIT.EDU Subject: Mail. Lots of mail. Gone. If you sent me mail of any sort before Friday afternoon, and you're waiting for a reply and haven't gotten one, or if it was about any of my continuing projects (such as dvi2ps, xps, TeX, the Sorcerer, etc.), please resend it. That's right, my RMAIL file was filled with zeros (but it was the right length) this morning. Of course, after reading my mail on Friday I then went off to New York for the holiday and got back and tried to read my mail and by now the autosave file is gone. The good part is that I needed to clean out my RMAIL file anyway. :-/ Mail sent after noon on Friday is safe. (Also, I was helping someone with letterformat.tex --- one of you gave him my username. I'm going to need his, since he isn't on any of these lists, and (heh heh heh) my mail is gone.) Sorry and thanks, Andrew  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01674; Mon, 2 Oct 89 13:49:47 EDT Received: from E40-391-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA17694; Mon, 2 Oct 89 13:49:30 EDT From: frederpa@ATHENA.MIT.EDU Received: by E40-391-2.MIT.EDU (5.61/4.7) id AA19021; Mon, 2 Oct 89 13:47:14 -0400 Message-Id: <8910021747.AA19021@E40-391-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Meeting on Print Quota Date: Mon, 02 Oct 89 13:47:11 EDT *** EOOH *** From: frederpa@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: Meeting on Print Quota Date: Mon, 02 Oct 89 13:47:11 EDT There will be a meeting on Print Quota on Tuesday, October 3rd, from 3:30 to 5:00 in Conference Room 382. All staff are invited. Please review the documentation for this meeting prior to attendance. You can pickup documents from Dan Geer. Note: This notice was sent out on Friday morning, but was "lost" in the mail. Sorry that it is reaching you late. --------  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA18906; Tue, 3 Oct 89 12:45:07 EDT Received: from E40-342F-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA12418; Tue, 3 Oct 89 12:46:27 EDT From: geer@ATHENA.MIT.EDU Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA06895; Tue, 3 Oct 89 12:44:21 -0400 Date: Tue, 3 Oct 89 12:44:21 -0400 Message-Id: <8910031644.AA06895@E40-342F-2.MIT.EDU> To: sysdev@ATHENA.MIT.EDU Subject: usenix program Cc: staff@ATHENA.MIT.EDU *** EOOH *** From: geer@ATHENA.MIT.EDU Date: Tue, 3 Oct 89 12:44:21 -0400 To: sysdev@ATHENA.MIT.EDU Subject: usenix program Cc: staff@ATHENA.MIT.EDU latest word from mission control. --dan ----------------------------------------------------------------------------- Morning Break 10:30-11:00 ----------------------------------------------------------------------------- ==Virtual Memory== (Chair - Chet Juszczak) 11:00-12:30 A Dynamic File System Inode Allocation and Reclaim Policy Insuring Improved VM Performance: Some No-Fault Policies An External Pager Implemented as a UNIX SVR4 Virtual File System ----------------------------------------------------------------------------- Lunch Break 12:30-2:00 ----------------------------------------------------------------------------- ==Architecture & Debuggers== (Chair - John Mashey) 2:00-3:30 Implementing a Mach Debugger for Multithreaded Applications pdb: A Network Oriented Symbolic Debugger Efficient Architecture Simulation For UNIX Kernel Debugging ----------------------------------------------------------------------------- Afternoon Break 3:30-4:00 ----------------------------------------------------------------------------- ==Applications== (Chair - Susanne Smith) 4:00-5:30 Software Tickerplants on UNIX GENESIS and XODUS General Purpose Neural Network Simulation Tool Keynote - A Language and Extensible Graphical Editor for Music +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Thursday, January 25 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ==Utilities== (Chair - John Devitofranceschi) 9:00-10:30 Integrated Interactive Access to Heterogeneous Distributed Services The UNIX System Math Library, a Status Report Tcl: An Embeddable Command Language ----------------------------------------------------------------------------- Morning Break 10:30-11:00 ----------------------------------------------------------------------------- ==Kernel Internals== (Chair - Charlie Perkins) 11:00-12:30 An Event-based Fair Share Scheduler Parallel STREAMS: a Multi-Processor Implementation Implementing Berkeley Sockets in System V Release 4 ----------------------------------------------------------------------------- Lunch Break 12:30-2:00 ----------------------------------------------------------------------------- ==Networks== (Chair - Alix Vasilatos) 2:00-3:30 Two Network Management Tools Packet Trains on NSFNET National Backbone A Traffic Characterization Pseudo-Network Drivers and Virtual Networks ----------------------------------------------------------------------------- Afternoon Break 3:30-4:00 ----------------------------------------------------------------------------- ==Special Session on Ethics and Computers== 4:00-5:30 Rob Kolstad - Moderator and Snide Remarks Dan Appelman - Legal Eagle J. Random Philosopher - Omphaloskeptic (now *there's* a word for you, Mike) Mike Manager - Cutthroat Computer Executive +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Friday, January 26 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ==User Interface Management Systems== (Chair - Dan Geer) 9:00-10:30 The Serpent User Interface Management System Parallel Object-Oriented UIMS with Macro and Micro Stubs MTX - A Shell that permits dynamic rearrangement of connections ----------------------------------------------------------------------------- Morning Break 10:30-11:00 ----------------------------------------------------------------------------- ==File Systems== (Chair - Kirk McKusick) 11:00-12:30 Using Unix as One Component of a Lightweight Distributed Kernel A Highly-Parallelized Mach-based Vnode Filesystem Disk Scheduling Revisited ----------------------------------------------------------------------------- Lunch Break 12:30-2:00 ----------------------------------------------------------------------------- ==Languages and Software Engineering== (Chair - Dan Klein?) 2:00-4:00 Postloading for Fun and Profit Multiple Site Source Reconciliation CVS-II: Parallelizing Software Development Ada and Binary Unix Standards ----------------------------------------------------------------------------- ==The End==  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22103; Tue, 3 Oct 89 15:10:18 EDT Received: from E40-342F-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA16359; Tue, 3 Oct 89 15:11:01 EDT From: geer@ATHENA.MIT.EDU Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA06957; Tue, 3 Oct 89 15:08:55 -0400 Message-Id: <8910031908.AA06957@E40-342F-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Re: X Conference Dates Date: Tue, 03 Oct 89 15:08:53 EDT *** EOOH *** From: geer@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: Re: X Conference Dates Date: Tue, 03 Oct 89 15:08:53 EDT ------- Forwarded Message From: converse@EXPO.LCS.MIT.EDU (Donna Converse) To: apple!well!jsc@AMES.ARC.NASA.GOV (James Carrington) Cc: xpert@EXPO.LCS.MIT.EDU Subject: Re: X Conference Dates? In-Reply-To: Your message of 28 Sep 89 23:25:34 GMT. <13864@well.UUCP> Organization: X Consortium, MIT Laboratory for Computer Science Date: Fri, 29 Sep 89 11:45:59 -0400 The 4th annual Technical Conference on the X Window System will be held on January 15-17, 1990 at the Marriott Copley Place Hotel in Boston, MA. The call for participation has been posted several times to the xpert mailing list / comp.windows.x newsgroup. If you missed it, and are considering a presentation, I can post it again. The deadline for submissions for talks, tutorials, and BOFs is November 17 1989. Registration details have not yet been announced. Donna Converse converse@expo.lcs.mit.edu 617-253-9608 ------- End of Forwarded Message  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA29438; Tue, 3 Oct 89 22:04:46 EDT Received: from FLASH.BELLCORE.COM by ATHENA.MIT.EDU with SMTP id AA26613; Tue, 3 Oct 89 22:06:41 EDT Received: by flash.bellcore.com (5.58/1.1) id AA15142; Tue, 3 Oct 89 22:05:15 EDT Date: Tue, 3 Oct 89 22:05:15 EDT From: walker@FLASH.BELLCORE.COM (Donald E Walker) Message-Id: <8910040205.AA15142@flash.bellcore.com> To: rap@ATHENA.MIT.EDU Subject: Re: call for papers for ACL meeting of June 1990 *** EOOH *** Date: Tue, 3 Oct 89 22:05:15 EDT From: walker@FLASH.BELLCORE.COM (Donald E Walker) To: rap@ATHENA.MIT.EDU Subject: Re: call for papers for ACL meeting of June 1990 CALL FOR PAPERS 28th Annual Meeting of the Association for Computational Linguistics 6-9 June 1990 University of Pittsburgh Pittsburgh, Pennsylvania TOPICS OF INTEREST: Papers are invited on substantial, original, and unpublished research on all aspects of computational linguistics, including, but not limited to, pragmatics, discourse, semantics, syntax, and the lexicon; phonetics, phonology, and morphology; interpreting and generating spoken and written language; linguistic, mathematical, and psychological models of language; machine translation and translation aids; natural language interfaces; message understanding systems; and theoretical and applications papers of every kind. REQUIREMENTS: Papers should describe unique work; they should emphasize completed work rather than intended work; and they should indicate clearly the state of completion of the reported results. A paper accepted for presentation at the ACL Meeting cannot be presented at another conference. FORMAT FOR SUBMISSION: Authors should submit twelve copies of preliminary versions of their papers, not to exceed 3200 words (exclusive of references). The title page should include the title, the name(s) of the author(s), complete addresses, a short (5 line) summary, and a specification of the topic area. Submissions that do not conform to this format will not be reviewed. Send to: Robert C. Berwick ACL-90 Program Chair MIT AI Laboratory, Room 838 545 Technology Square Cambridge, MA 02139 USA (+1 617)253-8918 berwick@wheaties.ai.mit.edu SCHEDULE: Final papers are due by 16 December 1989. Authors will be notified of acceptance by 3 February 1990. Camera-ready copies of final papers prepared in a double-column format, preferably on laser-printer output must be received by 7 April 1990, along with a signed copyright release statement. OTHER ACTIVITIES: The meeting will include a program of tutorials organized by Dan Flickinger, Hewlett-Packard Research Laboratories, 1501 Page Mill Road, Palo Alto, CA 94304, USA; (+1 415)857-8789; flickinger@hp.com. Anyone wishing to arrange an exhibit or present a demonstration should send a brief description together with a specification of physical requirements (space, power, telephone connections, tables, etc.) to Rich Thomason at the address below. CONFERENCE INFORMATION: Local arrangements are being handled by Rich Thomason, Intelligent Systems Program, Cathedral of Learning 1004, University of Pittsburgh, Pittsburgh, PA 15260, USA; (+1 412)624-5791; thomason@cad.cs.cmu.edu. For other information on the conference and on the ACL more generally, contact Don Walker (ACL), Bellcore, MRE 2A379, 445 South Street, Box 1910, Morristown, NJ 07960-1910, USA; (+1 201)829-4312; walker@flash.bellcore.com or bellcore!walker. PROGRAM COMMITTEE: Robert Berwick, David Israel, Karen Jensen, Aravind Joshi, Richard Larson, Paul Martin, Kathy McKeown, Martha Pollack, James Pustejovsky, Edward Stabler, Hans Uszkoreit, David Weir.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09176; Wed, 4 Oct 89 14:53:58 EDT Received: from FUTURE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA11524; Wed, 4 Oct 89 14:55:52 EDT Received: by FUTURE.MIT.EDU (5.61/4.7) id AA06833; Wed, 4 Oct 89 14:53:43 -0400 Message-Id: <8910041853.AA06833@FUTURE.MIT.EDU> To: vanharen@ATHENA.MIT.EDU, yaypoo@ATHENA.MIT.EDU, phils@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU, mory@ATHENA.MIT.EDU, kzolot@ATHENA.MIT.EDU, roman@ATHENA.MIT.EDU Cc: jstewart@ATHENA.MIT.EDU Subject: Focus mtg for Athena Motif developers Date: Wed, 04 Oct 89 14:53:38 EDT From: Jacqueline A. Stewart *** EOOH *** To: vanharen@ATHENA.MIT.EDU, yaypoo@ATHENA.MIT.EDU, phils@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU, mory@ATHENA.MIT.EDU, kzolot@ATHENA.MIT.EDU, roman@ATHENA.MIT.EDU Cc: jstewart@ATHENA.MIT.EDU Subject: Focus mtg for Athena Motif developers Date: Wed, 04 Oct 89 14:53:38 EDT From: Jacqueline A. Stewart There will be a focus meeting for a selected group of Athena Motif developers conducted by some of our user interface consultants for the OSF research grant. We are interested in discussing your experiences as Athena Motif developers, especially with regard to the Motif development tools and screen design issues. This meeting will be held: Date: Friday, 6 October 1989 Time: 2:00 pm - 4:00 pm Place: E40-316 (small conf. room) I have contacted most of you in person already (Mory - we have not been able to reach you - if you &/or some students programmers who have had experience using Motif could come we would appreciate it). Roman will be the Athena point person for this meeting. Please contact him if you have any questions. Thanks, Jackie  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15335; Wed, 4 Oct 89 21:30:20 EDT Received: from MEDUSA.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA20688; Wed, 4 Oct 89 21:28:53 EDT From: epeisach@ATHENA.MIT.EDU Received: by MEDUSA.MIT.EDU (5.61/4.7) id AA18013; Wed, 4 Oct 89 21:28:47 -0400 Date: Wed, 4 Oct 89 21:28:47 -0400 Message-Id: <8910050128.AA18013@MEDUSA.MIT.EDU> To: phils@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: Athena bitmap *** EOOH *** From: epeisach@ATHENA.MIT.EDU Date: Wed, 4 Oct 89 21:28:47 -0400 To: phils@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: Athena bitmap I have a copy of the owl bitmap that was used in 6.3A for xlogin. It's 200x200 I believe. You can find a variety of forms in /mit/epeisach/6.3/owl*. If you want the actual one that was used in 6.3A (stipple background instead of black) the RCS file /paris/source/4.3/etc.athena/xdm/dist/RCS/owl.xbm,v has it stored. Ezra  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17159; Wed, 4 Oct 89 23:55:59 EDT Received: from E40-342F-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA23386; Wed, 4 Oct 89 23:54:24 EDT From: geer@ATHENA.MIT.EDU Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA11909; Wed, 4 Oct 89 23:54:18 -0400 Message-Id: <8910050354.AA11909@E40-342F-2.MIT.EDU> To: sysdev@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: personel Date: Wed, 04 Oct 89 23:54:15 EDT *** EOOH *** From: geer@ATHENA.MIT.EDU To: sysdev@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: personel Date: Wed, 04 Oct 89 23:54:15 EDT It is my pleasure to announce Paul Boutin's addition to the Systems Development staff. Paul will be working on window system related value-added applications, principally in the graphics area. I do not yet know where he will sit, so in the meantime he stays seated in his old space. But MAKE NO MISTAKE ABOUT IT, he'll be doing other things. Please join me in welcoming Paul. --dan  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17238; Wed, 4 Oct 89 23:59:51 EDT Received: from E40-334-3.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA23460; Wed, 4 Oct 89 23:59:40 EDT From: rap@ATHENA.MIT.EDU Received: by E40-334-3.MIT.EDU (5.61/4.7) id AA05863; Wed, 4 Oct 89 23:59:28 -0400 Date: Wed, 4 Oct 89 23:59:28 -0400 Message-Id: <8910050359.AA05863@E40-334-3.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: CHANGE OF FUNCTIONALITY ANNOUNCEMENT *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Wed, 4 Oct 89 23:59:28 -0400 To: argus2@ATHENA.MIT.EDU Subject: CHANGE OF FUNCTIONALITY ANNOUNCEMENT THE FUNCTION CALL TO AlPop_Query HAS BEEN CHANGED in order to add functionality. I have added 2 more arguments to the end of the function call. The funtion call looks like this: VOIDP AlPop_Query PROTOTYPE((AlPopType, /* what kind of pop */ char*, /* the message */ char*, /* help message (if help is pressed) */ Widget, /* widget to use as parent */ AlPopHangDirection, /* where to popup */ /* in relation to */ /* parent widget */ Display*, /* used if widget==NULL */ int)); /* mask of which buttons to use */ The Display* is used only if the Widget is NULL. If the Widget is NULL this function will pop the popup underneath the pointer so it needs the Display*. The last argument is the bitwise inclusive OR of the following constants: #define ALPOP_NONE 0 #define ALPOP_CANCEL (1<<0) #define ALPOP_OK (1<<1) #define ALPOP_HELP (1<<2) and determines which buttons to display on the popup. So, for instance, if you wanted to show only the OK button just pass ALPOP_OK. If you want all three buttons pass ALPOP_OK | ALPOP_CANCEL | ALPOP_HELP. You get it. I HAVE ALREADY REMADE THE VAX LIBRARIES SO IF YOU RECOMPILE YOU *HAVE* TO CHANGE ANY REFERENCES YOU HAVE TO THIS FUNCTION. __Rich.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA18648; Thu, 5 Oct 89 02:18:55 EDT Received: from STEPHEN-R-DONALDSON.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA25482; Thu, 5 Oct 89 02:17:00 EDT From: qjb@ATHENA.MIT.EDU Received: by STEPHEN-R-DONALDSON.MIT.EDU (5.61/4.7) id AA05805; Thu, 5 Oct 89 02:16:01 -0400 Date: Thu, 5 Oct 89 02:16:01 -0400 Message-Id: <8910050616.AA05805@STEPHEN-R-DONALDSON.MIT.EDU> To: staff@ATHENA.MIT.EDU Cc: jis@ATHENA.MIT.EDU, jtkohl@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU Cc: ops@ATHENA.MIT.EDU Subject: srvtabs - important, or Don't say I didn't warn you *** EOOH *** From: qjb@ATHENA.MIT.EDU Date: Thu, 5 Oct 89 02:16:01 -0400 To: staff@ATHENA.MIT.EDU Cc: jis@ATHENA.MIT.EDU, jtkohl@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU Cc: ops@ATHENA.MIT.EDU Subject: srvtabs - important, or Don't say I didn't warn you IF YOU HAVE A WORKSTATION WITH A SRVTAB or maintain a host with one, read this. Otherwise, feel free to ignore it. The current set of kerberos libraries released to the world and available to us in the krbuser locker cares about the realm field for keys in the srvtab. This means that if your srvtab was created before some time this summer (when ext_srvtab was updated on KERBEROS.MIT.EDU), your srvtab *will not work* the next time kerberos is udpated in the athena release (hopefully January). To fix this, you will want to run the program /mit/qjb/${hosttype}bin/fix_srvtab. (attach qjb first.) This program, compiled for rt, vax, and pmax, reads a file (/etc/srvtab by default) and creates a new file in .fixed that contains the correct realm information. (It just changes "Athena" to "ATHENA.MIT.EDU" in the realm field of each key). After you do this, you should make a safe copy of the old srvtab, replace it with /etc/srvtab.fixed, and try to use the srvtab. You can also verify the correctness of the fixed srvtab with the ksrvutil program in krbuser (attach krbuser, /mit/krbuser/${hosttype}bin/ksrvutil list -k -f /etc/srvtab.fixed and again on the original). Don't forget to change keyfiles in locations other than /etc/srvtab. For example, if you are running a discuss server you will need to change /usr/spool/discuss/srvtab as well. *********** PLEASE LET ME KNOW IF YOU USE THIS PROGRAM ************* This way, I will know that I have reached people about this. If I don't get enough responses, I'll try to let people know in some other way. It is important that this be done or else things will mysteriously break next time things are built with the new libraries. ================== Note that all servers will have to have this program run on them. If you are interested, the source for this is in /mit/qjb/source/kerberos/fix_srvtab.c. Jay Berkenbilt  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20977; Thu, 5 Oct 89 09:27:09 EDT Received: from E40-342F-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA28677; Thu, 5 Oct 89 09:25:51 EDT From: geer@ATHENA.MIT.EDU Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA15408; Thu, 5 Oct 89 09:25:46 -0400 Message-Id: <8910051325.AA15408@E40-342F-2.MIT.EDU> To: ackerman@ATHENA.MIT.EDU, amgreene@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU, dkk@ATHENA.MIT.EDU, epeisach@ATHENA.MIT.EDU, garner@ATHENA.MIT.EDU, henry@ATHENA.MIT.EDU, jh@ATHENA.MIT.EDU, jik@ATHENA.MIT.EDU, jnrees@ATHENA.MIT.EDU, jtkohl@ATHENA.MIT.EDU, jud@ATHENA.MIT.EDU, kit@EXPO.LCS.MIT.EDU, kzolot@ATHENA.MIT.EDU, lnp@ATHENA.MIT.EDU, mar@ATHENA.MIT.EDU, marc@ATHENA.MIT.EDU, mcmillan@EAGLE.MIT.EDU, nschmidt@ATHENA.MIT.EDU, paul@ATHENA.MIT.EDU, qjb@ATHENA.MIT.EDU, raeburn@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU, swick@ATHENA.MIT.EDU, tytso@ATHENA.MIT.EDU, wdc@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: re: training on C++ Date: Thu, 05 Oct 89 09:25:42 EDT *** EOOH *** From: geer@ATHENA.MIT.EDU To: ackerman@ATHENA.MIT.EDU, amgreene@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU, dkk@ATHENA.MIT.EDU, epeisach@ATHENA.MIT.EDU, garner@ATHENA.MIT.EDU, henry@ATHENA.MIT.EDU, jh@ATHENA.MIT.EDU, jik@ATHENA.MIT.EDU, jnrees@ATHENA.MIT.EDU, jtkohl@ATHENA.MIT.EDU, jud@ATHENA.MIT.EDU, kit@EXPO.LCS.MIT.EDU, kzolot@ATHENA.MIT.EDU, lnp@ATHENA.MIT.EDU, mar@ATHENA.MIT.EDU, marc@ATHENA.MIT.EDU, mcmillan@EAGLE.MIT.EDU, nschmidt@ATHENA.MIT.EDU, paul@ATHENA.MIT.EDU, qjb@ATHENA.MIT.EDU, raeburn@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU, swick@ATHENA.MIT.EDU, tytso@ATHENA.MIT.EDU, wdc@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU Subject: re: training on C++ Date: Thu, 05 Oct 89 09:25:42 EDT John Ostlund has asked that we move the training session from the 20th of October to sometime in the week of October 30th, due to his business reasons. I am inclined to pick another Friday, viz. November 3rd. If that is a disaster for anyone, say so today. --dan Oct Nov S M Tu W Th F S S M Tu W Th F S 1 2 3 4 5 6 7 1 2 3 4 8 9 10 11 12 13 14 5 6 7 8 9 10 11 15 16 17 18 19 20 21 12 13 14 15 16 17 18 22 23 24 25 26 27 28 19 20 21 22 23 24 25 29 30 31 26 27 28 29 30  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA29256; Thu, 5 Oct 89 16:29:23 EDT Received: from E40-391-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA10233; Thu, 5 Oct 89 16:28:14 EDT From: frederpa@ATHENA.MIT.EDU Received: by E40-391-2.MIT.EDU (5.61/4.7) id AA04423; Thu, 5 Oct 89 16:28:08 -0400 Message-Id: <8910052028.AA04423@E40-391-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: EDUCOM Planning meeting on Friday, 10/6 @ 2:00 Date: Thu, 05 Oct 89 16:28:05 EDT *** EOOH *** From: frederpa@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: EDUCOM Planning meeting on Friday, 10/6 @ 2:00 Date: Thu, 05 Oct 89 16:28:05 EDT For those staff members attending the EDUCOM Planning meeting tomorrow (and you know who you are), the meeting will be held in Conference Room 298, downstairs. --------  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02304; Thu, 5 Oct 89 19:14:38 EDT Received: from FERNWOOD.MPK.CA.US by ATHENA.MIT.EDU with SMTP id AA14492; Thu, 5 Oct 89 19:14:24 EDT Received: from asylum.UUCP by fernwood.MPK.CA.US at Thu, 5 Oct 89 16:13:09 -0700. (5.61.14/XIDA-1.2.8.34) id AA18104 for rap@ATHENA.MIT.EDU via UUCP Received: by asylum.sf.ca.us (smail2.5x) id AA07784; 5 Oct 89 16:12:13 PDT (Thu) Date: 5 Oct 89 16:12:10 PDT (Thu) From: MAILER-DAEMON@asylum.sf.ca.us Subject: failed mail To: rap@ATHENA.MIT.EDU Message-Id: <8910051612.AA07784@asylum.sf.ca.us> ======= command failed ======= COMMAND: /usr/lib/mail/execmail.x -m -f 'fernwood!ATHENA.MIT.EDU!rap' 'lanz' ======= standard error follows ======= ======= text of message follows ======= From fernwood!ATHENA.MIT.EDU!rap Received: from ATHENA.MIT.EDU by fernwood.MPK.CA.US at Thu, 5 Oct 89 12:59:39 -0700. (5.61.14/XIDA-1.2.8.34) id AA08924 for lanz@ASYLUM.SF.CA.US via SMTP Received: from MORPHEUS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA09357; Thu, 5 Oct 89 15:58:25 EDT From: rap@ATHENA.MIT.EDU Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA16377; Thu, 5 Oct 89 15:58:17 -0400 Date: Thu, 5 Oct 89 15:58:17 -0400 Message-Id: <8910051958.AA16377@MORPHEUS.MIT.EDU> To: bjaspan@ATHENA.MIT.EDU Cc: motif@ATHENA.MIT.EDU In-Reply-To: Barr3y Jaspan's message of Thu, 5 Oct 89 14:59:50 -0400 <8910051859.AA12463@BINKLEY.MIT.EDU> Subject: setting focus Your right, XtSetKeyboardFocus does NOT do what I want it to. What I really want is a way for Motif to change the widget which it thinks has focus. Using XtSetKeyboard would be going behind Motif's back and the results are unnacceotable. The same is with XSetInputFocus. Perhaps I am looking for an as yet unwritten Motif Function that should be called something like XmManagerSetFocus(Widget). Oh well, thanks for the complete answer anyway :->, but I'm still looking :-| __Rich Pito.  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02310; Thu, 5 Oct 89 19:14:51 EDT Received: from Fernwood.MPK.CA.US by ATHENA.MIT.EDU with SMTP id AA14491; Thu, 5 Oct 89 19:14:20 EDT Received: from asylum.UUCP by fernwood.MPK.CA.US at Thu, 5 Oct 89 16:13:04 -0700. (5.61.14/XIDA-1.2.8.34) id AA18098 for rap@ATHENA.MIT.EDU via UUCP Date: Thu, 5 Oct 89 16:13:04 -0700 From: asylum!asylum_mailer_daemon Message-Id: <8910052313.AA18098@fernwood.MPK.CA.US> To: rap@ATHENA.MIT.EDU Subject: mail problem Trouble sending mail on `asylum', Thu Oct 5 16:12:11 1989 ============ Transcript follows ============ lanz 0 alias errors No local user named "lanz" 1 delivery errors 1 total errors ============== Message follows ============= >From ATHENA.MIT.EDU!rap Thu Oct 5 16:12:10 1989 remote from fernwood Received: by asylum.sf.ca.us (smail2.5x) id AA07776; 5 Oct 89 16:12:10 PDT (Thu) Received: from ATHENA.MIT.EDU by fernwood.MPK.CA.US at Thu, 5 Oct 89 12:59:39 -0700. (5.61.14/XIDA-1.2.8.34) id AA08924 for lanz@ASYLUM.SF.CA.US via SMTP Received: from MORPHEUS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA09357; Thu, 5 Oct 89 15:58:25 EDT From: rap@ATHENA.MIT.EDU Received: by MORPHEUS.MIT.EDU (5.61/4.7) id AA16377; Thu, 5 Oct 89 15:58:17 -0400 Date: Thu, 5 Oct 89 15:58:17 -0400 Message-Id: <8910051958.AA16377@MORPHEUS.MIT.EDU> To: bjaspan@ATHENA.MIT.EDU Cc: motif@ATHENA.MIT.EDU In-Reply-To: Barr3y Jaspan's message of Thu, 5 Oct 89 14:59:50 -0400 <8910051859.AA12463@BINKLEY.MIT.EDU> Subject: setting focus Your right, XtSetKeyboardFocus does NOT do what I want it to. What I really want is a way for Motif to change the widget which it thinks has focus. Using XtSetKeyboard would be going behind Motif's back and the results are unnacceotable. The same is with XSetInputFocus. Perhaps I am looking for an as yet unwritten Motif Function that should be called something like XmManagerSetFocus(Widget). Oh well, thanks for the complete answer anyway :->, but I'm still looking :-| __Rich Pito.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05519; Thu, 5 Oct 89 22:48:12 EDT Received: from E40-334-3.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA18895; Thu, 5 Oct 89 22:48:03 EDT From: rap@ATHENA.MIT.EDU Received: by E40-334-3.MIT.EDU (5.61/4.7) id AA06404; Thu, 5 Oct 89 22:47:51 -0400 Date: Thu, 5 Oct 89 22:47:51 -0400 Message-Id: <8910060247.AA06404@E40-334-3.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: new funciton for AlFonts *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Thu, 5 Oct 89 22:47:51 -0400 To: argus2@ATHENA.MIT.EDU Subject: new funciton for AlFonts This function allows you to get a customizable XmFontList for those cases (like the text widget) where the first widget in the font list is used no matter what. It is called extern XmFontList AlFonts_get_specific_fonts PROTOTYPE((Widget,AlFontsMask)); and takes a widget and a mask of the fonts you want inclusive ored from the following constants: #define ALFONTS_MAJOR_HEADING_MASK (1<<0) #define ALFONTS_MINOR_HEADING_MASK (1<<1) #define ALFONTS_BUTTONS_MASK (1<<2) #define ALFONTS_TEXT_MASK (1<<3) note that if you specify more than one font the order is undefined, so for the text widget, for instance, you would only specify one font. __Rich.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17884; Fri, 6 Oct 89 17:04:35 EDT Received: from E40-334-3.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA06507; Fri, 6 Oct 89 17:04:30 EDT From: rap@ATHENA.MIT.EDU Received: by E40-334-3.MIT.EDU (5.61/4.7) id AA06774; Fri, 6 Oct 89 17:04:23 -0400 Date: Fri, 6 Oct 89 17:04:23 -0400 Message-Id: <8910062104.AA06774@E40-334-3.MIT.EDU> To: mgibson@ATHENA.MIT.EDU Cc: rap@ATHENA.MIT.EDU Subject: time worked and vacation etc... *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Fri, 6 Oct 89 17:04:23 -0400 To: mgibson@ATHENA.MIT.EDU Cc: rap@ATHENA.MIT.EDU Subject: time worked and vacation etc... Apr May Jun S M Tu W Th F S S M Tu W Th F S S M Tu W Th F S 1 1 2 3 4 5 6 1 2 3 2 3 4 5 6 7 8 7 8 9 10 11 12 13 4 5 6 7 8 9 10 9 10 11 12 13 14 15 14 15 16 17 18 19 20 11 12 13 14 15 16 17 16 17 18 19 20 21 22 21 22 23 24 25 26 27 18 19 20 21 22 23 24 23 24 25 26 27 28 29 28 29 30 31 25 26 27 28 29 30 30 Jul Aug Sep S M Tu W Th F S S M Tu W Th F S S M Tu W Th F S 1 1 2 3 4 5 1 2 2 3 4 5 6 7 8 6 <---------------- 3 4 5 6 7 8 9 9 10 11 12 13 14 15 ----- vacation ----- 10 11 12 13 14 15 16 16 17 18 19 20 21 22 -------------------- 17 18 19 20 21 22 23 23 24 25 26 27 28 29 ----> 29 30 31 24 25 26 27 28 29 30 30 31 Oct Nov Dec S M Tu W Th F S S M Tu W Th F S S M Tu W Th F S 1 2 3 4 5 6 7 1 2 3 4 1 2 8 9 10 11 12 > 14 5 6 7 8 9 10 11 3 4 5 6 7 8 9 15 16 17 18 19 20 21 12 13 14 15 16 17 18 10 11 12 13 14 15 16 22 23 24 25 26 27 28 19 20 21 22 23 24 25 17 18 19 20 21 22 23 29 30 31 26 27 28 29 30 24 25 26 27 28 29 30 31 I was confused when I told you about me starting in May (that was last summer!!). We started on time on June 3. started June 3 projected end October 16 Vacation Aug 7 to Aug 28 (3 weeks) __Rich.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20765; Fri, 6 Oct 89 20:51:34 EDT Received: from XEROX.COM by ATHENA.MIT.EDU with SMTP id AA01603; Fri, 6 Oct 89 20:51:23 EDT Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 89 17:47:02 PDT Date: 1 Jan 01 02:27 PST From: wmackay.pa@XEROX.COM Subject: Hello To: rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU Cc: wmackay.pa@XEROX.COM Message-Id: <891006-174702-11845@Xerox> *** EOOH *** Date: 1 Jan 01 02:27 PST From: wmackay.pa@XEROX.COM Subject: Hello To: rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU Cc: wmackay.pa@XEROX.COM Hi. I finally got to a workstation, although the one in my office still doesn't work. I am having trouble getting to Athena. I can rlogin to Jason, but not my workstation. I can also ftp files from jason, but not my workstation. I also don't know how to get to the doc directories in the Argus afs locker. Any ideas? Steve will leave the key to my office in the envelope in my box, so you can get to the workstation if you need to. How's it going? How was the meeting with Watzman+Keyes? A number of people here are using X and would really like to use Argus. Wendy  1,answered,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21567; Fri, 6 Oct 89 23:10:14 EDT Received: from XEROX.COM by ATHENA.MIT.EDU with SMTP id AA03009; Fri, 6 Oct 89 23:10:09 EDT Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 89 20:10:01 PDT Date: 1 Jan 01 04:50 PST From: wmackay.pa@XEROX.COM Subject: It worked To: rap@ATHENA.MIT.EDU Message-Id: <891006-201001-12123@Xerox> *** EOOH *** Date: 1 Jan 01 04:50 PST From: wmackay.pa@XEROX.COM Subject: It worked To: rap@ATHENA.MIT.EDU I'm telneted into e40-315-5. I can even get to the argus directory. I just tried to use runrules and got: Assertion failed: file darray.c: line 130: temp->length > 0 Illegal instruction It may be a problem with my rules, since I haven't updated them recently. But just in case that's not the problem. Wendy  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA22249; Sat, 7 Oct 89 01:17:34 EDT Received: from XEROX.COM by ATHENA.MIT.EDU with SMTP id AA04584; Sat, 7 Oct 89 01:17:27 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 06 OCT 89 22:17:09 PDT Date: 6 Oct 89 22:16 PDT From: wmackay.pa@XEROX.COM Subject: Re: It worked In-Reply-To: your message of Sat, 7 Oct 89 01:10:46 -0400 To: rap@ATHENA.MIT.EDU Cc: wmackay.pa@XEROX.COM Message-Id: <891006-221709-12212@Xerox> *** EOOH *** Date: 6 Oct 89 22:16 PDT From: wmackay.pa@XEROX.COM Subject: Re: It worked In-Reply-To: your message of Sat, 7 Oct 89 01:10:46 -0400 To: rap@ATHENA.MIT.EDU Cc: wmackay.pa@XEROX.COM Ok. I'm going to head out now, but I'll be back here tomorrow afternoon. (I'm actually typing this from my workstation in my office -- very exciting. I've just spent the past hour trying to figure out LISP machine file specifications...and finally got something that will let me get to my mail.) I managed to copy over the design.doc and the -help info from the rule editor and runrules (but not rule browser, for some reason), so I'll work on that tomorrow. Talk to you later. W  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15981; Tue, 10 Oct 89 09:05:27 EDT Received: from WOMBAT.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA15924; Tue, 10 Oct 89 09:03:57 EDT From: epeisach@ATHENA.MIT.EDU Received: by WOMBAT.MIT.EDU (5.61/4.7) id AA12375; Tue, 10 Oct 89 09:03:49 -0400 Date: Tue, 10 Oct 89 09:03:49 -0400 Message-Id: <8910101303.AA12375@WOMBAT.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Computer Viruses set to go off on October 12 and 13 on PC's *** EOOH *** From: epeisach@ATHENA.MIT.EDU Date: Tue, 10 Oct 89 09:03:49 -0400 To: staff@ATHENA.MIT.EDU Subject: Computer Viruses set to go off on October 12 and 13 on PC's I have no way to determine if this is true, or not, but it was posted to news.announce.important. Use your own judgement. Ezra -------------------------------- Message-ID: <129@stargate.COM> Date: 10 Oct 89 01:31:13 GMT Sender: mark@stargate.COM Lines: 25 There are a pair of computer viruses ready to go on October 12 and 13 of this year. If you have an IBM or compatible PC, you may have a virus on your system. If your .COM or .EXE files have grown by 1000 or so bytes, they may be infected. One virus is known as the Jerusalem virus, and is set to go off on or after the next Friday the 13th. It can add itself to your executable files, slow down your system, and in some cases erase your hard disk. The other is the DATACRIME virus. It is not as common as the Jerusalem virus, but will immediately and without warning wipe out your disk. You are strongly urged to take a complete backup of your disks before the 12th. Since viruses often spread through public domain software, use of binary software that is not shrink wrapped should be avoided. There are commercial virus detection programs on the market. One is the ViruScan program from McAfee Associates, in California. It detects some 39 viruses (in the 9-28-89 version.) Their telephone number is 408-988-3832. Another source is Rikki Cate, in Amsterdam. The product, Cate's Cure, detects the DATACRIME virus. Cate's telephone is 31-20-981963 in the Netherlands.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17164; Tue, 10 Oct 89 11:05:45 EDT Received: from FUTURE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA17764; Tue, 10 Oct 89 11:05:01 EDT Received: by FUTURE.MIT.EDU (5.61/4.7) id AA24229; Tue, 10 Oct 89 11:04:54 -0400 Message-Id: <8910101504.AA24229@FUTURE.MIT.EDU> To: appdev@ATHENA.MIT.EDU, userservices@ATHENA.MIT.EDU Cc: orcutt@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: App Dev/User Services Mtg 11 Oct 1989 Date: Tue, 10 Oct 89 11:04:51 EDT From: Jacqueline A. Stewart *** EOOH *** To: appdev@ATHENA.MIT.EDU, userservices@ATHENA.MIT.EDU Cc: orcutt@ATHENA.MIT.EDU, staff@ATHENA.MIT.EDU Subject: App Dev/User Services Mtg 11 Oct 1989 Date: Tue, 10 Oct 89 11:04:51 EDT From: Jacqueline A. Stewart From: Jackie Stewart Telephone: 3-5226 To: Beth Anderson Gary Bean Sharon Belville Andrew Borthwick-Leslie Roman Budzianowski David Carver Bill Cattey Kevin Cunningham Ben Davis Gary Dryfoos Carla Fermann Dan Geer Jud Harward Matt Hodges Beth Kevles Anne LaVin Aida Liu Bryan Michon Jon Monsarrat Mark Moormans Jim Rees Russ Sasnett Evelyn Schlusselberg Naomi Schmidt Michael Webster cc: Ron Orcutt staff APPLICATIONS DEVELOPERS/USER SERVICES MEETING --------------------------------------------------------------------------- Date: Wednesday, 11 Oct 1989 AGENDA Time: 1:00 pm - 2:30 pm: pls. be prompt Place: E40-382 (Third floor Large Conference room) 1. EDUCOM planning/Athena coverage. 2. MIT Family weekend planning (sched. Sat. 21 Oct). 3. OSF research project final activities/Faculty Forum planning (sched. 30 or 31 Oct.) 4. Other stuff people are working on. ************** --------------------------------------------------------------------------- Note: Next scheduled meeting: Wednesday, 9 August 1989, 1:00 pm - 3:00 pm Topic: Fall readiness (yes, again) [appdev_us_agenda]  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05141; Wed, 11 Oct 89 11:57:07 EDT Received: from E40-334-3.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA13117; Wed, 11 Oct 89 11:56:59 EDT From: rap@ATHENA.MIT.EDU Received: by E40-334-3.MIT.EDU (5.61/4.7) id AA09660; Wed, 11 Oct 89 11:56:52 -0400 Date: Wed, 11 Oct 89 11:56:52 -0400 Message-Id: <8910111556.AA09660@E40-334-3.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: bug in help module *** EOOH *** From: rap@ATHENA.MIT.EDU Date: Wed, 11 Oct 89 11:56:52 -0400 To: argus2@ATHENA.MIT.EDU Subject: bug in help module the help module should do the indenting. I should not get output like this: notes: The first non-switch argument is assumed to be the ruleset name. The second non-switch argument is assumed to be a rule number to edit. If neither the -rule, -before, or -after options are specified the ruleeditor will create a new rule to be appended to the end of the ruleset. The -RS and -SV options are mutually exclusive. The -force option only has significance when creating a new rule set (i.e. the rule set specified does not exist yet). when the input looks like this: The first non-switch argument is assumed to be the ruleset name. The second non-switch argument is assumed to be a rule number to edit. If neither the -rule, -before, or -after options are specified the ruleeditor will create a new rule to be appended to the end of the ruleset. The -RS and -SV options are mutually exclusive. The -force option only has significance when creating a new rule set (i.e. the rule set specified does not exist yet). i.e. either the fist line should not be indented like that or they all should be indented. In either case it should not distort what I pass to it to be printed.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05629; Wed, 11 Oct 89 12:25:46 EDT Received: from PORTNOY.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA13825; Wed, 11 Oct 89 12:23:24 EDT From: marc@ATHENA.MIT.EDU Received: by PORTNOY.MIT.EDU (5.61/4.7) id AA12245; Wed, 11 Oct 89 12:23:18 -0400 Message-Id: <8910111623.AA12245@PORTNOY.MIT.EDU> To: staff@ATHENA.MIT.EDU, sipb@ATHENA.MIT.EDU, ursabear@ATHENA.MIT.EDU Subject: [Questions/comments/flames E-MAIL to:: New Med Center combo] Reply-To: marc@ATHENA.MIT.EDU Usmail: Marc Horowitz, 3 Ames Street, Cambridge, MA 02139 Phone: (617)225-6447 Date: Wed, 11 Oct 89 12:23:15 EDT *** EOOH *** From: marc@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU, sipb@ATHENA.MIT.EDU, ursabear@ATHENA.MIT.EDU Subject: [Questions/comments/flames E-MAIL to:: New Med Center combo] Reply-To: marc@ATHENA.MIT.EDU Usmail: Marc Horowitz, 3 Ames Street, Cambridge, MA 02139 Phone: (617)225-6447 Date: Wed, 11 Oct 89 12:23:15 EDT Don't say I forwarded it. ;-) ------- Forwarded Message Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA04800; Wed, 11 Oct 89 11:39:10 EDT Received: from [18.62.3.101] by ATHENA.MIT.EDU with SMTP id AA12610; Wed, 11 Oct 89 11:36:51 EDT Received: by JAMES-BLISH.MIT.EDU (5.61/4.7) id AA20726; Wed, 11 Oct 89 11:35:49 -0400 Message-Id: <8910111535.AA20726@JAMES-BLISH.MIT.EDU> To: gli@ATHENA.MIT.EDU Subject: New Med Center combo Date: Wed, 11 Oct 89 11:35:47 EDT From: Questions/comments/flames E-MAIL to: The new combination for the med center is 4513. But I didn't say that. MJB ------- End of Forwarded Message  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09942; Wed, 11 Oct 89 16:01:22 EDT Received: from E40-342F-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA20269; Wed, 11 Oct 89 15:59:17 EDT From: geer@ATHENA.MIT.EDU Received: by E40-342F-2.MIT.EDU (5.61/4.7) id AA01268; Wed, 11 Oct 89 15:59:12 -0400 Message-Id: <8910111959.AA01268@E40-342F-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: re: Results of X Word Processors Date: Wed, 11 Oct 89 15:59:10 EDT *** EOOH *** From: geer@ATHENA.MIT.EDU To: staff@ATHENA.MIT.EDU Subject: re: Results of X Word Processors Date: Wed, 11 Oct 89 15:59:10 EDT fyi. --dan ------- Forwarded Message Date: 10 Oct 89 18:48:34 GMT Organization: Jet Propulsion Laboratory, Pasadena, CA. Subject: Results of X Word Processors To: xpert@EXPO.LCS.MIT.EDU Thanks to all that responded to my request for information about word processors that run on X Windows. My comments and useful information retrieved during my search are in brackets following the address. So, here are the results which are in no particular order. 1. FrameWriter by Frame Technology Corporation 2911 Zanker Road San Jose, CA 95134 USA (408) 433-3311 (800) 843-7263 [They can send you a free demonstration tape of FrameMaker, a full desktop publishing system. FrameWriter is a product distributed with FrameMaker. It may be purchased separately for < $1000.] 2. Publisher by ArborText, Inc. 535 West William Street Ann Arbor, MI 48103 (313) 996-3566 help@arbortext.com uunet!umix!arbortext!help The Sun Sparcware Catalyst catalog states that a demonstration copy of Publisher is available. No prices. The sales rep is supposed to get back to me soon. 3. DECwrite by DEC (for VAX and DECstations only) [No comment] [These last two are products that I have seen on Sun workstations but not necessarily under X Windows. The comments received from gracious contributors did not specifically state that these run under X. So I advise you to inquire for yourself. Unless someone can clarify or enlighten.] 4. Alis by Applix Inc. [I have used this product on a Sun 3 and found it awkward and difficult. Alis encorporates many more functions than a simple word processor; it has e-mail, a drawing tool, reminder service, calendar, and other office automation tools. Alis is not supported on Sun 4's so I have not researched it any further.] 5. Interleaf by Interleaf, Inc. Ten Canal Park Cambridge, MA 02141 USA (617) 577-9800 (800) 241-7700 [Rumor has it that is it *expensive* ! > $5000] Disclaimer: I have no affiliation with any of the above companies, but I may have my preferences ;-) Enjoy, - -Basil "Be X ellent to each other" "Party on, dude" Basil Hashem hashem@mars.jpl.nasa.gov Jet Propulsion Laboratory (818)354-2936 ------- End of Forwarded Message  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA12864; Wed, 11 Oct 89 18:45:56 EDT Received: from GEVALT.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA24517; Wed, 11 Oct 89 18:43:21 EDT From: amgreene@ATHENA.MIT.EDU Received: by GEVALT.MIT.EDU (5.61/4.7) id AA19463; Wed, 11 Oct 89 18:43:16 -0400 Date: Wed, 11 Oct 89 18:43:16 -0400 Message-Id: <8910112243.AA19463@GEVALT.MIT.EDU> To: geer@ATHENA.MIT.EDU Cc: staff@ATHENA.MIT.EDU In-Reply-To: geer@ATHENA.MIT.EDU's message of Wed, 11 Oct 89 15:59:10 EDT <8910111959.AA01268@E40-342F-2.MIT.EDU> Subject: Results of X Word Processors For whatever it's worth, I saw Alis this summer and was not impressed. Slate (running under SunView but promised for X `rsn') was a bit more impressive, and also a word-processor/mail/image/sound job. ArborText does a good amount of TeX support and they were pushing Publisher at the TUG conference this summer; their equation editor apparently does a good job of outputting TeX source. (Sorry, Bill :-) Just my \$0.02 - Andrew  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13066; Wed, 11 Oct 89 18:58:03 EDT Received: from DECWRL.DEC.COM by ATHENA.MIT.EDU with SMTP id AA24833; Wed, 11 Oct 89 18:57:48 EDT Received: by decwrl.dec.com; id AA28952; Wed, 11 Oct 89 15:57:22 -0700 Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA05696; Wed, 11 Oct 89 18:55:58 EDT Date: Wed, 11 Oct 89 18:55:12 EDT From: treese@CRL.DEC.COM Message-Id: <8910112255.AA01010@cirocco.DEC.COM> To: bgardner@ATHENA.MIT.EDU, rap@ATHENA.MIT.EDU Subject: Argus release Cc: treese@CRL.DEC.COM Was there a "release" of Argus? If so, could I get a copy? Thanks, Win  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13267; Wed, 11 Oct 89 19:11:20 EDT Received: from PINK.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA25092; Wed, 11 Oct 89 19:11:08 EDT From: bgardner@ATHENA.MIT.EDU Received: by PINK.MIT.EDU (5.61/4.7) id AA02489; Wed, 11 Oct 89 19:10:59 -0400 Date: Wed, 11 Oct 89 19:10:59 -0400 Message-Id: <8910112310.AA02489@PINK.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: Re: bug in help module This is not a bug in the help module. You are invoking the function incorrectly. You should be passing the function an array of strings, rather than passing it one huge string with '\n' s in it. The help function does, in fact, indent for each string in the array of strings passed to it. (See the rulebrowser's -h output for reference). -- brian  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13519; Wed, 11 Oct 89 19:30:19 EDT Received: from XEROX.COM by ATHENA.MIT.EDU with SMTP id AA25486; Wed, 11 Oct 89 19:29:57 EDT Received: from Salvador.ms by ArpaGateway.ms ; 11 OCT 89 16:18:49 PDT Date: 11 Oct 89 16:18 PDT From: Wendy Wmackay Subject: finding files To: rap@ATHENA.MIT.EDU Cc: wmackay.pa@XEROX.COM Message-Id: <891011-161849-4069@Xerox> Rich, Hi. I've been trying for several days to get through. Does e40-315-5.mit.edu still have access on? I talked to David Chinn and said nice things... He didn't seem surprised. How's it going? Wendy  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA14712; Wed, 11 Oct 89 21:01:27 EDT Received: from E40-334-3.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA27317; Wed, 11 Oct 89 21:01:17 EDT From: rap@ATHENA.MIT.EDU Received: by E40-334-3.MIT.EDU (5.61/4.7) id AA10187; Wed, 11 Oct 89 21:01:10 -0400 Date: Wed, 11 Oct 89 21:01:10 -0400 Message-Id: <8910120101.AA10187@E40-334-3.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: yaaaaaaahhhh and arrrrrghhh the yaaaaaaah is I got the job at the OSF!"!!! the argggggg is I just spent 3 hours looking for a 'bug' in my code and it turns out I had a corrupt cache on one of my machines!!! Boy that'll really do ya' Now, when you encounter a really hard bug I have a small list of questions to ask. is it my code? /* logical place to start */ is it MOTIF? /* most bug searches stop here */ is it my cohorts code? /* tempers begin to flare */ is it a bad compile? /* easily tested, just recompile */ is it a compiler bug? /* give up, shoot yourself, or call Jeff */ are all the appropriate lockers attached? /* i.e. can the program read the dot file in your home directory? */ they may be attached but are they working? /* start pinging everything in sight or just watch your workstation hang as you do a df */ And now, theres the BIG one? (drumroll please) is your cache corrupt? /* i.e is any file you have possibly used in any way since they installed AFS on your machine corrupt? Easy to find out, just read the copious documentation on AFS and the fizz command (that is, the fs command). I like to think that I need to use FS when my workstation is FraSsled. */ Got it? Good. Frustratingly yours, __Rich.  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA14935; Wed, 11 Oct 89 21:18:15 EDT Received: from decwrl.dec.com by ATHENA.MIT.EDU with SMTP id AA27654; Wed, 11 Oct 89 21:18:09 EDT Received: by decwrl.dec.com; id AA08697; Wed, 11 Oct 89 18:12:36 -0700 Date: Wed, 11 Oct 89 18:12:35 -0700 Message-Id: <8910120112.AA08697@decwrl.dec.com> From: bock@XANADU.ENET.DEC.COM (BOSE A/D -- DTN 381-0898) To: "rap@ATHENA.MIT.EDU"@DECWRL.DEC.COM Subject: RE: my resume as text Rich -- Just talked to David Chin at OSF today -- where I understand you are a candidate for a job in their systems engineering group. He asked the usual questions and I could recommend you to him whole- heartedly, and without any qualifications. Good luck and I hope you get the offer. /geoff  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15038; Wed, 11 Oct 89 21:27:11 EDT Received: from CS.BU.EDU by ATHENA.MIT.EDU with SMTP id AA27790; Wed, 11 Oct 89 21:26:52 EDT Received: by CS.BU.EDU (5.58/4.7) id AA28157; Wed, 11 Oct 89 21:27:46 EDT Date: Wed, 11 Oct 89 21:27:46 EDT From: operator@CS.BU.EDU (Operations Central) Message-Id: <8910120127.AA28157@CS.BU.EDU> To: adb@CS.BU.EDU, alpert@CS.BU.EDU, anne@CS.BU.EDU, aps@CS.BU.EDU, atkins@CS.BU.EDU, carter@CS.BU.EDU, cesar@CS.BU.EDU, chungf@CS.BU.EDU, cobra@CS.BU.EDU, composer@CS.BU.EDU, connell@CS.BU.EDU, dermer@CS.BU.EDU, ebraude@CS.BU.EDU, esmith@CS.BU.EDU, gale@CS.BU.EDU, gene@CS.BU.EDU, hoffer@CS.BU.EDU, joshua5@CS.BU.EDU, lost+found@CS.BU.EDU, lynch@CS.BU.EDU, maurice@CS.BU.EDU, mds@CS.BU.EDU, pravin@CS.BU.EDU, rap@CS.BU.EDU, raymond@CS.BU.EDU, robotron@CS.BU.EDU, rsin@CS.BU.EDU, rwd@CS.BU.EDU, sciore@CS.BU.EDU, susskin@CS.BU.EDU, tak@CS.BU.EDU, tamale@CS.BU.EDU, tasos@CS.BU.EDU, tiuryn@CS.BU.EDU, ven@CS.BU.EDU, wehrli@CS.BU.EDU, yates@CS.BU.EDU, york@CS.BU.EDU Subject: Disk space Cc: operator@CS.BU.EDU /usr16 is 98% full right now. It has been going up to 100%. Please try to clean out your directories before the partition over- flows. Thank you. -operations (russ)  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA16950; Wed, 11 Oct 89 23:32:57 EDT Received: from E40-334-3.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA00804; Wed, 11 Oct 89 23:32:49 EDT From: rap@ATHENA.MIT.EDU Received: by E40-334-3.MIT.EDU (5.61/4.7) id AA10374; Wed, 11 Oct 89 23:32:41 -0400 Date: Wed, 11 Oct 89 23:32:41 -0400 Message-Id: <8910120332.AA10374@E40-334-3.MIT.EDU> To: argus2@ATHENA.MIT.EDU Subject: more cache bugs I am leaving and recompiling on another vax. It should be better, I hope. __RTich  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA18154; Thu, 12 Oct 89 01:09:06 EDT Received: from TABETHA.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA02521; Thu, 12 Oct 89 01:05:59 EDT From: paul@ATHENA.MIT.EDU Received: by TABETHA.MIT.EDU (5.61/4.7) id AA01267; Thu, 12 Oct 89 01:05:52 -0400 Date: Thu, 12 Oct 89 01:05:52 -0400 Message-Id: <8910120505.AA01267@TABETHA.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Paul is away until Monday October 23rd I will be doing three weeks of 6.170 homework and then going to Educom. I expect to read my mail from there, though. -Paul  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21080; Thu, 12 Oct 89 09:11:18 EDT Received: from E40-391A-2.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA07415; Thu, 12 Oct 89 09:10:13 EDT Received: by E40-391A-2.MIT.EDU (5.61/4.7) id AA03133; Thu, 12 Oct 89 09:10:08 -0400 Message-Id: <8910121310.AA03133@E40-391A-2.MIT.EDU> To: staff@ATHENA.MIT.EDU Subject: Absence for EDUCOM Conference Date: Thu, 12 Oct 89 09:10:04 EDT From: Ronald L. Orcutt Beginning tomorrow, Friday, I will away from MIT attending the EDUCOM Conference at U. Michigan (Ann Arbor). I should be back at MIT on Friday, Oct. 20. Mary Gibson will handle all administrative matters, and will be able to contact me during this period, if need be. Earll Murman will be here at MIT during this period, except for Wednesday and Thursday, Oct. 18 & 19, and will be able to handle any non-administrative matters.