[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:AMIGA NOTES
Notice:Join us in the *NEW* conference - HYDRA::AMIGA_V2
Moderator:HYDRA::MOORE
Created:Sat Apr 26 1986
Last Modified:Wed Feb 05 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:5378
Total number of notes:38326

781.0. "Corrections to Peck's book?" by CIMNET::KYZIVAT (Paul Kyzivat) Tue Oct 06 1987 16:38

The message below mentions corrections to Peck's book.  Does anyone have them
available to post here?  Also, is there a convenient source for the Autodocs?

	Paul

Newsgroups: comp.sys.amiga
Path: decwrl!labrea!rocky!ali
Subject: Re: A "C" of ignorance
Posted: 18 Sep 87 15:28:37 GMT
Organization: Stanford University Computer Science Department
 
In article <7200010@uiucdcsm> [email protected] writes:
> ...  What books do you consider vital to programming the Amiga? ...
 
For programming purposes, there are three sources I use:
 
(1) The three RKMs: "Libraries and Devices,"  "Exec,"  &  "Intuition."
    For a total of about $90, these three books provide you with plenty
    of examples, code, and a full list of all the system functions.
    Unfortunately there are some errors (although much less than the
    errors in the first set of RKMs, which I also had...) And I don't
    think RKMs have all the functions listed (like the newest 1.2
    functions --- DrawEllipse and such).
(2) "Autodocs"  --- These are Unix man-style descriptions of all the
    functions in 1.2 (including DrawEllipse and such). As far as I can
    tell, they are not buggy. To look at them, consult your local Amiga
    developer --- They are available on disk, not in print.
(3) Rob Peck's "Programming Guide to the Amiga." It's the kind of book you
    can sit down and read. Gives a good solid background 
    to programming the Amiga and why you need to do the things you do
    when programming. 
 
None of these books give info about DOS commands and such. They are useful if
you want to program the Amiga. You can start programming the machine if
you get a hold of (2) and (3), but for more serious work I think you need
all three of the above. 
 
[BTW, Peck's book also has some errors but he kindly posted a list of
 corrections a while back. If you get the book, drop me a note and I can
 mail you the corrections.]
 
Ali Ozer, [email protected]
T.RTitleUserPersonal
Name
DateLines
781.1BAGELS::BRANNONDave BrannonTue Oct 06 1987 19:09158
Newsgroups: comp.sys.amiga
Path: decwrl!pyramid!amdahl!dlb!dana!rap
Subject: Re: Programmers Guide To The Amiga, Errata
Posted: 13 Apr 87 18:43:59 GMT
Organization: Dana Computer, Inc., Sunnyvale, CA
 
 
Errata for Programmers' Guide To The Amiga, by Rob Peck, first printing
=======================================================================
 
Listing 2.6, mycdir.c 
 
	This is a do-nothing program that somehow got munged with
	portions of a program I posted to Usenet called fastdir.c.
	To make mycdir.c do "what it says it does" in the book, 
	simply delete the following lines:
 
	  extern struct FileHandle *Open();
	
	  struct FileHandle *myfile;
 
	  /* close the file */
	  Close(myfile);
 
	And delete ALL lines between:	
		/* open a file and thereby...
	and the line that says:		
		/* file via the handle */
 
	Change the last comment to read:
 
	/* and cleanup by unlocking any lock obtained from Lock().
	   Note: do NOT UnLock any lock obtained from CurrentDir.
		 This can make AmigaDOS forget that the disk exists
		 in the system.  Only locks obtained from Lock()
		 or DupLock() should be UnLock()'ed.
	*/
	
-----------------------
Listing 2.8, opta.c
 
	The book says "lists the CURRENT directory, just like 'dir opt a'"
 
	Replace the section:
 
		 main(argc,argv)
		 {
			(ALL of this part)
		 }
 
	with:
		main()
		{
			struct FileLock *oldlock;
			oldlock = Lock("",ACCESS_READ);
			if(oldlock != 0)
			{
				followthread(oldlock,0);
			}
			else
			{
				printf("cannot lock CURRENT dir\n");
			}
			printf("\n");
		}
 
	On page 35, listing 2.8, the line:
 
			printf(&m->fib_FileName[0]);
 
	should really be:
 
			printf("%ls", &m->fib_FileName[0]);
 
	But it works as originally written, though, because printf
	is looking at the filename area as though it is a format
	string.  So the absence of the %ls does not matter anyway.
	For a cleaner look with fewer questions, you might want
	to change it as shown here.
-------------------------
Listing 2.9
 
	is missing an underscore in the second to last line on the 
	bottom of page 35:
 
		printf("%ls",myinfo->fib_FileName[0]);
					^
					|_____ this is what got missed.
 
-------------------------
Listing 2.10
 
	I misinterpreted Mr.Rokiki's first name.  It is Tom, not Thomas.
 
	Also, when compiling with Aztec C, certain type declarations
	and casts must 	be made.  In Showdate, add the declaration lines:
 
		long n;
		int m,d,y;
 
	and the line that says: n -= 1461 * y/4;
	should read:            n -= 1461 * (long)y/4;
 
	This fix, instead of breaking in the year 2006, is good till 2100.
	Thanks, Tom, for the fixes.
-------------------------
Page 60, mid-page:  Setting a Signal Bit Directly.
 
	There are three references in this paragraph to SetSignal.
	ALL THREE should be changed to "Signal" rather than SetSignal.
	(Thanks to Carl Sassenrath, the creator of "Exec", for bringing
	 this to my attention)
 
------------------------
Page 295:  The audio program
 
	The final two sentences preceding listing 8.7 should be deleted.
	This example does NOT go directly to the hardware.
 
Page 296:  Listing 8.7
 
	An accidental duplication of three lines, and one of the
	duplicates is terribly munged.  If you simply remove
	the offending lines, that fixes the example.  The lines are:
 
	the FIRST time this
	line appears --->/* Create ports for replies from the device */
 
			 auReplyPort = CreatePort(0,0);
			 auLockPort  = CreatePoequest.io_Device;
						^
						|
						OUCH! what a mess.
 
---------------------------
 
There are a couple of instances where there are false leads
such as:
 
page 20... a reference to chapter 6 for more information
about the printer control codes (change the reference to 
"The Amiga ROM Kernel Manual ... has more information about
accessing the printer device directly.)
 
page 93 ... shows how to draw lines, circles, and boxes.  Delete
the reference to circles.  Most of the book was done with V1.1
and circles were not accessible in that earlier system code.
 
------------------------------
This set of errata is all I am aware of as of 4/12/87.  If you notice
anything more, please let me know.  
 
My address is DATAPATH, P.O. Box 1828, Los Gatos, Ca. 95031.
 
Thanks to all of you who have offered suggestions and corrections.
 
 
Rob Peck.		...hplabs!dana!rap
781.2BAGELS::BRANNONDave BrannonTue Oct 06 1987 22:022
    also see note 607.* for other problems with it and other books.
    
781.3Bug in the correctionsTLE::RMEYERSRandy MeyersTue Oct 06 1987 22:5724
Re: .1

>	/* and cleanup by unlocking any lock obtained from Lock().
>	   Note: do NOT UnLock any lock obtained from CurrentDir.
>		 This can make AmigaDOS forget that the disk exists
>		 in the system.  Only locks obtained from Lock()
>		 or DupLock() should be UnLock()'ed.
>	*/

This advice is wrong.  You SHOULD unlock any lock obtained from CurrentDir
unless you plan on putting it back into CurrentDir later.  If you don't
do this, you will leave extra locks around tying up memory and forcing
the filesystem to remember about the volume unnecessarily.  These extra
locks may prevent you from being able to delete a file for example:  AmigaDOS
believes that someone is still using the file.

A special case of this exists for Lattice users.  The Lattice startup
code carefully stores away the lock in CurrentDir when the program starts
and restores it to CurrentDir then the program exits.  If you unlock that
lock, Lattice will gleefully stuff a now unlocked lock into CurrentDir.
This will usually cause a task held requester or Guru the first time the
CLI running the program touches the file system.

So, unlock every lock except one you plan on using again.