HDTenEightyP/NetNews huggingface dataset:
From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re: AmigaDOS library functions and ANSI-C programming
Organization: UNC Office of Information Technology
Date: Wed, 30 Dec 1992 14:20:28 GMT

In article <1hrqupINNipe@aurora.unice.fr> beust@aurora.unice.fr (Cedric Beust)  
writes:
>
>In article <1992Dec29.221144.26405@urbana.mcd.mot.com>,
>qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:
>>AmigaDOS functions which take pointers to objects when the objects
>>aren't modified are not marked as "const". 

>I was reading the autodoc for AddHead which looks like
>AddHead(struct List *list, struct Node *node)
>and I was wondering if a copy of the node would be done and then
>pointed to in the list or if *my* node would be directly referenced.

In this case, your node will be directly referenced and both
*List and *node will be modified, so they should not be
marked as "const".  It never occurred to me that AddHead() might
not use my node directly.  

>The advantage of this method? Simple : you can use the same
>static node to create a list.

The disadvantage?  Lots of overhead for a feature you almost never
need or want.  In the rare case when you do, make the copies yourself
before you call AddHead().

>Since this wasn't mentioned in the autodoc,
>I decided to go safe and allocate myself a new node at each call.
>The information might be in the RKM (I didn't check), but I really
>think this kind of detail should be mentioned, either in natural
>language, or by the use of the const keyword whenever possible.

In this case the const keyword would be dead wrong.  However, it
would be better if const were used where appropriate.
--
 _/_/_/  _/     Todd_Lewis@unc.edu          You can lead a horse to 
  _/    _/     utoddl@guitar.oit.unc.edu   Mohammad, but you can't make
 _/    _/_/_/                             a mountain drink a mole hill.
From: s37732v@snakemail.hut.fi (Markus Juhani Aalto)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: WindowToBack() ... BUG?!?!?!
Date: 30 Dec 92 15:51:13 GMT
Organization: Helsinki University of Technology, Finland
Distribution: world
NNTP-Posting-Host: lk-hp-17.hut.fi
In-reply-to: k114636@cc.tut.fi's message of 30 Dec 1992 13:03:15 +0200

In article <1hrvlkINN2lg@cc.tut.fi> k114636@cc.tut.fi (Kuulusa Mika) writes:


   I'll discribe a bit...

   I have a program running on the background which does
   WindowToBack() every 4 seconds. Then I start dragging an
   icon (in Workbench) and when the program does WindowToBack(),
   the icon VANISHES. Just like that. Hm.... why?

I had the same problem and it has to do something with layer lockings.
Someone form Commodore explained this to me once, but I can't recall
what the exact reson was.

   How should I make the window go background? With layers.library
   I can make the windowlayer go background, but I don't know how
   to refresh other layers in the screen. Can someone help me?

You have to try to lock layers before use WindowToBack().
Check the code in the end.

	   Mika Kuulusa		                          p.931-236 304
	   Yliopistonkatu 46B49,33100 TAMPERE      email k114636@cc.tut.fi
	   FINLAND				"Ei saa j{{d{ tuleen makaamaan"

----------- clip here --------------------

/* 	Lock layers. If someone else has locked it, then we wait. */
LockLayerRom( WorkbenchScreen->LayerInfo.top_layer );
Forbid();
UnlockLayerRom( WorkbenchScreen->LayerInfo.top_layer );

WindowToFront(MyWindow);	/* Or use WindowToBack() */
Permit();

----------- clip here -----------------------

This ought to do it.


--


**************************************************************************
*         Markus Aalto              | Helsinki University of Technology  *
*                                   |                                    *
*  EMail: s37732v@vipunen.hut.fi    | Faculty of Electric Engineering    *
*  Fax:   358-0-8746991 (Sometimes) |                                    *
*                                   | Undergraduate in Computer Science  *
**************************************************************************
        
Newsgroups: comp.sys.amiga.programmer
From: labenrsa@ICIL64.CILEA.IT
Subject: Re: Icon dragging fun (Hmm?)
Organization: CILEA - v R. Sanzio 4 - Segrate - ITALY
Date: Wed, 30 Dec 1992 09:38:36 GMT
Reply-To: labenrsa@ICIL64.CILEA.IT

In article <C017xr.48z@csugrad.cs.vt.edu>, jaker@csugrad.cs.vt.edu (Jake Rose) writes:
>Hello out there in programmation land...
>
>....does anyone know if it's possible to have your program become a *source*
>for draggable icons

Jack,

About one year ago, I had a long discussion in a restricted conf with
J.Mackraz (sp?). It was 2.0 beta time, and appicons/menus/... was one
of the topics.

I complained that the Amiga system seemed to get all the new stuff in
the wrong places: in this case, icon drag/drop being a Workbench feature
rather than an Intuition feature. Another case was boopsi starting out
as an object oriented USER INTERFACE and being within intuition rather
then a basic system feature that new subsystems of any kind could be
built upon.

If I recall well, J.M. mantained that it would have been very hard, if
not impossible, to provide secure arbitration of layers on public screens
when multiple applications were involved in a drag-drop (which would
typically imply dragging a BOB over windows).

It seemed at that time that the basic stuff is indeed in place (layer
locking IS there), but some othe parts of the system which would have
been involved needed some major overhaul. This was the case with Workbench,
which seemed to mess around with its screen a lot.

If J.M. or any other CBM person can confirm or deny this (I have memory
leaks...), please correct me.

Now, we know that the Wbench HAS been re-written, and things may be
different now. I also recall, a while back I read some more info about
a forthcoming pair of boopsi classes for draggable objs and dropboxes,
but I can't dig that out at this moment. Anyone has more on that?

				Andy.

------
Andy Zanna
E.Mail SDEVAX::ZANNA@icil64.cilea.it
From: s37732v@snakemail.hut.fi (Markus Juhani Aalto)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: How do you resize GadTools gadgets??
Date: 23 Dec 92 16:25:33 GMT
Organization: Helsinki University of Technology, Finland
Distribution: inet
NNTP-Posting-Host: lk-hp-19.hut.fi
In-reply-to: gel36@gel.ulaval.ca's message of 22 Dec 92 21:20:09 GMT

In article <gel36.725059209@matapedia> gel36@gel.ulaval.ca (Usager temporaire) writes:

   I'm working on a resizable window and I need to resize
   my listviews whenever I get a NEWSIZE message.
   Is there a way I can resize the listviews without having
   to use FreeGadgets() and CreateGadget() to rebuild all
   my gadgets?

No.

   Why are the GFLG_RELWIDTH, GFLG_RELBOTTOM, etc... flags
   filtered by Gadtools??

Because GadTools doesn't support them. Atleast version 37 didn't.

   I found you could manually add these flags after creating
   a gadget, but they only work with simple gadgets like
   BUTTON, CHECKBOX, ... but they don't work with listviews.

Never add anything to gadtools gadgets. This is illegal thing to do. 

  I'd like to hear from someone who built a resizable window
   with gadtoolsbox and was successfull with resizing...

Yes! What would you like to hear. :^) BTW: I didn't make it with GadToolsBox
but with my 'bare hands'. :)

Okey here is a little description from F-Finder V2.0's main window interface.

1.	It calculates how wide and high window has to be to fit gadgets into
	window with requested font. This is Screen's font normally, but if
	window is too small for that font, then it falls back to Topaz80.

2.	Specify Min dimension for window after step 1.

3.	Calculate gadgets. In F-Finder I used lots of calculations from step 1
	in here.

This approach which in tends to be quite slow is quite 'easy' to implement
and in my A500 it takes
about 1.5 secs to create those gadgets. Refreshing after resize takes about
the same time (which is almost exactly the same time as few progs with
GZZ windows do). I could propably fit this to 1 sec if I would optimize it
wiit assembly code, but I don't think its necessary. Anyway the results are
quite nice and in my opinion the benefits are greater than the slowliness
of gadget creation routines. And remember that with A3000 (or better) this
wouldn't be even noticeable. (And when I uprade to new A4000 I couldn't
care less :^).
--


**************************************************************************
*         Markus Aalto              | Helsinki University of Technology  *
*                                   |                                    *
*  EMail: s37732v@vipunen.hut.fi    | Faculty of Electric Engineering    *
*  Fax:   358-0-8746991 (Sometimes) |                                    *
*                                   | Undergraduate in Computer Science  *
**************************************************************************
From: cschneid@amiga.physik.unizh.ch (Christian Schneider)
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Organization: ICU - University of Zurich, Dept. of Computer Science
X-Newsreader: TIN [version 1.1 PL8]
Date: Tue, 22 Dec 1992 14:33:08 GMT

Angela Schmidt (ry53@rz.uni-karlsruhe.de) wrote:
> or not. TypeOfMem() only works with RAM, but some of the entries in
> the fssm can be in ROM or even in the expansion space as well. So

But a valid fssm is always in ram, wrong?
I'm currently using TypeOfMem() for dn_Startup only, I don't think
this should miss some devices.

> for now, I assume that non-zero-values mean that there is a valid
> fssm. I tried TypeOfMem() but I really missed some devices after that,

This is rather dangerous. No enforcer hits? Did you have devices
with all (five?) possible dn_Startups (NULL, four letter ASCII, char *,
int, valid fssm are the possibilities I think to remember).

> because their device name (and I think the environment vector, too)
> was in ROM.

Which devices did you miss? But fssm itself was in ram?

:     \ /&\   Angela Schmidt cand. inf. (Nessy@IRC) | Amiga //
                             ^^^^ *grin* 

- Chris, stud.inf.ing.eth ;-)

-- 
Chris Schneider - cschneid@amiga.physik.unizh.ch BIX: hschneider IRC: cschneid
It's impossible to enjoy idling thoroughly unless one has plenty of work to do
From: jbhr@sofal.adsp.sub.org (Hans-Joachim Widmaier)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: How should I learn C?
Date: 29 Dec 92 20:23:43 GMT
Organization: Not an Organization
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith

In article <rlcarr.09er@animato.network23.com> rlcarr@animato.network23.com (Rich Carreiro) writes:
>
> Isn't C older than Pascal?  In any case, get a copy of Brian Kernighan's classic
> _Why Pascal Is Not My Favorite Programming Language_ (or some similar title).
> It's available somewhere; it was posted to alt.folklore.computers a month or
> so ago.  It's a wonderful point-by-point listing of the serious things that
> are wrong with Pascal.

I'm reading this group since july, but can't remember this post. I _really_
would like to read that ...
Could it probably be emailed?

jbhr
--
Hans-Joachim Widmaier | no fancy sig. sigh. | jbhr@sofal.adsp.sub.org
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
From: jbickers@templar.actrix.gen.nz (John Bickers)
Date: 31 Dec 92 20:36:41 PST
 <jbickers.0mbe@templar.actrix.gen.nz> <1992Dec30.120123.22379@mpifr-bonn.mpg.de>
Organization: TAP

Quoted from <1992Dec30.120123.22379@mpifr-bonn.mpg.de> by mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst):
> In <jbickers.0mbe@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:

> >    Also, it's been deleted from the thread, but we have been talking
> >    about CPU-driven operations.
> 
> Do we ? With all the side reference to the TMS processor ?

    I didn't talk about either the Blitter or any other sort of
    processor, though as far as I know high end graphics boards do go
    for chunky pixels rather than planes. Or did back when I could
    afford to read about that sort of thing. :)

    I specifically said using the CPU to draw lines and curves and so
    on. Discussions about special graphics chips are meaningless here,
    because if you throw enough hardware at the problem, both
    approaches tend towards zero-time results.

    Personally, I have come across several things that I would like to
    do, but which having planes makes slower and/or more painful. Some
    more examples (besides flood fills and the other stuff already
    discussed) are digital dissolves, circular wipes, CPU-driven blits
    between areas that are not aligned the same, clipping to unaligned
    boundaries, and doing things in vertical strips that aren't
    aligned to byte boundaries.

    The biggest problems are having to split chunky data into planes,
    having to shift data, and having to take care not to disturb data
    to either side of pixels (the left-and-right masking I mentioned
    before, which you said was a zero time operation).

    There are similar things you can point out that planes are better
    at than chunky pixels, most of which revolve around being able to
    manipulate the plane pointers independently, doing different
    things in different planes (like stars in one, text in another),
    or doing convenient things with masks and a Blitter.

    A demo that could do vectors in chunky pixel mode and a scroll
    text in planar mode at the bottom of the screen would be nice.

> Michael van Elst
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
Newsgroups: comp.sys.amiga.programmer
From: robart@agora.rain.com (Joe Bob)
Subject: Re: AmigaDOS library functions and ANSI-C programming
Organization: a gora
Date: Thu, 31 Dec 1992 03:56:31 GMT

In article <1hrqupINNipe@aurora.unice.fr> beust@aurora.unice.fr (Cedric Beust) writes:
>
>	I was reading the autodoc for AddHead which looks like
>	AddHead(struct List *list, struct Node *node)
>	and I was wondering if a copy of the node would be done and then
>	pointed to in the list or if *my* node would be directly referenced.


  AddHead has to modify your node in order to add it to the list.
And it can't in general use a copy of the node since it does't
know how big it is.  The node could be a Task, a Message, an IORequest,
a Font, or just about anything.

Xref: sparky comp.sys.amiga.programmer:17680 comp.sys.amiga.datacomm:8316
From: bloc1469@ee.uwm.edu (Gregory R Block)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.datacomm
Subject: Compiling DNet with SysVr4 patches...
Date: 22 Dec 1992 06:02:44 GMT
Organization: University of Wisconsin, Milwaukee
Distribution: world
NNTP-Posting-Host: 129.89.2.33
Keywords: DNet, Unix, SysV

Has anyone been able to get the SysVr4 patches to work with DNet?
They refuse to apply, it seems, correctly.  I'd be grateful if someone
could apply the patches in #ifdef manner and manage to put it out for
FTP somewhere.

Greg

--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
(:   "Commodore has never proven to me, to my satisfaction, that      :)
(:    Marc Barrett is still alive."			       -Wubba :)
(: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
From: ba178@cleveland.Freenet.Edu (Gal-On Broner)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AMOS - is it any good?
Date: 1 Jan 1993 19:11:22 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: ba178@cleveland.Freenet.Edu (Gal-On Broner)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, crystal@glia.biostr.washington.edu (Crystal) says:

>In <19921231.044901.425@almaden.ibm.com> simonart@vnet.ibm.com writes:
>
>>In <crystal.725777678@glia> Crystal writes:
>>> I've been told that AMOS is some sort  of "easy to program" language
>>> and that demos and "real" programs can be created with it.
>

  There is a PD magazine avaible for the language on ux1.cso.uiuc.edu
(128.174.5.59) in /amiga/amoner and nic.funet.fi (128.214.6.100)
in /pub/amiga/programming/amos. You don't need amos itself to
run it. Just plug into DF0: and enjoy!

There's hope!  :>
>
>

-- 
  Gal-on Broner  -  ba178@cleveland.Freenet.edu     //
                                                   //
  Amos - A language beyond imagination          \\//
                                                 \/
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 21 Dec 92 10:30:10 GMT
Organization: Max-Planck-Institut f"ur Radioastronomie

In <Jesse_Michael.02qy@matrix.rain.com> Jesse_Michael@matrix.rain.com (Jesse Michael) writes:
>I think they should release hardware references in the future, *but* they
>must provide a good example of how to *really* use the hardware.  Not like
>the examples in the old hardware reference manuals.  (e.g. absolute
>addressing)

They'd have to organize world wide programming courses for the demo coders.
And they'll still fail as some egocentrics will never take an advice.

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: walker@twix.unx.sas.com (Doug Walker)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: parnet network
Date: 29 Dec 92 19:06:52 GMT
Distribution: comp
Organization: SAS Institute Inc.
Originator: walker@twix.unx.sas.com


In article <199226.4249.20791@dosgate>, "david wyand" <david.wyand@canrem.com> writes:
|> More specifically, I am using an A2500/020 as the local machine, and an
|> A3000T as the remote, which has a 240Meg hard drive.  When I access the
|> Workbench partition on the tower, no problems, I am able to get a
|> directory and access files.  But as soon as I try to access the Work
|> partition, the system crashes after the first directory call.

Which system crashes, the A3000T or the A2500/20?

What versions of the OS are the machines running?  Are they both running
2.1?

|> The Software Error window displays the task as 'Work' (Work is displayed
|> in the upper left of the window, but not as the window's title).  Does
|> this mean that ParNet is having a problem with the drive itself?  Has
|> anyone had problems with WB2.1, and a large hard drive (which is
|> relativly fast) and ParNet?  Is it possible that the data stream is
|> overflowing into areas that it shouldn't due to the fact that ParNet
|> can't keep up with the speed of the drive (I'm assuming that the network
|> is slower than my hard drive, of course)?

No way.  The way DOS packets work, Parnet hands the packet to the
file system and waits for a reply.  There is nothing asynchronous
about it.  Faster drives just reply faster, that's all.

I don't know what's happening here, but the OS version could have
something to do with it.  2.1 obviously wasn't available when I
shipped the initial parnet (actually 2.0 wasn't either) so 
anything could be happening... but I would be surprised if that
were so, since all the old packets worked the same way as in 1.3.

|>                                          david.wyand@canrem.com
-- 
  *****
=*|_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: ry53@rz.uni-karlsruhe.de (Angela Schmidt)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 22 Dec 1992 16:36:29 GMT
Organization: Nessyhoehle@I501.NessyNet.de
Distribution: world
Reply-To: Angela@rz.uni-karlsruhe.de
NNTP-Posting-Host: tp70.rz.uni-karlsruhe.de

In article <1992Dec22.143308.26492@rzu-news.unizh.ch>, cschneid@amiga.physik.unizh.ch (Christian Schneider) writes:
> Angela Schmidt (ry53@rz.uni-karlsruhe.de) wrote:
> > or not. TypeOfMem() only works with RAM, but some of the entries in
> > the fssm can be in ROM or even in the expansion space as well. So
> 
> But a valid fssm is always in ram, wrong?

I'm not sure. Maybe, the four trackdisk devices may have their fssm in
ROM. But normally, the fssm is allocated by Mount and so in RAM.

> I'm currently using TypeOfMem() for dn_Startup only, I don't think
> this should miss some devices.

Maybe you will miss DF0:, DF1:, DF2: or DF3: in future... But what do
you think about the following checks:
  - (dn_Startup<<2)>=1024
  - AllocAbs ((dn_Startup<<2), x) MUST fail

> > for now, I assume that non-zero-values mean that there is a valid
> > fssm. I tried TypeOfMem() but I really missed some devices after that,
> 
> This is rather dangerous. No enforcer hits?

No enforcer hits und no nonstandard dn_Startup. I think if a program
like DiskCopy crashes with these device, I may crash too, if there is no
good way to avoid crashing. Flames to /dev/nil.

> > because their device name (and I think the environment vector, too)
> > was in ROM.

> Which devices did you miss? But fssm itself was in ram?

DF0:, DF1:, DF2: and DF3:. I'm not sure, but I think it was using
KS 1.3. But maybe I'm wrong and was OS 2.04. But the fssm was in RAM.

I will be away until 10-Jan-92. So don't wonder why I don't answer...


     V v
  @/@@=\    Merry Christmas and a Happy New Year,
    00 &=-      Angela 
oOoO_/` \\_
    \ /&\   Angela Schmidt cand. inf. (Nessy@IRC) | Amiga //
  |>O<|         EMail: Angela@rz.uni-karlsruhe.de | 1000 // 
   / \_/\/\/v,  Weekend: +49 731 712316 (9am-9pm) |  \\ // since 
  /___________\ Weekdays: 721 6904263 (10am-11pm) |   \X/ 1986 
Newsgroups: comp.sys.amiga.programmer
From: jamiller@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: SAS 6.* Unicode (JIS, etc.) supported?
Date: 2 Jan 93 02:30:23 CST
Organization: University of Kansas Academic Computing Services

Does SAS 6.* support 16-bit Unicodes like JIS (Japanese 2-byte ascii)?
-- 
jamiller@kuhub.cc.ukans.edu
James Miller

_chicchai .sig no ho ga ichiban iin janai ka..._
             Enlightenment Happens?
From: walker@twix.unx.sas.com (Doug Walker)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SAS/C 6.1 math=68881 BUG
Date: 21 Dec 92 14:41:49 GMT
Organization: SAS Institute Inc.
Originator: walker@twix.unx.sas.com


In article <rlcarr.0969@animato.network23.com>, rlcarr@animato.network23.com (Rich Carreiro) writes:
|> 
|> Has anyone else been bitten by this weird one?  I have reported it via
|> EMITS.  Haven't heard anything yet.
|> 

MATH=68881 is broken under 6.1.  Please use other math options until
a fix can be produced.

-- 
  *****
=*|_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: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: Tue, 29 Dec 92 12:35:23 PST
Organization: The Portal System (TM)
  <1992Dec22.143308.26492@rzu-news.unizh.ch>
  <1992Dec23.052714.25037@mail.cornell.edu> <38162@cbmvax.commodore.com>

So give us an "Official" way to walk the device list that is compatible
with 1.3 thru 3.0 that will kick out the "strange" things and keep only
the valid devices (like DF0:, any DH0:, ect...).  One of the reasons
I checked for specific device names(like Pipe:) was because of the 
"strange" things....