HDTenEightyP/NetNews huggingface dataset:
From: lithgow@usl.com (Malcolm Lithgow)
Newsgroups: comp.sys.acorn
Subject: ANSI, ISO, and other funny stories [Was Re: 'volatile' in Norcroft/Acorn C"]
Date: 1 Oct 92 02:26:05 GMT

[In message "Re: 'volatile' in Norcroft/Acorn C", Mark Taunton writes:]
>In article <9209300424.AA02872@ucbvax.Berkeley.EDU> lithgow@usl.com (Malcolm Lithgow) writes:
>>[In message "Re: 'volatile' in Norcroft/Acorn C", Andrew P.Mell writes:]
>>>Talking of ANSI compliance are the format specifiers for strftime()
>>>well defined?
[...]
>>Possibly neither. The I18N (internationalization) functions (including
>>strftime()) have finally been standardized by the ISO MSE committee
>>(MSE is Multi-Byte Extensions -- my speciality recently,
>>unfortunately).
[...]
>
>Nit-pick mode *ON*.
>
>The question was about *ANSI* compliance, not about compliance with
>recent ISO revisions/extensions to a language definition originally
>based on the ANSI C standard.
>Sometime after the
>full ISO C standard, complete with I8N stuff and whatever else,
>becomes final, then you might perhaps see vendors such as Acorn
>providing compilers to accept and implement it.  Until then, the
>answer to Andy's question (though this is not an official Acorn
>response) is:
>
>"Yes, talking of ANSI compliance, the format parameters to strftime()
>*are* well defined.  The Acorn C language system is designed and
>intended to implement them according to the ANSI C standard."
>
>Nit-pick mode *OFF*.

OK. You're right, and I wasn't trying to criticise Acorn, except...

Stand-on-my-soapbox mode *ON*. ;-)

ANSI standard C is an anachronism and is rapidly coming to have no
meaning whatsoever, because:

a) The ANSI draft was rubber-stamped by ISO a few years back, and so
ANSI standard C is also ISO standard C, since ANSI is US-specific and
ISO international, ISO takes precedence over ANSI (a fact which ANSI
recognizes, I believe).

b) The I18N stuff in ANSI is a joke (as you would expect from an
American standards group) and so ISO MSE is desperately needed,
particularly for multibyte work. Of course, ISO MSE is also a joke, but
not quite as hilarious as ANSI's attempt.

c) ISO MSE is already implemented/will be implemented in the next few
months by a range of vendors.

Stand-on-my-soapbox mode *OFF*.

Having said that, I don't think Acorn is particularly interested in
multibyte environments, so ISO MSE won't give them much extra.

Also, Acorn's is the best ANSI-compliant compiler I have come across,
and seems particularly good compared to UNIX compilers.

-Malcolm.  lithgow@usl.com  These are merely my opinions.
Newsgroups: comp.sys.acorn
Subject: Arrggggh! dead email! Arrghrgggh!
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Mon, 5 Oct 1992 23:07:52 GMT
Organization: Computer Science Dept. University of Auckland

The mailer here quietly died last week, and it's only just been noticed
and fixed. So, to the following people, the reason you haven't heard
from me is that my email simply vanished into the twilight zone...

I have no idea what I said in most of these messages, so I'm unlikely
to repeat them...

Oct  5 15:38:28 from=jwil1@cs7 to=vulch@kernow.demon.co.uk, 
Oct  5 16:03:07 from=jwil1@cs7 to=banks_p@kosmos.wcc.govt.nz, 
Oct  5 16:15:39 from=jwil1@cs7 to=nas20@phx.cam.ac.uk, 
Oct  3 12:32:42 from=jwil1@cs7 to=Gavin.Flower@comp.vuw.ac.nz, 
Oct  3 12:56:00 from=jwil1@cs7 to=banks_p@kosmos.wcc.govt.nz, 
Oct  2 08:58:07 from=jwil1@cs7 to=banks_p@kosmos.wcc.govt.nz, 
Oct  2 13:09:48 from=jwil1@cs7 to=nas20@phx.cam.ac.uk, 
Sep 29 10:49:20 from=jwil1@cs7 to=Ikki@BEIZ.mediatex.ch, 
Sep 29 10:59:27 from=jwil1@cs7 to=gkapog@leon.nrcps.ariadne-t.gr, 
Sep 29 11:02:31 from=jwil1@cs7 to=gunnar@fasel.hotb.sub.org, 
Sep 29 11:32:38 from=jwil1@cs7 to=banks_p@kosmos.wcc.govt.nz, 
Oct  1 14:17:04 from=jwil1@cs7 to=loek@nt.eltn.utwente.nl, 
Oct  1 14:34:18 from=jwil1@cs7 to=banks_p@kosmos.wcc.govt.nz, 

Several of you may recieve some panicked email in the near future ;-)
(It would be *this* week, wouldn't it? Argh!)
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.sys.acorn
Subject: Division and remainder (was Re: Yes, more .....)
Date: 6 Oct 92 11:20:24 GMT
Organization: Department of Computer Science, U of Copenhagen

kjetilho@ifi.uio.no (Kjetil Torgrim Homme) writes:

>Still, it is important that the programmers know how their machines
>work, and do as much as they can to give the compiler a hint. For
>example, a program I wrote on my BBC A3000 used the construct (var %
>16), and out of curiousity, I checked what the machine code generated
>was. To my amazement, it didn't just do (var AND 15), but did some
>weird checking. (var % 16) != (var AND 15) for negative var. So I
>changed the declaration of var from int to unsigned int, and sure
>enough, the compiler did the obvious thing. It was a lesson to me,
>anyway :-)

The ANSI C standard actually doesn't specify how division and
remainder (/ and %) work on negative integers. It allows (-3)/2 to be
either -1 or -2 and (-3)%2 to be either -1 or 1. As far as I recall,
it doesn't even specify that the behavious have to match, i.e. that
the equation x==(x/n)*n+x%n should hold, but that is probably an
oversight (and I can't imagine any implementation not doing this). I
much prefer that divison always round down and that x%n always lie
between 0 and n-1. Rounding towards zero and having signed remainders
is old bagage from ones complement machines. With "proper" division
and remainder you can always use x&15 for x%16, even if x is signed,
and you can always use x>>4 for x/16 (if >> is arithmetic shift).

So, Acorn would be justified in changing the behaviour of / and %.
Maybe they could add other operators that correspond to the
"old-fashioned" division and remainder. In the true C style, they
could call these // and %% ;-).

Some newer languages (like SML) specify that division must round down
and that remainder must be non-negative.

	Torben Mogensen (torbenm@diku.dk)
From: ainsjc@aisb.ed.ac.uk (Steffan)
Newsgroups: comp.sys.acorn
Subject: Deskjet 500 confusion...
Date: 28 Sep 92 13:19:21 GMT
Reply-To: ainsjc@aifh.ed.ac.uk (Steffan)
Organization: Dept AI, Edinburgh University, Scotland

I've had a Deskjet 500 printer for 6 months now and have constantly been
annoyed by the fact that it leaves a large margin (approx. 32mm) at the
bottom of the page, on which you cannot print.

However, I've recently come to the conclusion that the margin shouldn't
be this large. The RISC OS printer driver shows a far smaller margin,
and also a larger top margin then I get. The Deskjet manual mentions a
bottom margin of half an inch.

So I had another go at flipping the DIP switches. They were set to A4
paper and no perforation skip, but as far as I can work out it was
printing as though using US Letter paper.

After a while studying the (fairly useless) manual, I came to the
conclusion that the conclusion that the printer should be set up for A4
paper and perforation skip enabled. However, making this change made
absolutely no difference (yes, I did switch the computer off then on
again afterwards).

After changing a few times between US Letter and A4, it suddenly started
leaving a far smaller bottom margin when printing from BASIC. In fact,
the following program:

10VDU2
20FOR I%=1 TO 100:P.;I%:N.
30VDU1,12,3

had the effect of printing the first 68 numbers on the first sheet, but
then printed 69 and 70 on the second sheet, performed a form feed and
continued on a third sheet! Bizarre.

However, having now got some semlance of A4 printing, I still get a
large bottom margin, because I still get no gap at the top of the sheet.
I could rectify this by changing the print borders in the RISC OS
printer driver, but I'd prefer to get the whole thing working. I suspect
my problem is that the DIP switches are loose, and so any changes to
them have intermittent effect.

However, I bought the printer mail order from Watford. So I'm unkeen on
sending it back without being absolutely sure there is something wrong,
rather than I'm just being stupid.

So I have four questions:

1. Am I right in thinking that the bottom margin on a Deskjet printer
should be about half an inch (or three quarters with perforation skip
on) rather than the 32mm I'm getting?

2. What are the correct settings of (all) the DIP switches on my printer for
use with an Archimedes.

3. I tried setting the perforation skip on by sending a command from the
computer, and then printing a file from Impression, but this made
absolutely no difference - still no top margin. (i.e. everything came
out 11mm higher on the paper than it was shown on the screen). My explanation
for this is that the printer driver probably reset the printer before it
started printing. Do RISC OS printer drivers do this?

4. Has anyone got any ideas of how to test for sure whether there is a
fault.

Thanks a lot for any help.

Steffan.
From: mjw19@cl.cam.ac.uk (M.J. Williams)
Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
Date: 3 Oct 92 20:49:19 GMT
Reply-To: mjw19@phx.cam.ac.uk (M.J. Williams)
Organization: The National Society for the Inversion of Cudddly Tigers

In article <1992Oct2.085647.16339@infodev.cam.ac.uk> ph10@cus.cam.ac.uk (Philip Hazel) writes:
>I maintain a screen-oriented text editor which runs on the following platforms:
>
>o   IBM mainframe, MVS operating system (SSMP & 3270 terminals)
>o   Several flavours of Unix, including SunOS & Ultrix (SSMP & termcap
>    terminals)
>o   VAX/VMS (SSMP & VTxxx terminals)
>o   Acorn's RISC OS (& previously Arthur & previously the ARM development
>    system), though not as a WIMP application
>o   Panos (Acorn's OS for 32016-based Acorn Cambridge Workstation - never
>    really took off as a machine)
>o   MS-DOS

  Yeah, and, if I may say so, well good it is too. I appear to be using it now
  and not gnuemacs, because I can actually understand the commands, and, and
  here is the relavent bit, I learnt to use the MVS version before I got onto
  Unix. Thankfully because PH10 had decided to write it mainly in BCPL (unlike
  its big brother which was written entirely in 370 assembler), when I finally
  got tired of xedit, and gave up on vi, there was a powerful, programmable
  editor sitting there on Ultrix that I actually knew how to use. Had he
  plumped for 370 assembler then I would be trying to manipulate all seven
  hands at once (and we all know how difficult that can be, kiddies!) to get
  gnuemacs to work ("type M-C-x-C-v-p to bring up a picture of Richard Stallman
  in text-print mode, and then press C-v-x-u-g to convert it into a picture of
  a bunny rabbit eating a ferrari."). The only learning curve was learning to
  use a different name to load it.

  Oh, the Archi version does have one fault, I'm afraid. It turns off the mouse
  pointer on entry, and so does not work from a !TaskTool or similar TaskWindow
  program...

_______________________________________________________________________________
 \   ^   / Michael Williams                     Part II Computer Science Tripos
  |\/|\/\  MJW19@phx.cam.ac.uk                          University of Cambridge
  |  |(__) Cymdeithas Genedlaethol Traddodiad Troi Teigrod Mwythus Ben I Waered
Newsgroups: comp.sys.acorn
From: sdaveyj@cc.curtin.edu.au
Subject: Re: Hard Drive incompatibility under RISCOS 3.1, help!
Organization: Curtin University of Technology
Date: Wed, 7 Oct 1992 02:32:09 GMT

In article <ssumille.718300080@reading>, ssumille@csug3.cs.reading.ac.uk (Pete Millerchip) writes:
> Can anyone out there help?
> I just upgraded my A3000 to RISC-OS 3.1 and my Morley Electronics ST506 hard
> drive podule now refuses to talk to the drive - I get a "Disk not understood,
> are you sure it's formatted?" error even after I format it with !HForm.

Oh Dear, I have an A3000 with Morley st506 and I have RISC OS3.1 on order
if anyone knows anything about it please mail me too, at the moment I can 
receive but I cant mail back only to news groups.

 This incompatibility is very worrying...

		John Davey. (Curtin Uni Australia)
Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
From: Gavin.Flower@comp.vuw.ac.nz (Gavin Flower)
Date: Fri, 2 Oct 1992 23:38:54 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.

In article <1992Oct2.202141.19444@cs.utwente.nl> kortink@cs.utwente.nl
(John Kortink) writes:
[...]
>Whoopee. Read what you say. Five patronizing remarks in a row ? Sorry, but
>this is really childish. Just because I often like to go into heavy attack
>does not mean I should be 'violated' personally by you or TMOTA (or let it
>pass for that matter). Can we now resume listening to each other (and
>assume the other person does too) ? Thanks.
>
>Regarding your own statements, there already were other people than me who
>do not agree with you. Will you keep that in mind before you start thinking
>it's only me ?

The difference, is that the other people made points in a manner that was
reasonably well thought out, and free from personal attacks.  Mostly,
they appeared to have read carefully what had already been said.
Maybe you should contrast your approach with theirs.

[...]
>That aside, which neither side can ever 'win', I really fail to see why it
>cannot be fully acknowledged that major applications can be very succesfully
>written in ARM code and can survive all your doom and darkness predictions
>on updates and bugs.

Again *please* read carfully what I, and others said.  Also in the
implied time scale we are talking about, it is too soon claim major
software in assembler can survive as well as you claim - history is
against it.  Computers have been around for well over 30 years.

I've already acknowledged several times there is a place for ARM code,
and I've neither confirmed, nor denied, that CC do briliant things in
ARM code in their major products!  *Please* read what people write
carefully! 

[John, if that sounds patronising tough!  You still need to heed it!]

[...]

[Yeah, and *I* should learn not to be provoked...]


Gavin
-- 
Tomorrow's Society                              | flower_g@kosmos.wcc.govt.nz
    Depends on                                   ----------------------------
Today's Children  - help us raise them properly! 
*******  These comments have no known correlation with dept. policy!  *******
From: andyf@yama.uk.sun.com (Andrew Fox - Sun UK - Answer centre)
Newsgroups: comp.sys.acorn
Subject: Re: That alleged bug with RO 3.10
Date: 6 Oct 92 03:58:21 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: andyf@yama.uk.sun.com
NNTP-Posting-Host: yama.uk.sun.com

I also have tried it on my A5000, and it does the same thing...........

You click over the Name: label in the task manager info window and you get an 
internal error followed by the task manager vanishing from the icon bar.

Having said that, I can't possibly imagine any use for clicking the menu button over
previously mentioned place, other than to see what happens...........

As far as it being a bug is concerned, it hardly affects the functionality of the 
OS, so who cares........

Cheers for now,

Andy.

+-----------------------------+------------------------------------------------+
| Andrew Fox,                 |      'Life, don't talk to me about life.'      |
| Product Support Engineer,   +------------------------------------------------+
| Sun Microsystems Inc.,      |  					       |
| Citygate, Sale,             | Disclaimer: These opinions are mine, assuming  |
| Cheshire, M33 1JF,          |             I can remember what I've said.     |
| ENGLAND. +44 (0)61-905-4589 |                                                |
+-----------------------------+------------------------------------------------+
Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
From: Gavin.Flower@comp.vuw.ac.nz (Gavin Flower)
Date: Thu, 1 Oct 1992 13:15:51 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.

In article <1992Oct1.103327.26336@cs.utwente.nl> kortink@cs.utwente.nl (John Kortink) writes:
[...]
>God no, not *again* ! If anything the ARM code program could cope
>*much* easier with this change because it is written in the same
>language and the source can be updated in no-time. 

ARM assembly is the best assembler I've seen, and the most pleasurable
to use, of the 4 I've actually coded in.  However, methinks that you
are over stating the speed of change by a trifle.


>For a C source,
>an entirely new C compiler would have to be written. 

The compiler would need modification, rather than an entirely new one
produced.  I thought this would have been obvious!  Do you *really*
need a lesson in elementary compiler design?


>Guess which
>takes longer ? And take another guess at which will be faster and
>more memory-efficient ?

Assembler is obviously slower!  It faster to go from a concept
to a fully funtional major product in "C".  Run time speed isn't
always crucial.  Where runtime speed is crucial, there is good reason
to write selected parts in assembler.

Granted that assembler takes up less space, but this is not relevant
to the comments made.



[...]
>In the meantime, Gavin, Impression and ArtWorks are/will be probably
>the best and most widely used applications on the Archimedes. 

It was never stated that "C", should, or would, always be used for
major applications!


>How much
>does it take to cure C-blindness ?

What blindness?  Who's blindness?  I've also written programs in
various other high and low level languages.


Gavin
-- 
Tomorrow's Society                              | flower_g@kosmos.wcc.govt.nz
    Depends on                                   ----------------------------
Today's Children  - help us raise them properly! 
*******  These comments have no known correlation with dept. policy!  *******
Xref: sparky comp.sys.acorn:8827 comp.sys.acorn.tech:212
From: mcg@waikato.ac.nz
Newsgroups: comp.sys.acorn,comp.sys.acorn.tech
Subject: Re: PostScript printing (was Re: RiscOS 3.1, Risc Development IDEFS)
Date: 29 Sep 92 22:00:39 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <19013@acorn.co.uk>, pcolmer@acorn.co.uk (Philip Colmer) writes:
> In article <1992Sep29.115639.11080@waikato.ac.nz> bwc@waikato.ac.nz (Ug!) writes:
> 

> If the application *doesn't* know how to tell the printer driver what
> fonts are being used, ie *no* calls whatsoever are made to the new SWI
> (see below) after the initial call to PDriver_SelectJob but before any
> calls to PDriver_GiveRectangle, then the printer driver includes in
> the PostScript a definition of EVERY RISC OS font you have on your
> machine that does not have a PostScript equivalent defined.
> 
> So, the upshot of all of this is to badger the publishers of the
> application you are using into supporting this new SWI so that your
> printing works properly.
> 
> --Fil.
> 
> The new SWI that applications need to call is PDriver_DeclareFont
> (&80157):
> 
> Entry:          R0 = pointer to font name as passed to Font_FindFont in R1, or
>                 R0 = 0 to declare that no fonts will be used.
> 
> Good exit:      All registers preserved, NZC preserved, V clear.
> 
> Error exit:     V set, R0 points to error block.
>                 All other registers preserved, NZC preserved.
> 
> This SWI should be called after the initial PDriver_SelectJob to
> create the print job, but before any calls to PDriver_GiveRectangle
> have been made. It should be called once for each distinct font name
> and encoding to be used, but not for each font size (or colour, etc.).
> If a "SWI not known" error is returned (error number &1E7), then the
> printer driver is an old one that does not support this SWI. This
> specific error should be checked for, ignored, and printing should
> continue. Note that due to a bug, some of the old printer drivers
> return error number &1E6 (BadTime) instead of &1E7. Therefore the
> application will need to check for &1E6 and &1E7 when trying to call
> SWI PDriver_DeclareFont.
> 

While we're on this subject, could the dude who created !Draw_Plus, do a 
revised version compatable with Junior vs 1.17?

The problem is that the document fonts aren't declared properly (if you 
import a Draw_plus file into Junior 1.17); viz the *whole* font directory is 
dumped *UNLESS* one imports !Draw_plus file through to !Draw and then into 
!Junior. 

Thanks in advance....
From Martin Glanvill		(mcg@waikato.ac.nz)

Dept. Maths 							      @@@@@/|@
University of Waikato						      @@@@/ |@
Hamilton							      @@@/__|@
New Zealand							      @@/   |@
								      @@@@@@@@

----------------****=====| A quote to make your day |======****-----------------
If you explain so clearly that nobody can misunderstand, somebody will.
-------------------------------------------------------------------------------
Newsgroups: comp.sys.acorn
From: zrzm0111@helpdesk.rus.uni-stuttgart.de (MUFTI)
Subject: Re: Oh no ! More .....
Organization: User Help Desk, Comp.Center (RUS), U of Stuttgart, FRG
Date: Mon, 5 Oct 1992 09:19:18 GMT

In article <BvIIAt.B3G@comp.vuw.ac.nz> Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes:

>For super large projects, consider ADA, but the Archimedes range,
>currently isn't bigger enough to get into this territory.  Also there
>isn't even a hint of an ADA compiler for the Arc.

There is a hint 8-), but not a port 8-( ...
On Unix-workstations and MSDOS-PC's there is a usful translator/executor
for ADA named ADAED. It is currently not validated (but was valitated 
earlier). It is written in C and could maybe compiled on the Acorn 
Archimedes (if someone can compile the 20MB source code ...).
The other question is how much RAM memory it would require .... 

so long
MUFTI
From: r_voisey@csd.brispoly.ac.uk (R Voisey)
Newsgroups: comp.sys.acorn
Subject: Re: Riscos 3 for sale (?)y
Date: 2 Oct 92 17:40:28 GMT
Organization: Bristol Polytechnic, England

In article <1992Oct1.192337.11167@waikato.ac.nz> mcg@waikato.ac.nz writes:
>I'd be interested in knocking up a PCB (so long as the layout is single sided 
>and is either free or at modest cost ; i.e. below 5 quid).

It would probably fit on single sided PCB, but we used double sided.  The layout
it probably too fine for home etching in any case.

>It shouldn't be too hard to design a PCB, given the appropriate Pin outputs and 
>hardware details from Acorn....the problem is trying to weasel this information 
>out of them!  

You don't need any information from Acorn - not even they have had the
cheek to use non-standard EPROM pinouts!  Basically, for those who
don't already know, the only lines that have to be switched between
the two sets of EPROMS are the ~Chip_Select lines.  Make sure you
tie the lines on the switched out set high, though!  They cannot
be guaranteed to float high by themselves.

Cheers

Bob
-- 
  Robert J. Voisey  :  r_voisey@csd.brispoly.ac.uk
         -- Probug Software Developments --
162 Staplehill Rd, Fishponds, Bristol, Avon, England
From: gilbertd@p4.cs.man.ac.uk (David Alan Gilbert)
Newsgroups: comp.sys.acorn
Subject: Using ARM code and portability to 32bit ARM'S
Date: 6 Oct 92 07:43:03 GMT

OK theres been a lot of stuff chucked about concerning
doom for assembler code if a 32 bit address bus ARM comes
out into the Acorn world 
Has the world forgotten about MACRO's????

Surely its possible to put the problematic stuff into 
MACRO's.  Anyway I dont suppose that is too bad an idea for
some of the problem areas (e.g. flag setting, returns
from routines etc.).

Dave

-- 
-------------------------------------------------------------------------------
- David Alan Gilbert - gilbertd@p4.cs.man.ac.uk - G7FHJ@GB7NWP                -
------(Programmers don't sleep - they just park their heads)-------------------