HDTenEightyP/NetNews huggingface dataset:
From: alien@acheron.amigans.gen.nz (Ross Smith)
Newsgroups: comp.sys.amiga.programmer
Subject: Version strings
Date: 16 Oct 92 00:35:40 GMT+12
Distribution: world
Organization: Wanganui Amigans, Wanganui, NZ

Does anybody know how to put a 'version string' into a program (so that the
'version' command can find it)? I've got all three 2.0 RKMs but I can't find
any reference to the subject; the version.library isn't even mentioned. Is it
some kind of 'trade secret' that only Real Developers are allowed to know?

--
...... Ross Smith (Wanganui, NZ) ...... alien@acheron.amigans.gen.nz ......
                 "It's all absolutely devastatingly true,
              except the bits that are lies." (Douglas Adams)
From: koren@fc.hp.com (Steve Koren)
Newsgroups: comp.sys.amiga.programmer
Subject: more and System()
Date: 13 Oct 92 14:58:24 GMT
Article-I.D.: fc.Bw2ExC.BDA
Organization: Hewlett-Packard Fort Collins Site
X-Newsreader: Tin 1.1.3 PL5

I use the 2.04 System() call to execute programs.  Mostly this works
great.  I use a fairly generic set of tags: I set stack size, priority,
input, output, and a handful of others.  Certainly nothing esoteric.  It
seems to work for almost everything.

However, I have noticed one problem.  If I execute "more", and redirect
its stdin from a pipe, it complains as follows:

     Enter filename, or <Return> to exit:
     Can't open file

I can go into an AmigaDos CLI, and run "more <pipe:foo" and it works
fine.  Why doesn't it work when I set the SYS_Input tag for System?  I'm
sure this is happening right because everything else works that way and
gets its stdin set correctly.

Is there something special about "more" that I don't understand?  Or
perhaps some other tag which says "Hey, this is supposed to be run
interactively"?

  - steve
Newsgroups: comp.sys.amiga.programmer
From: comeau@csanta.attmail.com (Greg Comeau)
Subject: Re: C Compilers....
Originator: comeau@well.sf.ca.us
Keywords: C Compiler
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Date: Thu, 8 Oct 1992 03:30:42 GMT

In article <56431@olivea.atc.olivetti.com> geoff@strobe.ATC.Olivetti.Com (Geoff Caras) writes:
>I am interested in development tools for the amiga, in particular
>C (potentially C++) compilers for the amiga. I have seen a lot of postings
>on learning/switching to C on the amiga...But none on which compilers are
>prefered and are bug free. Also none of the usual sources for amiga software
>seem to carry development tools...

On the C end of things, the pack seems to stick with Aztec C, DICE C,
gcc, and SAS/C (listed alphabetically).  If there are others I hope
this list will be ammendeda as it was left out due to my ignorance of
the state of affairs rather than something on purpose.

On the C++ end of things, there is Comeau C++ and g++.
I am going to remain commentless about bugs and such as my comments
(even on the C compilers) might be viewed as biased.  Instead what 
I would like to say though instead is that I explicitly solicit public
comments about *genuine* Comeau C++ 3.0 bugs expecting alledged unbias
and fair responses (I think mine would be too, but others who do
not know me from BIX or so, may not think so).

- Greg
-- 
         Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                   Producers of Comeau C++ 3.0 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
	    Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a
Newsgroups: comp.sys.amiga.programmer
Subject: HELP!!! - More on Multitasking, Library Base Pointers
From: brycerw@brandonu.ca
Date: 14 Oct 92 10:44:44 CST
Organization: Brandon University, Brandon, Manitoba, Canada

Well, since I'm in the process of moving my code to SAS/C 6.0 for development,
I felt I might as well correct the library thing, and re-open libraries for
each task and process I spawn off.  Problem.

I define all my library bases in one module, and every other modules reference
them via extern.  This is for the entire program, task code and everything.
I also have exactly one routine to open the libraries, in the same module
where they are declared.

One process I spawn off is declared as:

__saveds void Simulation_Handler(void) {...}

In the main process, I do:

	printf("Intuition at %p, DOS at %p\n", &IntuitionBase, &DOSBase);

In this process I spawn off, I have the line:

	printf("Intuition at %p, DOS at %p for child\n", &IntuitionBase, 
		&DOSBase);

This line is right after I re-open libraries for the child process.  The
problem is that the pointers displayed are the same!  Seems to me, I'm just
simply overwriting the same part in memory to specify library base pointers.
Fine if the library returns the same pointer to the library base, but big
problems if the library base pointer is different for each task/process.

From what I can tell, I need the __saveds in the declaration in able to
reference one pointer global to all tasks and processes (read-only after
initialization.)

What am I doing wrong?  What do I do to fix this - to have storage of library 
base pointers at different addresses in memory for each task/process?

Robert Bryce
BRYCERW@BrandonU.CA

Newsgroups: comp.sys.amiga.programmer
From: comeau@csanta.attmail.com (Greg Comeau)
Subject: Re:  Comeau C++
Originator: comeau@well.sf.ca.us
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Date: Tue, 13 Oct 1992 11:35:31 GMT

>in article <BuzCEo.9K8@unx.sas.com>, walker@twix.unx.sas.com (Doug Walker) 
>writes:
>[some stuff deleted ...]
>|> True.  Many people do seem to think that a "native" compiler is
>|> somehow better.  I think that as long as performance is acceptable
>|> and you can debug at the C++ level, it's up to the compiler 
>|> implementor what intermediate language is used.  There is ALWAYS
>|> some intermediate language or languages in place with any compiler.
>|> The fact that this language happens to be C should be irrelevant
>|> to the final user.
>
>So SAS-C++ will come along with a C++ source level debugger, does it?

There is no SAS-C++ and will not be one for some time still.
There is a SAS/C and that does have a debugger.

>Hmmm that triggers some more thoughts.  How do you debug C++ programs
>compiled
>with Comeau C++?  I think every one who does programming in C++ has seen
>the nasty names that are created by the front end as C-function names.
>I really hate to debug this kind of stuff.  printf, sorry, I should say
>cerr debugging is sometimes quite useful, but ablsolutely not state-of-
>the-art.  Is there a source level debugger for Comeau C++ available? 

Not on the Amiga there is not.  It does work with C debuggers
(I don't want to keep harping this, but the only C debugger that
has been know to not work on all the ports we have has been CPR and
non-exhaustive testing shows that the SAS/C 6.0 CPR alleviates this).

This of course does not mean that the C debugger will understand say
a virtual function call in a multiple inheritance hierarchy, but
it will understand at least all the C stuff.  Furthermore, in cases
like our various UNIX ports, we front end either sdb or dbx to alleviate
the name mangling issue.  It is on the non-UNIX ports that we do not
have a mechanism to speak with the debugger.

In all seriousness, and practicalness, a debugger should not be an
end-all solution.  There are other mechanisms available to folks.
(And I do *not* say this as an excuse to anything, just as what I think
is a valid statement in general).

Re printf/cerr, cerr is not an end-all either.  If printf still rubs
you right, but all means use it.   Just know when to change when it
is appropriate.

- Greg
-- 
         Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                   Producers of Comeau C++ 3.0 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
	    Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a
Newsgroups: comp.sys.amiga.programmer
From: earl@rtsg.mot.com (Brent R. Earl)
Subject: curses source or aztec object file
Organization: Motorola Inc., Cellular Infrastructure Group
Date: Thu, 8 Oct 1992 00:54:31 GMT

I am looking for source to curses, or an object file that
will work with the aztec manx 5.2a linker.  I have tried
the curses200b.zoo, but the curses.lib is not one that
aztec recognizes, and I can't think of any quick and
dirty way to convert it.
Newsgroups: comp.sys.amiga.programmer
From: Hans Ridder <ridder@zso.dec.com>
Subject: Re:  Multithreaded code using CreateTask()
Originator: ridder@zowie.zso.dec.com
Organization: Digital Equipment Corporation - DECwest Engineering
Date: Sat, 10 Oct 1992 22:04:44 GMT

In article <1992Oct8.212329.13048@samba.oit.unc.edu> Todd_Lewis@unc.edu (Todd M. Lewis) writes:
>In article <heinz.03ws@edohwg.adsp.sub.org> heinz@edohwg.adsp.sub.org (Heinz  
>Wrobel) writes:
>>If people use libraries without reading the docs it's ok that things break.
>>You don't need a new OS call just because somebody is too lazy too document
>>certain things or somebody else is too lazy to read those docs ;^)
>
>The library mechanism is well documented and it is well-understood.
>Nothing about the spec restricts cooperating tasks from sharing a base
>pointer, and lots of popular programs have been doing it for years.

[Lots of other good stuff by Mr. Lewis deleted]

>I guess what really steams me about all this is that the Amiga has a
>really clean software architecture.  You start letting little
>restrictions like this creep in all over the place and you'll wake up
>one day and find it isn't fun to program anymore--it'll become just
>another software platform with a bunch of ugly restrictive warts. 

I agree with everything Todd says here.  I've never seen a *general*
restriction on tasks sharing library base pointers documented in any of
the RKM's, and I have RKM's going back to V1.0.

What concerns me is that I've been watching this thread, and haven't
seen any authoritative conclusions on the topic from anyone at C=, just
lots of opinions from various folks around the world.

Anyone from C= care to tell us the bottom line on sharing library base
pointers?

>    Todd M. Lewis / Todd_Lewis@unc.edu / utoddl@guitar.oit.unc.edu

-hans
-- 
  Hans-Gabriel Ridder				Digital DECwest Engineering
  ridder@rust.zso.dec.com			Bellevue, Washington, USA
  {pacbell,pyramid,uunet}!rust.zso.dec.com!ridder
From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: HDMem vs GigaMem for virtual memory on Amigas?
Date: 7 Oct 92 08:42:42 GMT
Organization: Commodore Germany

In article <1992Oct6.215329.28368@unibi.uni-bielefeld.de>, markus@techfak.uni-bielefeld.de (Markus Illenseer) writes:
 > In article <9748@cbmger.de.so.commodore.com>, peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany) writes:
 > |> 
 > |> Hmm, don't have an open A4000 just besides me, but I remember Dave H
 > |> stating several times here that the A4000 has the *full* 68040, not
 > |> the EC variant.
 > 
 >  Peter, i am just wondering... The german manual of the A4000 states that the
 >  A4000 has an 040EC build in (ok, i must admit: it's mentioned 'probably'),
 >  and there is a full-featured hand-book about how to upgrade the 040EC to
 >  a real 040 (remove 040EC, insert 040). 
 >  Now, how long have you been working on the manual ? Seems that the 040
 >  was a last-minute choice ? 

Yep, maybe. You see, those manual tranlsations take a lot of time, so they
happen many weeks before the finished mashine ships. At that time we only
had prototypes that didn't look very much like the final one, and nobody
could know what details would finally go into it. So this EC040 thing is
one of the inevitable accidents that can happen throug hsuch a long and
complex preparation period. Perhaps we can fix this for some future manual
version.

Just checked with the actual text. We say (retranslated) "the module may
have the EC040 processor version on it and then lacks the following
parts...". So we *were* prudent to not tell blatant lies :-).

-- 
Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
From: chrisg@cbmvax.commodore.com (Chris Green)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Trying to scroll!
Date: 13 Oct 92 12:49:25 GMT
Reply-To: chrisg@cbmvax.commodore.com (Chris Green)
Organization: Commodore, West Chester, PA

In article <9800@cbmger.de.so.commodore.com> peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany) writes:
>In article <GREENDOG.92Oct9110956@insti.physics.sunysb.edu> greendog@insti.physics.sunysb.edu (Michael D. Fischer) writes:
> >
> >That worked fine (just a counter).  When I changed the ASM code to do
> >my scroll strange things happen.  The scrolling DOES work, smootly, for
> >about 3-4 seconds, and then the computer reboots.  
> >
> >        XREF    _LVOScrollRaster
> >        XREF    _rp
> >
> >        jsr     _LVOScrollRaster(a6)    * do the scroll
>
>The docs for ScrollRaster() tell that you need a TmpRas, a separate
>bitplane (or part of), where the system first renders anything. You have
>to provide a pointer to a TmpRas in your RastPort. 

	Not true. A Tmpras is not required. 1.2/1.3 does have a bug which causes
a memory loss when there is not a tmpras attached, but this only applies
to ScrollRaster with SuperBitMap layers.
-- 
*-------------------------------------------*---------------------------*
|Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
|                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
|My opinions are my own, and do not         - icantforgettheimpression  o
|necessarily represent those of my employer.- youmadeyouleftaholeinthe  r
|"A screaming comes across the sky..."      - backofmyhead              d
*-------------------------------------------*---------------------------*
From: tjf@ukc.ac.uk (Belgarion)
Newsgroups: comp.sys.amiga.programmer
Subject: test
Date: 16 Oct 92 16:08:35 GMT
Article-I.D.: ucbvax.9210161609.AA18226

Just a test. Sorry.
Belgarion, King of Riva, Overlord of the West, and so forth.   | 
Head of Development, RGBSoft. Watch for us on your Amiga.      |  tjf@ukc.ac.uk
"So Calvin, what if someone decides to invade America?"        |   An RGBSoft
"No worries. Hobbes will eat them all. That`s what tigers do." |   Production.
-------------------------------------------------------------------------------
Disclaimer : No-one involved in the posting of this message except for the
stated author claims any responsability for its content or veracity.
-------------------------------------------------------------------------------
Newsgroups: comp.sys.amiga.programmer
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Subject: Re: C++/G++ programming question
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Fri, 9 Oct 1992 02:21:02 GMT

In article <1992Oct8.011236.3156@tplrd.tpl.oz.au> paulg@tplrd.tpl.oz.au (Paul Gittings) writes:
>I've started using C++ (g++) as a "better C" and I've run into a problem.
>The definition for the graphics library pointer, GfxBase, in C is
>
>        struct GfxBase *GfxBase;
>
>or in C++
>
>        GfxBase *GfxBase;
>
>This works  OK and I can even assign a library pointer to GfxBase.
>The problem I run into is when I try to close the graphics library
>
>        CloseLibrary((Library*) GfxBase);
>
>I get a message from g++; name GfxBase could be a type or expression.
>Compiler assuming type.
>Which results in a parse error, because we really wanted the variable
>GfxBase not the type GfxBase.  Is there any way (I'm new to C++) to

I used not a particularly beatiful solution, but it works. Actually the 
ones to blame are the guys responsible for the naming disaster ;-))

GfxBase *gfx_base asm ("_GfxBase");

That way you can refer to GfxBase as gfx_base, and no name conflicts arise
anymore.

-Markus

PS: side note to C++/G++ users trying to use either the <inline/*> or
Commo's <clib/*> headers: replace any parameters called "class" or "template"
by something not being a keyword, ie. _class or Class or whatever you want;-)
Currently, at least dos.h and intuition.h have this problem, I think
graphics.h as well, but I might be wrong there.
-- 
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: gb03@ns1.cc.lehigh.edu (GEORGE PHILIP BLUHM)
Newsgroups: comp.sys.amiga.programmer
Subject: Looking for EIFFEL by mBertrand Meyers on the Amiga
Date: 16 Oct 92 01:04:34 GMT
Organization: Lehigh University

Does there exist an Amiga version of Eiffel for the Amiga.


George Bluhm
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Bug in SAS/C 6.0
Originator: walker@twix.unx.sas.com
Date: Fri, 16 Oct 1992 13:44:34 GMT
Organization: SAS Institute Inc.
Keywords: SAS/C


In article <1992Oct15.120938.7542@uni-paderborn.de>, tron@uni-paderborn.de (Matthias Scheler) writes:
|> I call "AddAppIcon(...)" and afterwars a4 is trashed, so what should example
|> code be usefull for ?
|> -- 
|> Matthias Scheler                                         tron@uni-paderborn.de
|> University of Paderborn (Germany)

It would be useful because it doesn't happen for just any call
to AddAppIcon.

For example, the call below is correct:

;    5:   AddAppIcon(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
              MOVE.L         A4,-(A7)                 ;2f0c 
              CLR.L          -(A7)                    ;42a7 
              CLR.L          -(A7)                    ;42a7 
              CLR.L          -(A7)                    ;42a7 
              CLR.L          -(A7)                    ;42a7 
              CLR.L          -(A7)                    ;42a7 
              MOVEQ.L        #$0,D0                   ;7000 
              MOVE.L         D0,D1                    ;2200 
              SUB.L          A0,A0                    ;91c8 
              SUB.L          A1,A1                    ;93c9 
              SUB.L          A2,A2                    ;95ca 
              SUB.L          A3,A3                    ;97cb 
              MOVE.L         WorkbenchBase(A4),A6     ;2c6c 0000 
              MOVE.L         A7,A4                    ;284f 
              JSR            $ffffffc4(A6)            ;4eae ffc4 
              ADD.L          #$14,A7                  ;dffc 0000 0014 
              MOVE.L         (A7)+,A4                 ;285f 

Note that A4 is preserved in the first assembly instruction in
the list, and restored in the last one.

As it happens, this is PROBABLY a bug with deferred stack 
cleanup that was reported by someone else.  We are testing
a fix for this now and will be distributing it soon in a patch.
The only way to make SURE it is the same bug is if you show
us exactly what is going wrong in your code.

Never assume that just by stating what is going wrong we can
figure out how to fix something.  If we hadn't already had a
report of this problem, your posting would not have given us 
enough information to come up with a fix.  Usually it takes
a very specific set of circumstances to make a bug show up,
since our testing would uncover things like "It just doesn't
work no matter what you do."

-- 
  *****
=*|_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.

From: aoe@hpfcso.FC.HP.COM (Alexander Elkins)
Date: Thu, 8 Oct 1992 20:47:46 GMT
Subject: Defect: SAS/C "se" (screen editor)
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.sys.amiga.programmer

There is a defect in SAS/C "se" (screen editor).  To see the defect turn
on the auto-indent feature and turn off expand tabs to spaces.  Then type
in exactly the following text test case, substituting keystrokes for <return>,
<tab>, and <backspace>:
0123456789<return><tab>abcd<return><backspace>

What you see is
0123456789
	abcd
       89
       ^cursor is here

This is very annoying since I like to use tabs for indentation and find
the auto-indent feature a keystroke saver.

 - Alexander Elkins [aoe@hpfiaoe.fc.hp.com]
From: Fred_M_Hamilton@cup.portal.com
Newsgroups: comp.sys.amiga.programmer
Subject: Problem with SCMSG AREXX in SAS/C 6.0
Date: Sat, 10 Oct 92 19:41:12 PDT
Organization: The Portal System (TM)
Distribution: world

I'm having a lot of trouble getting scmsg to send AREXX commands to my 
editor (QED1.0e).  I believe I have configured it correctly-here is the
relevent config info from the env: file:

PORTNAME QED1
EDITCOMMAND Sys:Utilities/QED -PQED1 %f
GOTOFILE open "%f\n"
GOTOLINE goto "%l\n"

The first two parameters work perfectly:  If QED1 is not an active message
port, scmsg launches QED, and QED loads the file specified by %f.  If QED1
is already active it does not try to launch another copy of QED.  If I 
change QED1 to QED2 in the first parameter, scmsg waits for QED2 for about 
30 seconds (with dots lining up in the window titlebar) until it pops up
a requester saying it could not locate QED2.  So I believe the first half
is working properly.

However, scmsg can not make QED goto the %l line, or open up a new file
different from the one it may have opened with the EDITCOMMAND statement.
The GOTOFILE and GOTOLINE statements simply aren't getting to QED.  I have 
tried every variation I can think of, with and without the '\n':

GOTOLINE GOTO 4
GOTOLINE 'GOTO 4'
GOTOLINE "GOTO 4"
GOTOLINE GOTO "4"
GOTOLINE GOTO '4'

but nothing seems to work.  I have verified that QED1 is an open, working
message portby using a little CanDo program (RexxBrowser) to send messages
to it.  If I type "GOTO 4" or "goto 4" in RexxBrowser, QED goes to line 4.

Does anyone have any idea what I, QED, or scmsg could be doing wrong?

Can anyone point me in the direction of a program that RECEIVES rexx 
messages and prints them out literally, so I can compare what RexxBrowser
is sending with what scmsg is sending?

Any help will be greatly appreciated!

-Fred

(I just registered for EMITS, so I'll pursue that avenue as well)
From: pdietz@cse.unl.edu (Phil Dietz)
Newsgroups: comp.sys.amiga.programmer
Subject: How to make RESIDENT data structures change?
Date: 14 Oct 1992 02:55:25 GMT
Organization: NCEMRSoft
Distribution: world
NNTP-Posting-Host: cse.unl.edu


I have a big data file I parse down into strings...and I store their pointers.

I would like for these pointers to _stay in memory_...so when the program is
run again, these strings need not be parsed again....I have deduced that
a RESIDENT program should have this quality I need.  I realize that
the __near hunk is recopied/cleared each time it is run, so it won't work...
but it there a hunk that isn't recopied?

Is it possible to store these pointers in some RESIDENT HUNK once, then any
further call of the program would simply use the pointers already in memory?

(I am using SAS6.0 and linking with cres.o)
(I am parsing my own pseudo-localization files...I'd like to store these )
(to make the localized program run faster on a 2nd execution...)

--
   I'm not a PowerLifting Tele-Evangelist                     Phil Dietz
           although I DID play                        pdietz@cse.unl.edu
              one on TV!                          University Of Nebraska