HDTenEightyP/NetNews huggingface dataset:
From: chucks@pnet51.orb.mn.org (Erik Funkenbusch)
Newsgroups: comp.sys.amiga.programmer
Subject: Multiple Windows
Date: 11 Dec 92 10:05:03 GMT
Organization: People-Net [pnet51], Minneapolis, MN.

Is there an easier way of telling which Window a Window pointer is pointing
without resorting to the UserData field?

I have an application where i have several windows that open up.  Rather than
calling a different IDCMP Dispatch function for each window, i used unique
gadget ID's for every gadget in the program, even if they have different
windows.

My problem here is that i'd rather use a program like GadToolsBox to design
everything, and GadToolsBox defaults each gadget id to 0 for each new window. 
Sure, i can modify the generated source, but then if i modify my GadToolsBox
image and regenerate i need to make these modifications again.

I can use the STart ID field in the window data requester, however this means
that i have to know how many gadgets are in the other windows, and heaven help
me if i add more to a previous window..

So, my solution would be to have my IDCMP Dispatch routine know which window
it's dealing with and handle the appropriate gadget based on that.

I can think of only one way to legally do this, and that's use the UserData
field to point to a window number or something.  Is there an easier way?

As a side note, has anyone else noticed that GadtoolsBox 1.3 doesn't generate
the proper IDCMP flags for gadgets when you start adding a lot of windows?

.-----------------------------------------------------------------------------.
| UUCP: {crash tcnet petrus quest}!orbit!pnet51!chucks | Amiga, IBM, and any  |
| ARPA: crash!orbit!pnet51!chucks@nosc.mil             | system you let me    |
| INET: chucks@pnet51.orb.mn.org                       | get my grubby mind   |
|------------------------------------------------------| into.                |
| Programmer at large, employment options welcome, inquire within.            |
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: lionel@cs.city.ac.uk (Lionel Tun)
Subject: Re: CISC and RISC
Organization: City University, London
Date: Fri, 18 Dec 92 14:51:40 GMT

ahansfor@bigwpi.wpi.edu (Andrew L. Hansford) writes:
>>>>>> On 18 Dec 92 00:56:48 GMT, idr@rigel.cs.pdx.edu (Ian D Romanick) said:
>
>idr> It's to the
>idr> point now on RISC machines that a native compiler can usually
>idr> BEAT and assembly language progammer (snif) 
>
>No doubt.  Compiler technology has made large advances in dealing with
>RISC.  I am not surprised that a compiler with many man hours of
>development can outperform an assembly programmer on any section of
>code unless the programmer is VERY familiar with pipeline scheduling
>algorithms. 

This is very interesting. I have oftened wondered whether computers
will become better at programming computers than humans. This appears
to be happening at the assembler vs compiler level.

News headlines: Computer (assembly) programmers made redundant
by computer programs!

When will this phenomenon engulf the C programmers and eventually
the 4GL programmers?

--
  ________  Lionel Tun, lionel@cs.city.ac.uk  ________
 / /_  __/\       Computer Vision Group      /\ \__  _\
/___/_/_/\/ City University, London EC1V 0HB \ \___\_\_\
\___\_\_\/        071-477 8000 ext 3889       \/___/_/_/
Xref: sparky comp.sys.amiga.programmer:17447 comp.sys.amiga.misc:18681
From: jaker@csugrad.cs.vt.edu (Jake Rose)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
Subject: Re: Advice to SAS/C 5.10b users
Date: 16 Dec 92 23:50:06 GMT
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA

shulick@shoshone.ucs.indiana.edu (Sam Hulick) writes:

>It would be rather safe to stick with 5.10b.  6.0 and 6.1 are too
>buggy.. But you can probably see that from all the posts(complaints) on
>c.s.a.p. :)

I've been using my roommate's version 6.1 compiler for a while now, and I
haven't had any real complaints.  It's a little different, but I wouldn't
call it "buggy".  People just haven't gotten used to the differences yet.

>-- 
>    // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)
>   // 68030 25 MHz /__/\ \ My opinions wear combat boots.  Or whatever.
>\\// OS 2.04       \__\/ / "Walk!  Not bloody likely.  I am going in a
> \/                     / taxi."  --George Bernard Shaw
-- 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Jake Rose               :: MS Windows: faster than a dead sea turtle crawling up
jaker@csugrad.cs.vt.edu :: the beach with a boxcar on its back, but only just.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Newsgroups: comp.sys.amiga.programmer
From: shulick@navajo.ucs.indiana.edu (Sam Hulick)
Subject: THANK YOU!! (ReadArgs()).. but I'm handling something wrong
Originator: shulick@navajo
Reply-To: shulick@navajo.ucs.indiana.edu
Organization: Vallen Software
Date: Sat, 19 Dec 1992 05:58:24 GMT


Thanks to EVERYONE who replied & helped out. :)  After a couple replies,
I got things working, so most of the mail I got about ReadArgs() I
skimmed thru quickly & deleted.

Well, the /M/A works and everything.  Umm, something stopped working,
though.  :)  My template has gotten big, and I have these switches..

".....,B=Blah/S,F=Foobar/S,....."

Well, I used to check them like this:

   blah_mode = arr[1] == -1;   /* assume 'B=Blah/S' was the second in */
                               /* the template */

Well, it used to work, but now I have lots of things in my template, and
even though I DON'T specify a switch, it gets set -1 anyway!  So what's
the REAL way to check if a switch is specified?  Please POST, do NOT
reply via e-mail.. I get way too many responses to read. :)   Thanks.

-- 
    // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)
   // 68030 25 MHz /__/\ \ My opinions wear combat boots.  Or whatever.
\\// OS 2.04       \__\/ / "Walk!  Not bloody likely.  I am going in a
 \/                     / taxi."  --George Bernard Shaw
From: bn@mndcrme.uoknor.edu (Bo Najdrovsky)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Cobol for the Amiga?
Date: 14 Dec 92 03:23:34 GMT
Article-I.D.: mndcrme.bn.01ix
Organization: Operation Mindcrime
X-Newsreader: TIN [version 1.1 PL6]

Paul Kienitz (paulk@terapin.com) wrote:
:
: I never had to, and I went to a cheap school that was real heavy on
: that sort of thing.

Then you're lucky. I kept putting it off myself, but they didn't
drop the requirement. If I wanted to graduate, I had to suffer through
it.

:
: But think of something else:	so many programmers refuse to touch
: COBOL nowadays that the few who are willing to really get into it
: get LARGE money for maintaining those old programs.

You are a bit off base there. There is a surplus of Cobol people out there.
The demand is for C/C++ programmers with Unix and GUI (Motif mainly) expe-
rience.

p.s. I'm not just making this up. It's info from a professional recruiter
that specializes in locating programmers for companies.

--
---------------------------------------------------------------------------
|  Bo Najdrovsky  bn@mndcrme.uoknor.edu bn@okcforum.uoknor.edu|    //	  |
|							      |   //	  |
|      "I remember now, I remember how it started..."         | \X/ AMIGA |
---------------------------------------------------------------------------
Xref: sparky comp.sys.amiga.programmer:17472 comp.sys.amiga.misc:18715
From: walker@twix.unx.sas.com (Doug Walker)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
Subject: Re: Advice to SAS/C 5.10b users
Date: 17 Dec 92 14:17:37 GMT
Organization: SAS Institute Inc.
Originator: walker@twix.unx.sas.com


In article <BzD93n.JCo@usenet.ucs.indiana.edu>, shulick@shoshone.ucs.indiana.edu (Sam Hulick) writes:
|> 
|> It would be rather safe to stick with 5.10b.  6.0 and 6.1 are too
|> buggy.. But you can probably see that from all the posts(complaints) on
|> c.s.a.p. :)

I don't agree at all.  In anything the size of SAS/C, there are going
to be bugs.  I believe the majority of V6 customers are not experiencing
major problems - you just hear about the ones that are on the net 
because they are reporting them.

6.1 fixes most of the problems reported in 6.0, except of course that
we broke the MATH=68881 option.  If you don't use that particular
option, or can afford to use a different math option for a short
time, 6.1 should be as stable or more stable than 5.10b.

There were bugs in 5.10b, as well.  We discovered several while
testing 6.0, in fact, that had never been reported.

|>     // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)

-- 
  *****
=*|_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: mk59200@cs.tut.fi (Markku Kolkka)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: RCS
Date: 15 Dec 1992 12:27:02 GMT
Organization: Tampere University of Technology
Distribution: world
NNTP-Posting-Host: kuparirastas.cs.tut.fi

In article <WALT.92Dec10105911@bcarh1d7.bnr.ca> walt@bcarh1d7.bnr.ca (Walt Sullivan) writes:
>You could probably alias ci to "ci -l", if you're using a reasonable
>shell. But I don't see why you'd want to give up the ability to ask
>RCS for a read-only copy of your source (with "co" (or "ci", following
>a "co -l")).

ci -l or co -l gives an _editable_ copy of the source, not read-only.

BTW. is there an updated version of RCS available? The current one can't
handle files with international characters.

--
	Markku Kolkka
	mk59200@cc.tut.fi
From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 18 Dec 92 08:20:56 GMT
Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Organization: Commodore Germany

In article <petter.09wh@pnilsen.adsp.sub.org> cbmehq!cbmnor!pnilsen!petter@cbmvax.commodore.com writes:
 >In article <paulk.2r1u@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
 >>> I'm certain that a sizable list of OS-friendly demos, and probably
 >>> all the well-known demos, can be supplied by the people on this
 >>> here net.  I'll start the list with Boing! (the first demo) and
 >>> Juggler.
 >>
 >> Boing! had to be revised more than once to work on evolving OS
 >> versions.  

Huh?

 >Hey, I got all the demoes which were originaly used to show off the Amiga.
 >They ALL works on my A3000 running OS 3.0 !!   RobotCity, Boing etc. works
 >like a charm.

I second this, at least I tried them under 2.04 and had no problem.

BTW, we are here in .programmer: I still don't understand how the shadow
of the ball was done in Boing over the raster. Is it a masked bitplane
or such stuff?

-- 
Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
Wer's nicht kann, soll's bleiben klopfen oder Steine lassen!
Newsgroups: comp.sys.amiga.programmer
From: etxpihl@eua.ericsson.se (Tomas Pihl)
Subject: MX_KIND Radio buttons
Keywords: MX_KIND, c, amiga, radio
Reply-To: etxpihl@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Mon, 14 Dec 1992 13:48:09 GMT

Could someone tell me how to tell (at any time) which one
of my radio buttons that are currently selected?

________________________________________
/ Tomas Pihl
/ ELLEMTEL Telecom Systems Lab, Sweden
/ email:   etxpihl@eua.ericsson.se
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: tjehl@sedona.intel.com (Timothy Jehl)
Subject: Re: CISC and RISC
Originator: tjehl@sedona
Reply-To: tjehl@sedona.intel.com
Organization: Intel Corporation.
Date: Wed, 16 Dec 1992 18:55:21 GMT


In article <1gnl0mINNpq2@crcnis1.unl.edu>, tbills@cse.unl.edu (Trent Bills) writes:
> 
> |> >What are the advantages of CISC and RISC?
> 
> RISC is based on several observations made by looking at compiler generated
> code.  The first is that compiler writers have great difficulty in trying
> to find situations under which a complicated assembly code instruction
> can be used.  It has been observed that compilers for CISC machines do not
> typically make use of "nifty" instructions.  Second, it has been observed
> that compilers for CISC machines ussually only use one or two addressing
> modes.  Therefore, in the RISC processor, only one or two addressing modes
> are implemented.  These simplifications and the register to register only
> operations allow RISC designers to fit their instructions into a fixed
> size instruction word (32 or 64 bits).  The fixed size instruction word
> greatly reduces the complexity of the instruction decode portion of the
> CPU.  All of these simplifications add up to a great savings in space
> on the chip.  This extra space can be used for a cache, large register
> file, or on chip coprocessors.
> 
   There is one (and only one) reason for RISC processors : clock speed.
There is absolutely no advantage to having a lesser instruction set unless
you can make the device run faster.  It is true, as pointed out above, that
simplifying the instruction set results in less complex decoding logic.
However, the advantage to this less complex logic is speed, not area.
If you can't make the chip run faster, RISC makes no sense.

   On the die area front, we are rapidly reaching the point where the
computational logic on a high end processor is being dwarfed by the
on chip storage.  Minor area savings in the computation are becoming
less important, so expect 1) RISC processors to become more complex,
as the process technology becomes available to allow high speed operation
while performing complex tasks, and 2) CISC processors to move to both
super-scaler and super-pipeline as the processing area becomes cheaper.
In addition, expect the instructions sets of both types of processors to
start expanding to allow conditional execution commands.  As the pipelines
get deeper, the penalty for branches get more expensive.  Instructions
which allow you to do conditional execution without branching will become
vital to maintain code throughput.
-- 

"It really only matters to the people who care."

Newsgroups: comp.sys.amiga.programmer
From: shulick@navajo.ucs.indiana.edu (Sam Hulick)
Subject: Re: Sigh.. OKAY.  ReadArgs() is buggy?
Organization: Vallen Software
Distribution: inet
Date: Sat, 19 Dec 1992 19:24:12 GMT

In article <S37732V.92Dec19110643@lk-hp-16.hut.fi>, s37732v@snakemail.hut.fi (Markus Juhani Aalto) says most sayishly:
>Did you initialize arr array to zeros. Like this arr[0]=0; arr[1]=0; etc..

Oh blah.  Don't you hate stupid mistakes? :)  Ok, it works now, with
this addition before ReadArgs():

  memset(arr, '\0', sizeof(arr));

Thanks.  I probably would've spent the next year trying to figure THAT
one out. :)

-- 
    // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)
   // 68030 25 MHz /__/\ \ My opinions wear combat boots.  Or whatever.
\\// OS 2.04       \__\/ / "Walk!  Not bloody likely.  I am going in a
 \/                     / taxi."  --George Bernard Shaw
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Hardware Reference Manual
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sun, 13 Dec 1992 19:55:08 GMT

In <1992Dec11.144552.1339@imada.ou.dk> breese@monet.imada.ou.dk (Bjoern Reese) writes:
>You simply can't blame the hardware bangers without blaming C=.
>Whether C= have matured or not, the harm was done, and they
>contributed to this situation, IMHO.

Heh, the only fault they made was making the hardware manual the cheapest.

A large number of 'hardware bangers' that I know bought the hardware manual
because it is sufficient to write programs that use Amiga specific things.
Why should they pay more ?

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
From: aesba1ii@dct.ac.uk
Newsgroups: comp.sys.amiga.programmer
Subject: help!
Date: 10 Dec 92 11:55:25 GMT
Organization: Dundee Institute of Technology



  anyone get me the address where i can get a pc downloader?


  schleppel
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: linking 2.0 version of amiga.lib
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sat, 12 Dec 1992 20:46:54 GMT

In <1992Dec10.093712.17702@cam.compserv.utas.edu.au> dbenn@leven.appcomp.utas.edu.au (David Benn) writes:
>Doesn't SAS C use Blink? If so, then the answer must be a little more
>complicated than that.

Yes and no. SAS uses Blink but this Blink is quite different from the
last freely distributable version of Blink (i.e. Blink 6.7).

You may try Alink (available from C=). Alink is quite slow, doesn't
understand indexed libraries and lacks all the fancy capabilities
of Blink. But as a plain Amiga linker it works fine.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Help me with Shell scripts (AmigaDos or sksh)
Date: 12 Dec 92 10:24:51 PST
Organization: BBS

> System() is the only one I've found which is general enough for my
> needs.
 
I bet it would be helpful in several areas if you used RunCommand.
Maybe you can use System in cases where it has to be asynchronous and
RunCommand the rest of the time?
Newsgroups: comp.sys.amiga.programmer
From: cpc@shell.portal.com (Chris Cebelenski)
Subject: Re: AmigaDos Assign command
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
Date: Thu, 17 Dec 1992 03:14:34 GMT

In article <ianm.03r4@laghey.UUCP> ianm@laghey.UUCP (Ian Moran) writes:
>I have noticed strange behaviour with the 'assign' command under 2.04 and
>above. If I take advantage of the multiple assign facility thus :
>
> assign rexx: s: dh0:turbotext/rexx
>
>Then Arexx macros will not be located under Turbotext which is contrary to
>what I would expect, only s: is searched.
>
>Also, why do few (if any) file requesters follow multiple assigned
>paths similar to the above. If I enter rexx: in the C= requester then I will
>get only the contents of s:
>
Actually, I've found that most directory programs will not follow multiple
ASSIGN's.  On my system, even LIST won't follow them.  Is there a correct
way to program this?  (Obviously people are doing SOMETHING wrong..)

cpc
cpc@shell.portal.com
The opinons expressed above are mine alone, and do not necessarily
represent the views of any employer or agency.
From: peter@cbmvax.commodore.com (Peter Cherna)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Newbie font/screen question
Date: 16 Dec 92 21:17:22 GMT
Reply-To: peter@cbmvax.commodore.com (Peter Cherna)
Distribution: na
Organization: Commodore-Amiga, Inc.  West Chester, PA.

In article <1992Dec15.215729.24166@ms.uky.edu> kherron@ms.uky.edu (Kenneth Herron) writes:
>So, besides setting up the TextAttr, what's the minimum I need to
>do with the font?  I'm guessing the OS only does an OpenFont() so
>the font has to already be in memory; I can assure this by calling
>OpenDiskFont() first, but that leaves an extra use count lying around,

Use counts are free, so don't worry about it.  Indeed, the correct
way is:

	if ( OpenDiskFont( ... ) )
	{
	    if ( OpenScreen( ... ) )
	    {
	        ...
	        CloseScreen( ... );
	    }
	    CloseFont( ... );
	}
	
>I suspect AddFont() and RemFont() figure into this...

No, those are used to add/remove a TextFont to the public font list.  This is
automatically handled by OpenDiskFont().

>Kenneth Herron                                              kherron@ms.uky.edu

     Peter
--
Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
"Opinions enlarged to show detail"
Newsgroups: comp.sys.amiga.programmer
From: chris@132.236.236.117 (Christopher A. Wolf)
Subject: Getting a valid FileSysStartupMsg pointers.
Content-Type: text/plain; charset=iso-8859-1
Nntp-Posting-User: tc13@cornell.edu
Reply-To: chris@alchemy.tn.cornell.edu
Content-Transfer-Encoding: 8bit
Organization: none
X-Newssoftware: GRn-beta 1.16g (10.12.92) by Michael B. Smith & Mike Schwartz
Mime-Version: 1.0
Date: Sun, 13 Dec 1992 03:00:20 GMT

I am writing a program which needs to find the exec device name and unit
number and DosEnvec pointer associated with each of the various available
DOS filesystem devices which refer to a physical disk drive.  (i.e.  I want
to find out that DF0: is trackdisk.device unit 0 and that DH1: is
gvpscsi.device unit 1 for example while ignoring things such as RAD:, RAM:,
or remotely mounted network devices)

My basic approach has been to walk the DOS DeviceList, doing an
IsFileSystem() on the dol_Name field of each entry to find out which
devices are valid filesystems and to weed out things like PRT:, PAR:  and
SER:.  On those devices that are valid filesystems I am then looking at the
dol_StartUp field to get a pointer to the FileSysStartupMsg and from there
I can extract a pointer to the device name, unit number and DosEnvec
vector.

However, apparently dol_StartUp does NOT always point to a valid
FileSystemStartupMsg (hereafter abbreviated FSSM) even though IsFileSystem()
returns true.  I have particularly found this to be the case on devices
which are not physical disks such as RAM disks or remotely mounted
network devices.

I have been unable to find any documentation on this point so am appealing
to the net wisdom 8)  My questions are - how can I tell when
dol_StartUp actually points to a valid FSSM? or is there a better/easier
way to extract the info I am looking for?  Also how can I -reliably-
eliminate non-physical disks (i.e.  RAM or network disks) from my search?
Will only physical disks have a valid FSSM?

Any light you can shed on this matter would be greatly appreciated.
Thanks!

                                             - Chris

--
------------------------------------------------------------------------------
Christopher A. Wolf   mail: chris@alchemy.tn.cornell.edu   IRC: cwolf (#amiga)

The rec.arts.sf.starwars Frequently Asked Question List is available via anon.
FTP from the Star Wars archive site at wpi.wpi.edu. "May the FAQ be with you!"
------------------------------------------------------------------------------
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Hardware hacking....
Date: 15 Dec 92 01:54:35 GMT
Organization: BBS

> I can't wait for the firses the OS" game to come
> out for AGA/1200, to prove all these twinks wng.
 
I hear that LucasFilm has at least oe 3.0/AGA game ievelopment.
 
I strongly suspect that AGA will get the Amiga BACK e game
market.  For one thing, think how much easier it will be now to port
anything designed for 256 color VGA or Mac screens.