HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: Preferential Treatment for Education...???
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Thu, 13 Aug 1992 02:15:06 GMT
Organization: Computer Science Dept. University of Auckland

smb@cs.nott.ac.uk (Simon Burrows) writes:

>I was not saying that Acorn should not release new machines, just that they
>should not actively encourage educational buyers to purchase remaining
>stocks of a machine about to be discontinued.

How the hell do you expect them to sell their computers without "actively
encouraging" buyers? I think that this is what they should try harder to do,
not less hard.

>It looks likely that the new machine will cost no more than the A3000, in
>fact I think less.

Yes. And in 6 months time it will probably drop in price, and everyone
who bought one the week before will be pissed off at "losing" 100 units of
monetary value by buying a week "early".

>If that doesn't mean it is discontinued, what does?

I would say a press release from Acorn saying "We have discontinued production
of the A3000" would be the only sure fire way of knowing.

Sure, it's nasty and horrible that Acorn have to try to sell off their last
A3000 stocks with a special deal before the new better faster cheaper
machine appears, but this is NORMAL in any industry with any amount of
technological improvement. At some point, the old becomes outdated, and the
new becomes cheaper than the old. Acorn is a BUSINESS, and have to keep
making a profit if they can.

Also, if people are stupid enough to say "OOOH Look! Acorn is dangling a
carrot in front of me" and then buy the machine, then you can't blame it
ALL on Acorn. You have to expect that Acorn are always within a year of a new
release, and you could keep waiting for the next machine... and the next one...
but at some point you will have to take the plunge and buy.

I chose not to buy the A5000 a year ago, because it seemed to have been
prematurely released (hardware slightly shaky, RISC OS buggy as hell), so
I thought I'd wait until "Early 1992" until RISC OS 3.1 was released and
see... Now, I'm waiting until September or October to see if there is
going to be a machine I would prefer to the A5000 (I like the A4, except that
in NZ the price difference between it and the 5000 is large, and the LCD
display has very very nasty ghosting problems, so I'll probably get a 5000..

However, in a couple of months I *will* buy a machine, and I will probably
end up less than 6 months later, regretting that I won't be able to get
the new 60Mip 24-bit 32MB $500 machine... But I'll buy because I need a
machine *now*, and the one I am buying now is good enough to make me happy
now. In 6 months it will only be worth half what I paid for it, but that's
life, and has nothing to do with Acorn policy.
-- 
_________________  "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: r_voisey@csd.brispoly.ac.uk (R Voisey)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: Floptical Drives
Date: 15 Aug 92 18:47:51 GMT
Organization: Bristol Polytechnic, England

In article <1992Aug14.151606.1976@cs.nott.ac.uk> smb@cs.nott.ac.uk (Simon Burrows) writes:

>suppliers. However is the product the same? Do the floptical drives use the
>standard SCSI hard disc drivers, supplied with every SCSI interface, or do
>they require special software? Which makes of SCSI interface work with
>floptical drives?

They work with standard cards AND they need special software.  This is because
the floptical has an unusual (probably unique) device lock/release protocol
which, although straight forward, has the unfortunate effect of screwing up
if used with a standard protocol driver.  Most new PC scsi cards have this
protocol in their BIOS, but none of the Archimedes cards have it (AFAIK).

I use a Morley interface with my floptical, but they work fine with most of
the cards on the market (I'm not sure about Oak..).

When comparing prices, please bear in mind that suppliers to the PC market
deal with thousands of units, where as the suppliers to the Archimedes
market deal with hundreds, or less.   You could buy a drive from a PC
supplier and try to persuade one of the developers to sell you their flopFS
modules, but I doubt whether they would do so..

Bob

All opinions are my own etc

-- 
Robert J. Voisey  :  r_voisey@csd.brispoly.ac.uk   (Janet)
GUI coders do it     Bob Voisey @ 2:252/106.0      (Fidonet)
on the desktop       Bob Voisey @ 100:104/106.0    (TurboNet)
Xref: sparky comp.sys.acorn.advocacy:59 comp.sys.acorn:8287
From: pdenize@waikato.ac.nz
Newsgroups: comp.sys.acorn.advocacy,comp.sys.acorn
Subject: Reporting problems to Acorn
Date: 20 Aug 92 11:10:39 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <1992Aug19.074939.2450@rdg.dec.com>, goodwin@edieng.enet.dec.com (Pete Goodwin) writes:
> 
> The moral is: complain to Acorn to get them fixed. Don't just give up on
> RISCOSlib otherwise it'll stay as it is.

I agree with Pete

One should complain

But Acorn has been PAID to perform a reasonable amount of testing and provide a
product of merchantable quality.  The software written often reflects the
quality of the compiler, its libraries and its documentation.  Acorn seems to
have wasted a great deal of time commenting on style rather that producing a
validation set of programs.

The reason I say wasted time is that it seems the style comments dont seem to
have been followed by their own software engineers.

Defn: A Hacker, one who knows the right way to do something and follows
      a different rule.

Paul Denize

--------------------------------------------------------------------------
Paul Denize                                Internet: PDenize@Waikato.ac.nz
Department of Computer Science
University of Waikato                         phone: ++64 7 8562-889
Hamilton                                                          Ext 8743
NEW ZEALAND                                   fax  : ++64 7 8560-135
--------------------------------------------------------------------------
From: r_voisey@csd.brispoly.ac.uk (R Voisey)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: RISC OS 3 Applications Discs
Date: 13 Aug 92 23:04:35 GMT
Organization: Bristol Polytechnic, England

In article <1992Aug12.182316.10022@cs.nott.ac.uk> psyhsmb@unicorn.nott.ac.uk (Simon Burrows) writes:
>I've just been looking at the RISC OS 3.10 Applications Discs, and was
>surprised to see that the main difference between these and those supplied
>with RISC OS 3.00 is that the BASIC !RunImage files have been run through
>a crunching program, making them almost totally incomprehensible.

 .. just as most of them were with RISCOS 2...  I don't know if they encrypted
them for the sake of space or to prevent people browsing them (I suspect
the former), but it surely makes next to no difference to 99% of users...

The BASIC applications disks programs were not exactly brilliant material
for people to use for learning WIMP coding..  in fact they were about as
terse as BASIC can get, with virtually no comments and lots of multiple
statements on single lines..

>how Acorn programs work? It seems to be setting a bad example to other users,
>who should be encouraged not to crunch their programs unless essential.

Why should people be encouraged not to crunch their programs???  Doing so
makes a significant improvement in the time taken to load an application
of any size..  and saves disk space to boot.

Anyway, 99% of crunched programs have been 'squeezed' - you can unsqueeze
them with xpand, though I suspect this might be a developer only program.
That shouldn't cause YOU any problems though..

Bob

-- 
Robert J. Voisey  :  r_voisey@csd.brispoly.ac.uk   (Janet)
GUI coders do it     Bob Voisey @ 2:252/106.0      (Fidonet)
on the desktop       Bob Voisey @ 100:104/106.0    (TurboNet)
From: r_voisey@csd.brispoly.ac.uk (R Voisey)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: RISC OS 3 Applications Discs
Date: 21 Aug 92 23:07:46 GMT
Organization: Bristol Polytechnic, England
X-Newsreader: Tin 1.1 PL5

Emmet Spier (maurp@warwick.ac.uk) wrote:
: 
: Err r Voisely says that Acorns BASIC app discs progs were terse & hard to
: learn from but nearly every PD programmer I know started off with !Madness or
: !Calc (me!) & then slowly re-coded it as you learnt what Acorn did wrong!

Hmm..  I started off with the PRM and a telephone.  After a couple of weeks
volume 3 of the PRM was tatty as hell, and my phone bill was astronomical -
but it basically worked...

I hate reading other peoples code, even if it's well written and commented..
that course can lead to REALLY inefficient programs if you don't take care.

(Hands up everybody who starts a new WIMP application by copying their old
one and deleting the bits which don't seem relevent..  I'm certainly guilty
of this, but it can lead to some pretty inefficient code after a 'shell' has
reached the third or fourth generation.

Bob

-- 
Robert J. Voisey  :  r_voisey@csd.brispoly.ac.uk   (Janet)
GUI coders do it     Bob Voisey @ 2:252/106.0      (Fidonet)
on the desktop       Bob Voisey @ 100:104/106.0    (TurboNet)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: Magazine Circulation Figures
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Thu, 13 Aug 1992 02:25:20 GMT
Organization: Computer Science Dept. University of Auckland

gtoal@gem.stack.urc.tue.nl (Graham Toal) writes:

>:I know that at least one of the magazines is experiencing financial 
>:difficulties, and at the same time none of them now publish their ABC

>if this is true, it could be taken as an early indicator of the general
>health of the acorn market.  time to sell those shares, guys.

I would say it's because as all Acorn Mags get prgressively more expensive
their information content declines at an alarming rate, while the bullshit
content ("Yes, if you poke a screwdriver into your power supply, it is
perfectly safe so long as you are eating an imperial mint" ;-) goes up
to a frightening "30% of help we give is WRONG", people start to think
"Bugger this for fun. I'll manage without them".

That's what I did - One day I realised that I have piles of hundreds of
completely worthless things that cost me about $10 each. Considering I only
earn about $100 a week (I'm a student ;-( this is quite a drain on my
finances...

-- 
_________________  "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)
Xref: sparky comp.sys.acorn.advocacy:57 comp.sys.acorn:8285
From: goodwin@edieng.enet.dec.com (Pete Goodwin)
Newsgroups: comp.sys.acorn.advocacy,comp.sys.acorn
Subject: Re: Validation of Acorns DesktopC includes
Date: 19 Aug 92 07:48:18 GMT
Organization: Digital Equipment Corporation


In article <1992Aug19.061705.24053@cs.aukuni.ac.nz>, jwil1@cs.aukuni.ac.nz (TMOTA) writes...

>The moral of the story: Don't use RISC OS Lib.

The moral is: complain to Acorn to get them fixed. Don't just give up on
RISCOSlib otherwise it'll stay as it is. Now if Acorn would like to fix the
faults I've logged so far...

Pete Goodwin
goodwin@system.enet.dec.com
From: imb@harvey (Ian Brown)
Newsgroups: comp.sys.acorn.tech
Subject: POSIX library - does one exist
Date: 14 Aug 92 07:03:38 GMT
X-Newsreader: Tin 1.1 PL3

Does anyone know if there is a POSIX conforming library about, or if anyones
working on one.

If not, I may contact the Unixlib author and get his permisiion to use
that as a basis for one...


	All the best
              Ian Malcolm Brown

Mail:         imb@oasis.icl.co.uk  OR  ...!uel!dsbc!imb
Phone:        +44 344 424842 x2310 (ITD 7263 2310)
Fax:          +44 344 487832
Organization: International Computers Limited
Address:      ICL, Lovelace Road, Bracknell, Berkshire, RG12 8SN, UK
From: gpvos@cs.vu.nl (Gerben 'P' Vos)
Newsgroups: comp.sys.acorn.tech
Subject: Re: New Language/Compiler (ideas wanted)
Keywords: Compiler/Language
Date: 14 Aug 92 09:33:02 GMT

Gavin Flower writes:

>A number of years ago, someone suggested a "comfrom", to match a
>"goto".  When it was first mentioned, it was as a joke.  However, the
>more I thought about it, the more it appealed...

The "come from" was intended to be used * without * a corresponding goto,
so it would actually be a construct which would encourage really horrible,
disgusting, unstructured, <insert rude word here> core (oops, i meant code,
but core is probably appropriate too :-) ).

It has been implemented in some languages as a debugging tool---not to be
used in real code. Also, it has been implemented in INTERCAL, a joke
language, which encourages programming worse than found in the Obfuscated
C Programming Contest.

>The idea is that both ends of the goto are labeled.  This has several
>advantages:-

>(1) At the target label, the "comefrom" clearly identifies the places
>from which the current label can be reached, and just how many places.

>(2) Also it will help to discourage indiscriminant use of the
>"dreaded goto", without preventing its use in "appropiate" contexts.

>(3) This would give the compiler more scope for picking up errors.

But the way you propose it, it sounds actually very nice.

. . . . . . . . . . . . . . . . . . . . . . . . . . . G e r b e n   V o s   <><
Aconet: 8500/104!Gerben Vos  Internet: gpvos@cs.vu.nl
This .signature is a Usenet Olympic Record holder. Copy it now!
From: osmith@acorn.co.uk (Owen Smith)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Modules
Date: 20 Aug 92 17:43:42 GMT
Organization: Acorn Computers Ltd, Cambridge, England

In article <1992Aug19.200810.1@vxdesy.desy.de> burke@vxdesy.desy.de writes:

>  The PRM seems a bit inconsistent on the subject of interrupts in SWIs.

Unfortunately the RISC OS 2 PRM is out of date - it describes what the
situation was under Arthur. In RISC OS 2 interrupts are usually enabled when
your SWI entry code in your module is called. In fact interrupts are in
whatever state they were in when the SWI was issued, which means they are
almost always enabled. This also means that enabling them if they were
disabled may be dangerous, since IRQs were disabled for a reason by the code
that called your SWI. This is fairly unusual though - how much code have you
written that calls SWIs with IRQs disabled?

>  Now to the thorny subject of errors.

I'm not going to answer what you asked, but make a different point instead.
Please remember that *ALL* SWIs are capable of returning V set R0 -> error,
so whenever you call *ANY* SWI (including OS_WriteC and the like) you should
check for a V set error return.

There are a variety of ways you can get an error from a SWI that you don't
expect. If it's not an OS SWI, just RMKill the module :-). OS SWIs may be
intercepted by some dodgy software, either through a vector or illegally by
patching the SWI table; alternatively you may be spooling or using the
printer drivers. A good case in point is Sound_InstallVoice (PRM page 1593).
This says "If an error occurs, this SWI does not set V in the usual manner.
Instead R1 is zero on exit, and R0 points directly to a null-terminated
string." While this is strictly true, it is misleading as it implies you
don't need to check for V set error return at all. This is false - if you
*RMKill the SoundChannels module you get V set R0 points to a SWI not known
error block. So you need to check V set first, and then check for the
unusual way this SWI returns errors.

Owen.

The views expressed are my own and are not necessarily those of Acorn.
From: mcg@waikato.ac.nz
Newsgroups: comp.sys.acorn.tech
Subject: Re: Modules
Date: 20 Aug 92 23:44:25 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <1992Aug19.200810.1@vxdesy.desy.de>, burke@vxdesy.desy.de writes:
> 
>   That's all I can think of for now. I wonder if the RISC OS3 PRMs are any
> better ...
> 

I've heard that the RO3 PRM's are just ammened RO2 manuals, to cater for the 
different usage of things (I don't know exactly what) under RO3 on the A5000.

Roumor/fact?!? can anyone verify this?
From Martin Glanvill		(mcg@waikato.ac.nz)

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

----------------****=====| A quote to make your day |======****-----------------
A consultant is an ordinary person a long way from home.
-------------------------------------------------------------------------------
From: bwc@waikato.ac.nz (Ug!)
Newsgroups: comp.sys.acorn.tech
Subject: Re: New Language/Compiler (ideas wanted)
Date: 17 Aug 92 13:29:29 +1200
Organization: Vooniersity fo Kaiwato

Halfdan Ingvarsson asks for ideas on new language features.

(deep breath)  Hokay, here we go:

Firstly, have a look at Oberon-2.  The descriptions are available by anonymous
ftp from ETH.  Some really neat ideas there.

1.  Generics.  Any new language worth its salt should consider this issue.  One
    of the reasons why Ada beats C++ for productivity is that generics beats
    object oriented for reuseability.  (the other reasons have to do with the
    great tools that come with Ada, and the strict licensing scheme which
    ensures compatability)

2.  Subranges.  At some stage I'd love to build a language which has *no*
    concept of fixed data-type sizes.  Of course, you could then have a
    library routine which defines a type Word (much like Modula-2's
    System.WORD) and Byte and so forth.  However, this is entirely a
    portability concept, and so is not really applicable to what you are trying
    to do, but even so, just think how nice it would be to be able to use
    320-bit integers...

3.  Overloading.  Ada has this, without being Object-oriented.  This coupled
    with generics gives you better reuseability than object instantiation.
    Both functional and operator please.  Don't worry about redefining
    operator precedence:  leave 'em as they are, and folks can work with that.

4.  One of the things I would like is a 'string' concept, which automatically
    handles groups (arrays) of items which grow and shrink - maybe a 'bag'.  In
    this way you could have a 'STRING OF CHARACTER' or a 'STRING OF INTEGER'.
    'STRING', like 'ARRAY' allocates space, but it can be resized etc
    dynamically.  Useful.

5.  Projection.  See previously mentioned Oberon-2.  This completely redefines
    the way inheritance and stuff works.  Keeps the language procedural rather
    than data-driven, which is nice for those of us who think in processes, not
    in data-flows.  Coupled with generics, should make life very interesting.
    Also, by combining with overloading gives similar capability to object-
    oriented, although dynamic binding might be tricky to fudge.

6.  Packages or Modules or *something*!  Preferably coping automatically with
    linking (C... yuck!).

7.  No limitations like 'strings can only be up to 255 in length'.  Yuck!

8.  There is no number 8.

9.  Can link up with C, including C I/O.

10. A good 'ABSTRACT' (or opaque) data type.  Modula-2 almost does it, but not
    quite, since it limits the size of its opaque types to the size of a
    pointer.  Ada goes one better, but then requires you to say what's actually
    in it, so what's the point?  Opaque data types enable data-hiding (great
    for abstraction purposes), and are all too often very useful.  In C, I
    kludge this by passing back a pointer to the type as a 'void *'.

Oh well, some food for thought.
								Ug!
From: robg@citr.uq.oz.au (Rob Geraghty)
Subject: null modem cables
Summary: how to wire it?
Keywords: RS232
Organization: Prentice Centre, University of Queensland
Date: Tue, 18 Aug 1992 07:33:03 GMT

Hi folks,
	 would someone out there be able to give me a wiring diagram for
a null modem connection for 25pin D RS232 to 9pin Arc RS232?  I'm told
it's not standard and I can't just buy a 25-9pin converter.

thanks
Rob

------------------------------------------------------------------------
Rob Geraghty                         | Time
robg@durian.citr.oz.au               | Flowing like a river
CITR                                 | Time
                                     | Beckoning me
                                     | (A.P.P.)
------------------------------------------------------------------------

--
------------------------------------------------------------------------
Rob Geraghty                         | Time
robg@durian.citr.oz.au               | Flowing like a river
CITR                                 | Time
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.sys.acorn.tech
Subject: Re: New Language/Compiler (ideas wanted)
Date: 17 Aug 92 11:58:38 GMT
Organization: Department of Computer Science, U of Copenhagen

kers@hplb.hpl.hp.com (Chris Dollin) writes:

>In article ... jwil1@cs.aukuni.ac.nz (TMOTA) writes:

>   torbenm@diku.dk (Torben AEgidius Mogensen) writes:

>   >Afeature I have sorely missed in compilers for C etc. is a cheap
>   >tail-call: if the last thing you do in a procedure or function is to
>   >call a procedure or function, this can be implemented as a goto rather
>   >than a general procedure/function call. Also, the local variables of

>   What do you mean? What if the tail-called function then tries to call
>   another function or (even worse) recurses? This could only work if
>   the tail-called function expected to recieve *exactly* the stack frame
>   that the tail-caller has had set up when it was called.

>Urk? You clean up the stack before you call the tail-called function, of
>course. It's a standard optimisation, at least in the Lisp world. [The only
>objection to it is that it can make debugging harder -- you lose the functions
>that tail-called when you get the stack backtrace.]

>   And remember that Acorn's C compiler (the ARM proc. call std.?) is clever
>   enough to notice when you call a function that does not call another (a
>   leaf function), and does not bother with most of the context-storing
>   operations involved in normal function calls.

>I'm not sure you said what you meant. There's no cleverness involved in calling
>a leaf function (after all, who's to know that it *is* a leaf function?), it's
>just that leaf functions don't need to carry all the baggage of a full function
>call -- it's the code of the leaf that ``does not bother with most of the
>context-storing operations''. [They don't carry the baggage because there's
>very little that can go wrong inside them, so they don't need to record who
>they are in case something does.]

This is basically the old caller-saves/callee-saves controversy:
caller-saves makes tail-call optimization easy, callee-saves makes
leaf-call optimizations easy.

The reason callee-saves is bad for tail calls, is that it can't see if
it is called from a tail position (unless a separate entry point or
parameter specifies this). The reason caller saves is bad for leaf
call optimization is that things are already saved, so you can't avoid
doing so.

Both of these problems can be partially solved by using a mixture of
caller saves and callee saves strategies.

	Torben Mogensen (torbenm@diku.dk)