tony@tui.marcam.dsir.govt.nz (Tony Cooper) (05/26/91)
I have confirmed that there definitely a bug in the glue code for the standard file package under A/UX 2.0.1. There is an (A1) which should be an A1. This causes the SF dialogs to be placed at (0,0) instead of at the user-specified position. But I have not managed to isolate the cause of the SF Package crash that I mentioned a few weeks ago. I do not think it is a bug in the glue code, but rather a bug in some initialisation somewhere. Under A/UX 2.0 it does not crash but it does do some corruption to the system. So this bug had been around for quite a while and seems to make it impossible to write code using the SF Package under A/UX. I have written this report in lieu of sending a SPR (since I'm not sure how to send SPR's). So if an Apple person reads this please take note (and please fix it). Cheers, Tony Cooper sramtrc@albert.dsir.govt.nz (the only person in the known universe to have used the SF Package under A/UX 2.0.x).
liam@cs.qmw.ac.uk (William Roberts;) (05/28/91)
In <1991May26.110152.27421@am.dsir.govt.nz> tony@tui.marcam.dsir.govt.nz (Tony Cooper) writes: >I have written this report in lieu of sending a SPR (since I'm not >sure how to send SPR's). So if an Apple person reads this please >take note (and please fix it). The stuff about SPRs seemed to go with the beta releases. At the considerable risk of discussing in public aspects of Beta systems, here is the little script I use to create an SPR: ---------------------------------------------------------- # Fill in bits of an spr form to match the system FORM=/tmp/spr SPR_PREFIX=/users/system/liam/aux/sprs/spr NEXT=/users/system/liam/aux/sprs/NEXT cat >$FORM <<'----' ((( A/UX SOFTWARE PROBLEM REPORT ))) -- FILL IN ALL THE FIELDS IN [brackets] -- SUMMARY: [please enter a brief 1 line summary of the problem] SUBMITTED BY: William Roberts (liam@cs.qmw.ac.uk) COMPANY: Computer Science Department, QMW, University of London ADDRESS: Mile End Road, London E1 4NS, England PHONE #: +44 1 975 5250 ---- echo "DATE: " `/bin/date` >>$FORM echo "SYSTEM NAME: " `/bin/hostname` `uname -m` >>$FORM echo "RELEASE: " `/bin/uname -srv` >>$FORM echo "COMPONENT: ?" read COMPONENT echo "COMPONENT: " $COMPONENT >>$FORM echo "CMPNT VERSION: " >>$FORM version $COMPONENT >>$FORM 2>&1 cat >>$FORM <<'----' DESCRIPTION: REPEAT BY: OTHER: ---- vi $FORM cat >>$FORM <<'----' -------------------------------------------------------------------- < RESOLUTION TO BE ENTERED BY THE PERSON RESOLVING THE PROBLEM> (1)RESOLVED (2)NOT A BUG (3)COULD NOT REPRODUCE (4)DOCUMENTATION PROBLEM (5) SUGGESTION OR COMMENT ASSIGNED TO: RESOLUTION: enter 1 character from the set above RESOLVED BY: DATE RESOLVED: SEVERITY LEVEL: choose 1 of 4 1) SEVERE CAUSES - FATAL ERROR 2) MAJOR FUNCTIONAL DEFECT 3) MINOR FUNCTIONAL DEFECT 4) COSMETIC RELEASE # CONTAINING FIX: SOURCE FILES AFFECTED: BINARY FILES AFFECTED: DOCUMENTATION FILES AFFECTED: OTHER: ---- NUMBER=`cat $NEXT` expr $NUMBER + 1 >$NEXT cat $FORM > $SPR_PREFIX$NUMBER echo created $SPR_PREFIX$NUMBER --------------------------------------------------------- I tend to run this on the system where I've recreated the bug - change the relevant details to suit your name, address etc. I also find it helps to number these things yourself, so that you can keep track of them if nothing else. The place you mail them to varies from time to time. Once upon a time it used to be reports@aux.support.apple.com, but now I just send them to my local friendly Developer Technical Services, in my case UK.DTS@applelink.apple.com. The advantage of mailing these things to DTS is that they tend to acknowledge them: particularly during beta testing the reports@aux.support.apple.com address seemed to be a black hole, even though things did get fixed in later releases. Is this all correct, you Apple folks? Would you rather have bug reports submitted like this than random postings on comp.unix.aux? Is there anything important that I've forgotten? -- William Roberts Internet: liam@dcs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: +44 71-975 5234 (Fax: +44 81-980 6533)
ksand@apple.com (Kent Sandvik) (05/28/91)
In article <3104@redstar.cs.qmw.ac.uk>, liam@cs.qmw.ac.uk (William Roberts;) writes: > The place you mail them to varies from time to time. Once upon a time it used > to be reports@aux.support.apple.com, but now I just send them to my local > friendly Developer Technical Services, in my case UK.DTS@applelink.apple.com. > > The advantage of mailing these things to DTS is that they tend to acknowledge > them: particularly during beta testing the reports@aux.support.apple.com > address seemed to be a black hole, even though things did get fixed in later > releases. > Is this all correct, you Apple folks? Would you rather have bug reports > submitted like this than random postings on comp.unix.aux? Is there anything > important that I've forgotten? In general MacDTS works with registered developer questions, so most of our resources are working on those questions of natural reasons (they pay for the service, so they get the major service). Also most of our registered developers are working on important software packages, and as working for a software company everyone knows that quick response is very important, especially in times such as these when time-to-market dictates how much you earn. Anyway, reports@aux.support.com is maybe the most logical place for sending bug reports. Unfortunately they can't acknowledge every posted bug report, mostly due to resource limitations as well. I tend to get bugs and wonderings posted to my account now and then, and trust me, I have them all in my TODO-folder, but sometimes I can't spend so much time on those even if I want to. This newsgroup is a great way to make use of the extended A/UX knowledge out there in the field. Originally Usenet was the feeding ground and inofficial support channel for UNIX, and hopefully we could continue to use this newgroup for any kind of one-to-many support. Regards, Kent Sandvik, Flatworms Group, DTS
urlichs@smurf.sub.org (Matthias Urlichs) (06/12/91)
In comp.unix.aux, article <13673@goofy.Apple.COM>,
ksand@apple.com (Kent Sandvik) writes:
<
< Anyway, reports@aux.support.com is maybe the most logical place for sending
< bug reports. Unfortunately they can't acknowledge every posted bug report,
< mostly due to resource limitations as well.
<
It should be trivial to install a simple autoreply daemon, at least, so that
I know that the bug report has in fact reached aux.support.apple.com.
< I tend to get bugs and wonderings posted to my account now and then, and
< trust me, I have them all in my TODO-folder, but sometimes I can't spend so
< much time on those even if I want to.
<
You aren't the only guy/gal who has that problem... :-(
< This newsgroup is a great way to make use of the extended A/UX knowledge
< out there in the field. Originally Usenet was the feeding ground and
< inofficial support channel for UNIX, and hopefully we could continue to use
< this newgroup for any kind of one-to-many support.
<
100% agreement here.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/tony@tui.marcam.dsir.govt.nz (Tony Cooper) (06/13/91)
The only bugs involved here are the moths in my brain. I reported a bug where the SF C routines (ie the lowercase-named routines such as sfgetfile) required sfgetfile(&where, ...) instead of sfgetfile(where, ...). Well this is not a bug at all. It is supposed to be that way and is clearly documented in the A/UX toolbox guides (both 1.1 and 2.0). My problem was that I thought the lowercase routines were just for using C strings (instead of Pascal) and I completely forgot that Points were different as well. I don't know why points are treated differently since both points and pointers to points are 4 byte quantities, but I'm not much of a MacOS programmer so I don't have a very good grasp of this stuff anyway. And I mentioned in an earlier posting that sfgetfile crashed the system when run under A/UX and compiled with cc. Well I don't know what caused the crash but I do know that I can avoid it if I call WaitNextEvent three times before sfgetfile (or SFGetFile or ...) then the crash doesn't occur. Cheers, Tony Cooper PS The newly announced hybrid programming environment looks pretty good. Bit beyond my price range (cc is "free" and I use THINK C on the other side) especially considering that A/UX currently has X11R4 programming tools and a C compiler that compiles MacOS source already. It's hard to see what you get extra for the money. the ANSI compiler gets included "free" in future upgrades of A/UX.