HDTenEightyP/NetNews huggingface dataset:
From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: C Programmer's Editor of Choice?
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Wed, 22 Jul 1992 23:29:34 GMT

In <14js9gINN8m5@matt.ksu.ksu.edu> strat@matt.ksu.ksu.edu (Steve Davis) writes:
>I'm going to have to chip in with a word for GNU-EMACS, the ONE
>TRUE EDITOR.  Something has to be said for EMACS, since it can
>*emulate* through ELisp any other text editor.  And what's even
>better is that it's MACHINE INDEPENDENT!  :-)  I'm using EMACS
>right now on an 80 MIPS UNIX box, have it for my laptop, for my
>Amigas, etc. etc. etc.  

Hmm, I can imagine that it runs fine on an 80 MIPS UNIX box.. but
on a Laptop ?

Emacs opponents unite :-) There must be something better than
Eight Megabytes And Continously Swapping editors.. :-)

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: bj@cbmvax.commodore.com (Brian Jackson - Amiga Networking)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: C Programmer's Editor of Choice?
Date: 21 Jul 92 17:57:59 GMT
Reply-To: bj@cbmvax.commodore.com (Brian Jackson - Amiga Networking)
Organization: Commodore, West Chester, PA

In article <14fneaINN75v@darkstar.UCSC.EDU> jonathan@cats.ucsc.edu (Jonathan Cano) writes:
>Another excellent option is QED, a shareware editor by Darren M. Greenwald
>(who is a programmer at C= ).  QED amazing! 

Highly recommended. It's been my editor of choice for years now. Truly
nice. Another thing that should be mentioned is that all the code in QED is
'legal'.  I have yet to have it give me -any- trouble on any revision of
the OS that I've had here (and I get many :)).  Solid as a rock. Also, it
has an arexx learn mode whereby you can record a series of actions and then
QED will write an -arexx script- for you that will repeat the list. Nice. 

>| Jonathan Cano             |     //   _   |
>| jonathan@cats.ucsc.edu    | \\ //   (_)  |

Brian
       +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
       Brian Jackson    Amiga Networking Group, Commodore-Amiga Inc.
                        bj@cbmvax.commodore.com
     {uunet|rutgers}!cbmvax!bj    or   networking@cbmvax.commodore.com
 "Oh, so you have a Borg named Hugh."           Uva uvam vivendo varia fit
From: jdp@caleb.UUCP (Jim Pritchett)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: MUNGWALL 37.54 uploaded
Date: 29 Jul 92 00:28:24 GMT
Organization: is sometimes desirable

Has anyone made the above program available for bms?

                                                Jim Pritchett


UUCP:  rwsys.lonestar.org!caleb!jdp
 or    utacfd.uta.edu!rwsys!caleb!jdp
Newsgroups: comp.sys.amiga.programmer
From: chymes@uri.csmil.umich.edu (Charles Hymes)
Subject: Impulse FORM TDDD is crummy. was: IFF 3D standard? (DR3D?)
Date: Tue, 21 Jul 92 12:45:04 EDT
Organization: Cognitive Science and Machine Intelligence Lab, U. of MIichigan
Keywords: n


Impulse's FORM TDDD is a crummy IFF is I heartily incourage is
upgrading. My promlem with it is that while it is a LEAGL IFF it is a
NON-STANDARD IFF. It is non-standard to the point that
parseiff.library is won't read any of its chunks. The problem is that
it has sub-chunks and sub-sub chunks, without any of the encapulating
FORMs LISTs or PROPs. TDDD's look like this:
FORM TDDD
	OBJ
		DESC
			PNTS
			EDGE
			FACE
			...
		TERM
	...

When it should look like this:

LIST TDDD
	FORM OBJ
		FORM DESC
			PNTS
			EDGE
			FACE
			...
		TERM			
	....

The problem is that IFFParse.library never enters the contents of a
chunk. So to it, (and any other IFF reader that is not TDDD specific)
a TDDD is only made of one large OBJ chunk, which it will never parse
again. If the TDDD form was standard, iffparse could decend into each
sub chunk, and retreve the ones wanted ones, perserving context and
all that jazz. To parse TDDDs, one has to treat OBJ chunks and DESC chunks as
seperate, *NON STANDARD* IFF files, and parse each seperately. This is
what I have done. I wrote a TDDD reader that reads uses Iffparse to
get each OBJ chunk, copys the chunk to a buffer and prefixes "FORM
TDDD" and the size to each OBJ, calls iffparse on each (now-legal) OBJ
chunk, gets each DESC sub-chunk, prefixes "FORM TDDD" and the size to
each DESC chunk, and finally one can then get at the data for the 3d
objects. Yuck. 

One could argue that the problem is with Iffparse, but this is not the
case. A standard IFF should expicitly state which chunks are
sub-chunks, and not expect the parser to look inside each chunk and
guess that it is a sub-chunk becuse the first four bytes happen to be
upper case ASCII. That is what FORM LIST, and PROP chunks are for.

Charweed Hymerfan
From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Printing the device list -- what am I doing wrong?
Date: 29 Jul 92 15:08:44 GMT
Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Organization: Commodore Germany

In article <51071@dime.cs.umass.edu> barrett@gleep.cs.umass.edu (Daniel Barrett) writes:
 >
 >	I'm trying to print the list of volumes under 2.04.  The following
 >program gives me a recoverable alert 01000008.  What am I doing wrong?

Try to handle the strings as BSTR! Take the first byte as length and then
only copy so many bytes to output. You can't rely on null terminated
strings here, as you do implicitly when using standard C routines.

 >	The device names DO get printed, but they appear with extra
 >spaces in front of them, or backspace characters.  Weird.

I guess these are the length bytes :-)

 >		name = BADDR(dlist->dol_Name);
 >
 >		if (name)
 >		{
 >			FPuts(Output(), name);

This is the bug. First fetch the first byte as length and then fetch these
n bytes.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
				   or  peterk@public.sub.org
Newsgroups: comp.sys.amiga.programmer
From: stark@wam.umd.edu (Mike Stark)
Subject: Re: ASL and GadTools libraries.
Organization: University of Maryland, College Park
Date: Tue, 28 Jul 1992 17:25:22 GMT

In article <33732@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes:
> In article <1992Jul27.191144.25772@wam.umd.edu> I write:
>> I wish the autodocs said this was OK because I really want to let the user
>> of my program close windows while the ASL requester is active.
>
> The autodocs WON'T say it's OK because it's NOT.  If you want to close
> the window while the requester is active, then don't pass your window
> in as a reference window.  It's pretty simple.

Well, I think you misunderstood me a little bit.  I realize that what I
am doing is not a good idea.  However, I have a program that has several
windows open on one IDCMP one of which may be the ASL file requester.  I
wanted to have one process service all of these windows and I thought that
the ASL hook function provided a way to do that while the ASL requester was
alive.  Unfortunately, it is clear from the documentation (And now painfully 
clear that the documentation represents not only the fact but also the 
intent of C/A) that I will have to fork off another process just to open 
up the ASL requester.

Darn.  I was just hoping that it wasn't so.


-- 
---Mike Stark                         | stark@umdhep.umd.edu
   Physics Department
   University of Maryland
   College Park, MD  20742
From: strat@matt.ksu.ksu.edu (Steve Davis)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: C Programmer's Editor of Choice?
Date: 23 Jul 92 14:56:16 GMT
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

jprad@faatcrl.UUCP (Jack Radigan) writes:

|>strat@matt.ksu.ksu.edu (Steve Davis) writes:

|>>I'm going to have to chip in with a word for GNU-EMACS, the ONE
|>>TRUE EDITOR.  Something has to be said for EMACS, since it can
|>>*emulate* through ELisp any other text editor.  And what's even
|>>better is that it's MACHINE INDEPENDENT!  :-)  I'm using EMACS
|>>right now on an 80 MIPS UNIX box, have it for my laptop, for my
|>>Amigas, etc. etc. etc.  

|>  MicroEmacs is my fallback editor for the PeeCee and Amiga here as well
|>as a dialup UNIX account that I have.

|>  It still doesn't have undo/redo though.  And, it's memory management is
|>rather slow as well...

I'm not talking about Micro EMACS, I'm talking about the *ONE TRUE
EDITOR*, GNU Emacs.  I agree that Emacs is a little slow with
memory management.  But my development machine is an A3000, so that
isn't a problem.  I wouldn't suggest running it on anything slower
than a 12Mhz '020, however.  That I do run it on my 7Mhz BBS
computer is amazing...

The only thing that the Amiga port of GNU emacs really needs is
Workbench supported cut-and-paste.  But, for that matter, the X
implementation of EMACS doesn't use X cut-and-paste either!  :-(

Stratocaster
-- 
  Steve Davis  |    Contact me at ...            | The Boarding House BBS!
               | Internet:  strat@cis.ksu.edu    | 9600 baud (v.32/v.42)
               | FidoNet:    Steve @ 1:295/3     | America: 913-827-0744
           ********** Have you hugged your Amiga today? **********
Newsgroups: comp.sys.amiga.programmer
From: walrus@wam.umd.edu (Udo K Schuermann)
Subject: Re: IFF 3D standard? (DR3D?)
Organization: University of Maryland, College Park
Date: Tue, 21 Jul 1992 05:50:17 GMT

In article <1992Jul21.135437.1@economics.adelaide.edu.au> djung@economics.adelaide.edu.au writes:
>Is there an IFF standard for 3D data?
>
>I want to represent the geometry of a 3D world, along with alot of information
>concerning surface properties (alot of physical values).  Also light sources.
>If not, I may create one, otherwise I may have to embelish one.

Impulse registered the FORM TDDD ("Three Dimensional Data Description") and
it appears in the new Devices RKM.  The format is basically tailored to
store information pertinent to the Turbo Silver and Imagine rendering
software, but since it is IFF you could add your own (inofficial) chunks to
the file and keep it compatible with an existing standard.  Exactly what IFF
was created for.  Not only that, but you would be able to draw on a store of
existing 3D objects, and your own efforts might be usable in Imagine, too!

The TDDD.doc is 11 pages long, so I can't give you much information about
it.  Suffice to say that it describes the geometry of a 3D world (objects
especially) using points to build edges, and from these construct
triangular faces.  Attribute information includes color, reflectivity,
transparency, and several others.  I'm sure that extending these wouldn't
be difficult.
	Your best bet might be to get the RKM:Devices (ISBN 0-201-56775-X)
published by Addison-Wesley (#56775)

 ._.  Udo Schuermann     "If I went around calling myself emperor just because
 ( )  walrus@wam.umd.edu  some moistened bint lobbed a scimitar at me, they'd
 Seeking virtual memory   put me away!"         -- Monty Python's "Holy Grail"
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@spckll.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Hey Commodore types
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Thu, 23 Jul 1992 20:28:33 GMT

In <mwm.1ah3@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
>In <1992Jul23.103350.14923@mpifr-bonn.mpg.de>, mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) wrote:
>> Under K&R C every integer parameter was pushed as a LONG onto the stack
>> anyway.

>It's INT, not long, that's pushed if the compiler doesn't have a known
>type. Unless the type of the pushed object is larger than a long; for
>instance, a pointer when you are compiling with 16-bit ints.

Sorry, Mike is of course right, chars and shorts are promoted to int.
But 32bit ints are used most often so that it still matches the
arguments that the stub routines await.

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: mykes@amiga0.SF-Bay.ORG (Mike Schwartz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: C Programmer's Editor of Choice?
Distribution: world
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith
Date: 23 Jul 92 14:47:07 PST
Organization: Amiga makes it possible

In article <sraboel.00n6@srabol.adsp.sub.org> sraboel@srabol.adsp.sub.org (Steen Raboel (ECD 019)) writes:
> > Check out the TurboText demo on the fish disks (in the 400's).  Once you
> > try it, you will buy it :)
>
> I've checked it, but can't find a place to buy it ;-((
>
> Does anyone have a name and a FAX # ??
>
> > Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)
>

I don't work for Oxxi, never did, and likely never will :)  So this is
not an advertisement of any kind.

Oxxi Inc.
P.O. Box 90309
Long Beach, CA 90809-0309
USA

voice: 213-427-1227
fax: 213-427-0971

> --
>
>   /-----------------------------------------------------------------------\
>   | Steen Raboel                 UUCP: cbmehq!cbmden!srabol!sraboel       |
>   |                       _      FIDO: 2:231/138.0 Or 2:230/311.13        |
>   |                       \\ _                                            |
>   |               Interacti\X/ision - The Name Of Precision               |
>   \-----------------------------------------------------------------------/

--
Amiga programmer of: GRn, MailMinder, Budokan, Beyond Dark Castle, Dark Castle
Sega Genesis programmer of: Dick Tracy and Marble Madness.
Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)
1124 Fremont Ave.
Los Altos, CA 94024
From: beust@rhea.inria.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: Help with Boopsi and sysiclass please
Date: 21 Jul 92 07:55:56 GMT
Organization: University of Nice Sophia-Antipolis, France


	I need to change the System Gadgets imageries, so that the
	change takes effect on any already open windows and also on
	windows to come.

	Obivously, doing a SetAttrs() on a system gadget got by
	NewObject with a new image isn't enough. Any idea?


+------------------------------------------------------------------------+
| Cedric BEUST                                     University of Nice    |
| INET: beust@avahi.inria.fr                       $whoami               |
| UUCP: llaor.unice.fr!arkonis!beust               god (personal alias)  |
|    //      -- "To be, or not to be...",                                |
| \\// Only    That is illogical, captain!         f U cn rd dis         |
|  \/ Amiga!                 -- Spock              U mst uz Unix         |
+------------------------------------------------------------------------+
Newsgroups: comp.sys.amiga.programmer
From: davids@netcom.com (Dave Schreiber)
Subject: Going from volume lock to device name
Date: Tue, 28 Jul 92 06:16:36 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

Can anyone tell me how to get a device name, given a lock on the volume
that the device is associated with.  I'm writing a program that takes
as input locks (to disks) from Workbench, and need to go to the appropriate
device name ("DF0:", "WB_2.X:", etc). 

I tried doing something like this already:

{
for(all disk devices in system)
{
   lock=Lock(devicename,ACCESS_READ);
   if(SameLock(lock,volumelock)==LOCK_SAME)
      unlock lock;
      return device name
   else
      unlock lock;
}

return error;
}

But this caused Workbench to become unstable (dragging an icon into a 
floppy disk's trashcan froze Workbench), even with all the appropriate
checking of return values, etc.  Could this be a bug in Workbench, or
am I missing something (Kickstart V37.175, Workbench V37.67)?

Thanks.


-- 
Dave Schreiber/davids@netcom.com (until 9/15/92)/"Ask, don't touch"
Newsgroups: comp.sys.amiga.programmer
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Subject: Re: Question about AllocDosObject()
Keywords: AllocDosObject directorys filesystem
Organization: Jet Propulsion Laboratory
Date: Fri, 31 Jul 1992 17:09:06 GMT

In article <5415@dsacg3.dsac.dla.mil> nfs1675@dsacg3.dsac.dla.mil (Michael S Figg) writes:
>
>
>
>Can anybody give me a simple explanation of 'AllocDosObject()'. From the
>autodocs it looks like it is used to create a new DOS object, but the ExAll()
>or Examine() function (I don't remember which) seems to indicate that it is
>needed to look at any existing directory. Does AllocDosObject() identify 
>a directory in the file system as a DOS object temporarily? An example would
>be great.       
>
>Thanks, Mike
>
>-- 
>Perl doesn't mind a little pluralism-a perl   | Michael Figg  DSAC-FSD
>script is correct if it's halfway readable    | DLA Systems Automation Center
>and gets the job done before your boss fires  | Cols, Ohio mfigg@dsac.dla.mil
>you. -- Wall and Schwartz ("Programming Perl")| CIS: 73777,360    

AllocDosObject is currently no different than AllocMem. I asked about this a
while ago, because I was interested in performing ExAll from tasks. Tasks can-
not use the DOS library of which AllocDosObject is a part. However, tasks can
simulate the operation by sending an ACTION_EXAMINE_ALL DOS packet. I'm not
sure where this issue stands now. 

jeff
From: peter@cbmvax.commodore.com (Peter Cherna)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: PGA_NewLook is nowhere to be found!
Keywords: PGA_NewLook
Date: 22 Jul 92 13:56:54 GMT
Reply-To: peter@cbmvax.commodore.com (Peter Cherna)
Organization: Commodore-Amiga, Inc.  West Chester, PA.

In article <12866@chalmers.se> d0per@dtek.chalmers.se (Martin Hiller) writes:
>I have a little problem: my compiler (SAS/C 5.10a) doesn't seem to 
>recognize the PGA_NewLook tag, all I get is 'undefined identifier'.

#define PGA_NewLook     (PGA_Dummy + 0x000A)

>- Martin.

     Peter
--
Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
"No guts, no glory."
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@spckll.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: C Programmer's Editor of Choice?
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Thu, 23 Jul 1992 20:21:19 GMT

In <14mhjjINNfos@matt.ksu.ksu.edu> strat@matt.ksu.ksu.edu (Steve Davis) writes:
>1.System2.0> eval 166852 - 1075888
>592264
>1.System2.0>

>Nope!  Only half a meg!  ;-)

Then load some cute macros that are the only reason to _have_ such a
big editor. I'd suggest to load some language support mode or GNUs :-)

BTW, my vi clone needs about 65k.

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."
Newsgroups: comp.sys.amiga.programmer
From: philipm@cs.kuleuven.ac.be (Philip Marivoet)
Subject: Re: Standard 2.0 File Requester Question
Organization: Dept. Computerwetenschappen
Date: Wed, 22 Jul 1992 08:20:21 GMT

I don't have an idea why ASL may be slow but take a look at ReqTools.
This requester package is a MUST for every programmer who uses 
requesters. They are easy to use (for the programmer and for the user),
VERY powerful (I especially like the feature where you can use the arrow
keys to select a file) and style guide conformant under 1.3 and 2.0
ReqTools can be found on amiga.physik.unizh.ch

-Ives
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Command execution speed tablew wanted.
Date: 30 Jul 92 10:50:00 PST
Organization: TAP, NZAmigaUG

Quoted from <1992Jul29.102039.57606@cc.usu.edu> by slmt9@cc.usu.edu (Joshua Dinerstein):

> 	I am looking for something like a table of command execution speeds
> for the assembly language commands. Does a table like this even exist?

    Assembler books tend to have them. I use a thing called "68000
    Assembly Language", by Krantz & Stanley, which has a set of tables
    in the back, "Courtesy of Motorola Inc.". That last bit implies
    that these tables are the same as the ones you've already got. If
    so, they are quite easy to figure out.

    Note that these tables have little relationship to 68030 CPUs, cf
    the "CPU Cycles" thread.

> 	Joshua
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
Newsgroups: comp.sys.amiga.programmer
From: epang@fraser.sfu.ca (Eugene Pang)
Subject: Re: Checking SetPatch version...
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 27 Jul 1992 03:09:14 GMT

tna@mentor.cc.purdue.edu (Trevor Andrews) writes:
>What is the correct way of checking SetPatch's version from within
>a program?

Uh...
  long ver=0,rev=0;

  system("version >env:setpatch.ver c:setpatch"); /* on 2.04+ */
  sscanf(getenv("setpatch.ver"), "%ld.%ld", &ver, &rev);
  
>I beleive some SetPatchs open a port... Is this true of
>all of them?  Can it be checked through its port?

Yeah...they open a port ("SetPatch Port").  But since there's no task,
there's also no task attached to the port.  Makes it kind of hard to inquire
the version/revision through the port...
Newsgroups: comp.sys.amiga.programmer
From: abrams@r-node.gts.org (Wayne Abrams)
Subject: designing a user interface
Summary: listview under AmigaDos 1.3
Organization: R-node Public Access UNIX System (416-636-2026) 24hrs.
Date: Tue, 28 Jul 1992 05:24:47 GMT


Salut tout le monde. I'm writing an application under AmigaDos 1.3 and I want
to add to it's functionality by using scrolling list gadgets. Now though there
is an OS sanctioned way to do this under OS 2.0, I don't have OS 2.0. Can
anyone direct me to either a code fragment, or a library that impliments this
--