HDTenEightyP/NetNews huggingface dataset:
From: amuser@cs.curtin.edu.au (Bill Sharp-Smith)
Subject: Re: Cando Applications
Organization: Curtin University of Technology
Date: Tue, 6 Oct 1992 04:55:30 GMT

carl@lochness.DAB.GE.COM (Carl Wilson) writes:

>Hi,
>    I am aware that there are a lot of cando applications that
>are available through the company's bulletin board but are there
>any ftp sites for these applications?

Not as far as I know, but you can get the contents of the BBS on disk
from Innovatronics (at least the Australian distributor can supply
them).

Let me know if you can get them by FTP, as I am using CanDo quite a
bit.

>					Thanks
>					Carl

Gary McGhee
-- 
 ________________________________________________________________________
/[  /~7 / / /~~ /  / /~7 | Email: amuser@marsh.cs.curtin.edu.au          ]
 [ / 7 /_/ /_7 //l/ / 7  | By post: PO Box 595, Cloverdale,W. Aust 6105  ]
 [ Amiga Users Group of  |                                               ]
 [ Western Australia Inc | Opinions expressed are my own etc...          ]
 [_______________________________________________________________________]
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: It works under CPR, but not without it!
Originator: walker@twix.unx.sas.com
Date: Thu, 1 Oct 1992 13:34:15 GMT
Organization: SAS Institute Inc.


In article <1adjhbINN54n@gap.caltech.edu>, rknop@cco.caltech.edu (Robert Andrew Knop) writes:
|> So, I have this program.  If I compile all of the source modules with -d5 (for
|> C) or -d (for the one assembly module), and then link it, it works just fine.
|> If I compile them without the debugger, it behaves screwily.  No guru, but the
|> program does not run correctly.
|> 
|> What could be causing this?  Clearly I can't use the debugger to track down
|> this problem... any suggestions as to where I should be looking for trouble?
|> 
|> This is frusturating.
|> 
|> -Rob
|> rknop@cco.caltech.ledu

What is probably happening is that you have a memory trash, and
compiling with the debugging option is moving your code around
enough to make the trash happen somewhere innocuous.

One thing to try is a lower debug level.  Levels -d2 and -d4 will not 
affect the generated code; that's the first thing to try.  You have to
be careful about trusting the values of variables in the debugger
with these levels, however, because the compiler may have decided to
defer flushing the value to the memory location associated with the
variable, and hence CPR will report inaccurate values.  Use the
mixed mode to make sure that things are where you think they are.

If -d2 doesn't do it, try compiling most of your program with -d1
and the modules you think are more likely to be a problem with a 
higher debug level.

If you haven't tried MemLib to track down memory errors, you might
want to try that.  If this problem is due to trashing of memory 
allocated with malloc or AllocMem, which it might be, MemLib will
detect that for you.

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.

Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: pooler@aix02.ecs.rpi.edu (Robert Peter Poole)
Subject: Re: FP oddities...
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Tue, 6 Oct 1992 01:24:53 GMT


When compiling code that uses the 68881/68882 FPU, you should take care to
#include <m68881.h> in your source files.  The reason for this apparently
has to do with defining the floating point instructions in terms of their
68881/2 specific stubs.  I recall this was important under 5.10b, and I noticed
that when recompiling a ray tracer, the #include <m68881.h> actually generated
smaller code that ran faster.  I'm not sure if this matters as much for
SAS/C 6.0, but just to be sure you are getting the correct code generation,
you should #include it.

Rob Poole
pooler@rpi.edu
pooler@cs.rpi.edu
Newsgroups: comp.sys.amiga.programmer
From: epang@fraser.sfu.ca (Eugene Pang)
Subject: Re: Aztec C compiler problems
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Tue, 29 Sep 1992 19:21:52 GMT

ludde@nada.kth.se (Erik Lundevall) writes:

>Yes, sqrt() is buggy, as you've noticed. There was a bugfixed sqrt() posted
>here a while ago, if I remember correctly.

I believe it was Paul Kienitz who posted the fix.  Unfortunately, I seem to
recall he had problems posting the uuencoded file.  Sufficeth to say...there is
a fix...somewhere.
From: jgh1+@pitt.edu (John G Hardie)
Newsgroups: comp.sys.amiga.programmer
Subject: Shells under GNUEmacs 18.58, version 1.26
Date: 4 Oct 92 19:00:27 GMT
Organization: University of Pittsburgh
Originator: jgh1@unixd3.cis.pitt.edu


Hi.

I just installed the upgrade to Emacs 1.26 for amiga.  This version
is supposed to have full support for processes.

Well, that may be so, but I can't make it work.  If I attempt to
do shell-command, shell, compile, or any other process related command
I get the message
'attempting vfork - not enough memory'  (or something like it - I dont
remember the exact wording)

Hmmph!  I've got a 6Meg A3000, with nothing but emacs running.  Avail says
that I have almost 4 M of ram free (about 1.4 of chip, the rest fast).
Furthermore, if I send the command to AREXX from emacs, it runs just
fine.

Does anyone know what's going on?

Regards,
John

-- 
jgh1@vm1.cis.pitt.edu

	Give me chastity and continency, but do not give them yet.
Xref: sparky comp.sys.amiga.programmer:13819 comp.sys.amiga.misc:14492
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
Subject: Re: :-( Contest - win your own A4000 :-(
From: cree@elec.canterbury.ac.nz (Michael Cree)
Date: Tue, 29 Sep 1992 00:16:22 GMT
Organization: Electrical Engineering, University of Canterbury, New Zealand
X-Newsreader: TIN [version 1.1 PL6]

L Lundman (lundman@kauri.vuw.ac.nz) wrote:
: In article <1992Sep28.140559.23389@usage.csd.unsw.OZ.AU> peteru@hydra.maths.unsw.EDU.AU () writes:
: 
: Actually it's not only Australia, the same happens here. I sent a letter
: to Commodore NZ 8 months ago and I still haven't received a reply. Perhaps
: this is normal for a big company? Sheesh...

So, I'm not the only one to experience that. I've long ago given up hope of
getting technical information from Commodore NZ. So I emailed CATS in USA
and got a response by the next day - I couldn't believe it!!! The North
Americans have it sooooooo lucky.

: Jorgen Lundman         eMail: lundman@kauri.vuw.ac.nz, lundman@rata.vuw.ac.nz

-----------------------------------------------------------------------------
Michael Cree                              Gold there is
cree@elec.canterbury.ac.nz                 and rubies in abundance;
                                          But lips that speak knowledge
                                           are a rare jewel. (Prov 20:15)
------------------------------------------------------------------------------
Newsgroups: comp.sys.amiga.programmer
From: jamie@cdevil.unx.sas.com (James Cooper)
Subject: Re: "Converting" to SAS/C 6.0
Originator: jamie@cdevil.unx.sas.com
Date: Tue, 6 Oct 1992 16:18:00 GMT
Organization: SAS Institute Inc.


In article <8493@orbit.cts.com>, chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes:
>
>I keep hearing people mention that they have to "convert" their code to be
>compatible with SAS/C 6.0.  What are the reasons for these conversions?  Is it
>merely ANSI compliance?  or have keywords changed?  or is the functionality
>different?  How much work is involved for various things?

ANSI compliance (adding extra underscores in front of some variables).
Also, there were changes to most of the compiler executables, so most
makefiles will need to be changed.  We have a script we're trying out
that does most of the "grunt" work for you on the makefiles, though.

That is, if you are moving up from a previous version of Lattice/SAS.
If you are moving over from DICE or Aztec C (or any other), there will
be keyword changes, etc.

-- 
---------------
Jim Cooper
(jamie@unx.sas.com)                             bix: jcooper

Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
and not necessarily those of my employer.
From: BGT101@psuvm.psu.edu (Blaise Tarr)
Newsgroups: comp.sys.amiga.programmer
Subject: gcc2hunk - gcc with ALINK?
Date: 3 Oct 92 18:15:20 GMT
Article-I.D.: psuvm.92277.141520BGT101
Organization: Penn State University

Is it possible to convert gcc's object files into standard Amiga object
files in hunk form?  I would like to call functions written in gcc from
an assemly language program.

Thanks for any help.

       ///  Blaise Tarr
      ///
  \\\///    BGT101@psuvm.psu.edu     "Typically, the subject being copied
   \XX/     tarr@cs.psu.edu           is terminated."   -CSM 101
Newsgroups: comp.sys.amiga.programmer
From: jamie@cdevil.unx.sas.com (James Cooper)
Subject: Re: Help with Asmembly code needed.
Originator: jamie@cdevil.unx.sas.com
Date: Mon, 28 Sep 1992 14:21:25 GMT
Organization: SAS Institute Inc.


In article <paulk.1n2m@terapin.com>, paulk@terapin.com (Paul Kienitz) writes:
>> Ah!  An easy one... :-)
>>
>>         move.l  #SIGBREAKF_CTRL_C,d1    * mask for ^C signal
>>         moveq   #0,d0                   * what to set it to after check
>>         jsr     _LVOSetSignal(a6)       * a6 == ExecBase
>>         tst.l   d0                      * was it set?
>>         bne     Break                   * yes, go handle it!
>
>BLAAAT
>
>SetSignal returns the state of ALL signals, not just the one you set
>in the mask argument.  So you have to test just that one bit in the
>return value, with something like btst.l #SIGBREAKB_CTRL_C,d0.

You're right... that's what I get for just typing something off the top
of my head, with just a quick look at the prototype to get the regs
correct.

Sorry to anyone who tried this and had it fail to work correctly... :-(

-- 
---------------
Jim Cooper
(jamie@unx.sas.com)                             bix: jcooper

Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
and not necessarily those of my employer.
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Cross-compiling with SPARC gcc 2.2.2 -> amiga
Date: 1 Oct 92 13:44:51 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH

In article <BvEus1.FFx@cs.columbia.edu> carson@cs.columbia.edu (Carson A. Gaspar) writes:
>
>I have the compiler producing 680x0 code, but need the amiga-modified
>version of as (I suspect - unless it uses m-generic.h), ld, ranlib,
>etc.  I have the executables for these things, but can't find source.

I uploaded gas and ld sources separately some time ago, I think the archive
was called gasldsrc.* ie you should search for 'gasld' with archie. If the
archive is no longer online on ftp sites, I'll reupload it.

-Markus


-- 
Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
From: efb@cnmss.tredydev.unisys.com (Edward Bacon)
Newsgroups: comp.sys.amiga.programmer
Subject: AmigaGuide and the AutoDocs?
Date: 29 Sep 92 20:45:11 GMT
Organization: Unisys Corporation, Tredyffrin



The SAS/C 6.0 just arrived and it's my first experience with 
amigaguide.  Will the autodocs be available as amigaguide
documents, is there a utility to convert the current autodocs?

Thank you to the SAS people for creating such a nice package.
Newsgroups: comp.sys.amiga.programmer
From: aces@mcode.amdahl.com (Jeffrey D. Smith)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Obj-C vs. C++ [was Re: Comeau C++]
Date: 5 Oct 92 14:02:00 GMT
Reply-To: jds30@amail.amdahl.com
Organization: Amdahl Corporation, Sunnyvale Ca.

In article <1992Oct1.200337.16085@beaver.cs.washington.edu>, wille@june.cs.washington.edu (Robert Wille) writes:
> In article <1992Oct1.163330.29774@oracle.us.oracle.com>, dnavas@oracle.uucp (David Navas) writes:
> |> In article <1992Sep30.201018.28069@beaver.cs.washington.edu> wille@june.cs.washington.edu (Robert Wille) writes:
> |> >In article <1992Sep30.164448.113@oracle.us.oracle.com>, dnavas@oracle.uucp (David Navas) writes:
[lots of fun stuff deleted, because you've already seen it]
> 
> Just overload operator new and operator delete.
> 
> class D {
> // Usual stuff
> 
>    static void * operator new (size_t size) { return MyMemoryAllocator(size); }
>    static void operator delete (void* ptr) { MyMemoryFreer(ptr); }
> };
> 
> D and everything derived from D will now use MyMemoryAlloctor and MyMemoryFreer
> to allocate/free memory for the class.
> 
> Note that if you want to use AllocMem, when operator delete is called, you
> will have no idea how big the piece of memory is that you want to free.  You
> cannot assume it will be sizeof(D).  You could do the following for a ChipMem
> allocator:
> 
> void* MyMemoryAllocator(size_t size)
> {
>    size += sizeof(size_t);
>    size_t *ptr = (size_t*) AllocMem(size, MEMF_CHIP);
>    *ptr = size;
>    return (void*) (ptr + 1);
> }
> 
> void MyMemoryFreer(void *ptr)
> {
>    ((size_t*)ptr)--;
>    FreeMem(ptr, *ptr);
> }
> 
> Hope this helps.
This is great.

Please remember that this will work correctly on the
Amiga (most of the time), but it is not generally portable to
any other CPU architecture.  Changing 'AllocMem' to 'malloc'
and 'FreeMem' to 'free' won't fix it.  The problem is alignment
of the data area. The system allocation routine returns a pointer
that is aligned on the strictest boundary for the current CPU.
By futzing the pointer, the result is at best aligned to a
(size_t*) boundary.  If the data area requires 8-byte alignment,
then you may be adjusting the pointer into the middle of an
8-byte chunk and blow away the CPU when it references, say, a
double floating point value.

By the way, the MC68000 CPU currently has 2-byte alignment
as the strictest requirement.  (You get better performance for
longs on a 4-byte boundary for the advanced MC680x0 CPUs.)
Newsgroups: comp.sys.amiga.programmer
From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re: Multithreaded code using CreateTask()
Organization: UNC Office of Information Technology
Date: Wed, 30 Sep 1992 17:13:27 GMT

In article <35483@cbmvax.commodore.com> dlarson@cbmvax.commodore.com (Dale  
Larson - Product Assurance) writes:
>In article <1992Sep30.131753@uni-paderborn.de> aurel@uni-paderborn.de (Aurel  
Balmosan) writes:
>>I think [...] you can use any library bases which was opened in the main  
>>process, because the library base pointer is always the same[...].

>Wrong.  Some libraries return different library bases to each opener.  To my
>knowledge, no library other than Exec has guaranteed that it will always
>return the same library base to each opener, though this is (and probably will
>continue to be) the usual behavior for many libraries.  Be safe and re-open
>any libraries needed by the child task or process.

This poses some interesting problems.  Typically the Task's library base  
pointers are shared with the parent Process.  What clean mechanism can you
suggest for keeping multiple sets of these library base values in one set
of base pointers?  I've really gotten into multithreaded code in a big way
lately, and doing what you suggest would put a big kink in some of my
current projects.

Any libraries which return different bases for different openers or
which require a specific open by each calling task even if the same
base value is returned should be documented pretty blatantly.  The
description of how libraries work in the RKMs didn't make a big point
about this.  Changing any existing library to require more stringent
opening conventions is bound to break lots of programs that were
written "by the book."  Following this new guideline would make
CreateTask() almost useless for any significant subtasks given the
way most compilers handle A6 for library calls. 
--
Todd M. Lewis / Todd_Lewis@unc.edu / utoddl@guitar.oit.unc.edu
       An acorn's destiny is not to become an oak tree.
         An acorn's destiny is to become a squirrel.
Newsgroups: comp.sys.amiga.programmer
From: siera@imada.ou.dk (Soeren Berg Hansen)
Subject: Re: If you use locale.library, read this
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Mon, 5 Oct 1992 13:36:23 GMT

In article <30878@sophia.inria.fr> beust@modja.inria.fr (Cedric Beust) writes:
>
>	Well, first I wanted to say the locale.library is a great thing!
>	It seems so odd to hard-code text in applications, now!
>
>	Anyway, the problem is : find translators for your wonderful
>	programs. Not so easy. I just wanted to tell anyone who is
>	looking for a translator that I'm willing to do this in French.
>	So if you finished your program but need to add a few languages,
>	drop me a mail. Of course, no money wanted!!! Just for fun!
>
>	Why am I doing this? Just because I'm also developing an
>	application with the locale.library and I wish I had read
>	this kind of proposition...
>
>	Let me know if you need help!
>
>
>--
>Cedric BEUST, beust@sa.inria.fr, Bull Research Koala proj, KoalaBus & xforum
>Pho:(33) 93.65.78.07(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.
     And I'm willing to translate to danish, if anyone's interested (from
     english ofcourse). No money asked. By the way, don't know how to implement 
     the locale files, so I'll just do plain ascii files.

Soeren

siera@imada.ou.dk
From: doiron@starpt.UUCP (Glenn Doiron)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Cun I yoos da Debugger wid Assembly?
Date: 29 Sep 92 22:08:47 GMT
Organization: 68K Software Development
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith

In article <1992Sep26.231142.20133@cs.uow.edu.au> u9155406@cs.uow.edu.au (Gerardo Bentancor) writes:
> *Stupid Question/s Alert*
> 
> Hey Guys,
[zap]
> 	Oh Yeah, and before I forget, (be prepared this is a really dumb
> question). How on earth is my assembler supposed to work when I have the
> following lines in the include files: e.g.
> 
> 	dos/dos.i has the following lines:
> 
> STRUCTURE DateStamp,0
> 	LONG  ds_Days			; Number of days since Jan. 1, 1978
> 	LONG  ds_Minute			; Number of minutes past midnight
> 	LONG  ds_Tick			; Number of ticks past minute
> 	LABEL ds_SIZEOF			; DateStamp
> 
> Now how can this assemble? It looks Cish to me, and of course, asm spews
> when it gets to these lines...

 include "exec/types.i"

Glenn Doiron
--
Amiga UUCP+
Origin:  uunet!starpt!doiron     (Organization:68K Software Development)
         BIX: gdoiron
** Not enough memory to perform requested operation.  Add 4 megs and retry.
Newsgroups: comp.sys.amiga.programmer
From: markus@techfak.uni-bielefeld.de (Markus Illenseer)
Subject: Re: HDMem vs GigaMem for virtual memory on Amigas?
Date: Tue, 6 Oct 92 21:55:27 GMT
Organization: Universitaet Bielefeld, Technische Fakultaet.

In article <amuser.718347646@marsh>, amuser@cs.curtin.edu.au (Bill Sharp-Smith) writes:
|> chanson@nyx.cs.du.edu (Chris Hanson) writes:
|> 
|> >markus@techfak.uni-bielefeld.de (Markus Illenseer) writes:
|> 
|> >  Also, even if it were 68040 compatible, it would not work on the A4000,
|> >as the A4000 uses the 68EC040 chip, the big brother of the 68EC030. The
|>                        ^^^^^^^^^^^ 
|> This has been refuted several times by CBM staff. The A4000 has a full
|> '040.
|> -- 
|>  ________________________________________________________________________
|> /[  /~7 / / /~~ /  / /~7 | Email: amuser@marsh.cs.curtin.edu.au          ]
[...]

 Please learn to quote right, i NEVER said the above. I know that the
 A4000 has a full featured 68040.


-- 
Markus Illenseer       EMail: markus@TechFak.Uni-Bielefeld.de
Universitaet Bielefeld Fax: (+49 521) 106-2992
Technische Fakultaet   Phone: (+49 521) 106-2938 ; (2935 Sek.)
Angewandte Informatik  SnailMail: Postfach 100131, D-4800 BIELEFELD 1
From: heinz@edohwg.adsp.sub.org (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: FWrite() <-> Write()
Date: 29 Sep 92 20:11:07 GMT
Organization: Edotronik GmbH

In article <Boris_Folgmann.0ipk@ibase.stgt.sub.org> Boris_Folgmann@ibase.stgt.sub.org (Boris Folgmann) writes:
>What's better when using FWrite() instead of Write() under OS2/DOS V37???

Your write is buffered. So for text it is usually a lot more efficient as
the system doesn't need to Write() in small chunks immediately all the
time.

>| Boris Folgmann  | UUCP:  Boris_Folgmann@ibase.stgt.sub.org

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: SAS/6.0 Compiling from Editor
Originator: walker@twix.unx.sas.com
Date: Thu, 1 Oct 1992 14:40:49 GMT
Organization: SAS Institute Inc.


In article <QemX4pW00iUzA0fK0R@andrew.cmu.edu>, ef23+@andrew.cmu.edu (Eugene M. Feinberg) writes:
|> 
|> I installed v6.0 of the SAS compiler.  However, when I try to compile
|> from the editor by hitting F4, a get a window that says "Compiling" 
|> and which goes away quickly with no noticable affect.
|> 
|> Thanks in advance.
|> 
|> Gene Feinberg

Ah, we have just discovered something.  If you use WShell as your
default user shell under 2.0, compiling from within SE does not work.

No idea why at this point.  You can easily write a rexx script to
save the current session and submit a compile with the ERRORREXX
option active, however.

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.

Newsgroups: comp.sys.amiga.programmer
From: wille@june.cs.washington.edu (Robert Wille)
Subject: Re: Obj-C vs. C++ [was Re: Comeau C++]
Organization: University of Washington Computer Science
Date: Wed, 30 Sep 92 20:10:18 GMT

In article <1992Sep30.164448.113@oracle.us.oracle.com>, dnavas@oracle.uucp (David Navas) writes:
|> In article <jac.717747506@moonshine> jac@moonshine.llnl.gov (James A. Crotinger) writes:
|> >dnavas@oracle.uucp (David Navas) writes:
|> >> C++, it seems to me, was designed to provide an object-oriented >interface<
|> >> to C, where Obj-C was designed as an object-oriented language with similar
|> >> syntax as C.
|> >  I guess this is a matter of opinion. Obj-C always looked like someone
|> >tried to graft small-talk on top of C. C++ seems more C-like, and if you
|> >like C syntax (I do), it seems more elegant.
|> 
|> >Suppose class D inherits from B, which declares a "virtual function" 
|> >named "foo". Class D can provide its own definition of "foo". Now,
|> 
|> And to call D's superclass' definition of foo we'd just type-cast right?
|> So what happens if D shifts within the hierarchy?

No.  Type-casting doesn't change which virtual function gets called.

[stuff deleted]

|> How difficult is it to have C++ create objects in, say, CHIP_MEM?  Or
|> allocate objects from a private memory pool?

Very easy.  At work we have a whole bunch of C++ classes.  The memory
for the objects is allocated out of privately managed memory.  We do garbage
collection in the background and will even move objects if they aren't
currently in use (i.e. all the objects in our container classes float around
in memory except for when you're accessing them.

[more stuff deleted]

|> I think my claim is that it's not always the best tool for the job --
|> which ought to have been self-evident (~truism).  Not that anything was
|> "impossible", which is an invalid argument for any "Turing-complete"
|> language (assuming it's possible in the first place ;)).

But then again, no language is the best tool for the job.

-- 
Robert

There is evidence that the brain is like a computer.  If that's true, 
then there really aren't any stupid people.  Just people running DOS.
Newsgroups: comp.sys.amiga.programmer