ftp.mactech.com 2010/ftp.mactech.com.tar/ftp.mactech.com/csmpdigest/csmp-digest-v3-060

Text File | 2010-09-21 | 58KB | 1,647 lines

Received-Date: Thu, 22 Sep 1994 15:08:40 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-060
To: [e-mail]
Date: Thu, 22 Sep 1994 15:08:30 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 65

C.S.M.P. Digest             Thu, 22 Sep 94       Volume 3 : Issue 60

Today's Topics:

        Books to learn assembly language on Mac?
        FYI: Fun Bug with CustomGetFile
        How to call 68K lib from PPC code?
        PROBLEM: Serial Port Programming & PowerBooks
        Using CLUTs to simulate page flipping?
        Why is AppleScript type checking absent?
        [Q] _PBCatSearch vs Recursive Indexed _PBGetCatInfo



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Guang Mei)
Subject: Books to learn assembly language on Mac?
Date: Thu, 1 Sep 1994 01:23:43 GMT
Organization: Marine Biological Laboratory

Hi:

I need to learn assembly language on Mac and I cann't find any book(s) to
start with. Could any one recommend any good book(s) to read? I have no
assembly language programming experience before so the book should be for
beginners.

Please post your answer here or e-mail your response to  [e-mail]

Thanks.

--
- -----------
Guang Mei   [e-mail]     Tel:[phone] ext 374
Program of Architectural Dynamics in Living Cells
Marine Biological Laboratory, Woods Hole, MA 02543

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Fri, 2 Sep 1994 00:27:35 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Several options:

First, call your closest Motorola representative and have him send you a
catalog of their publications.

Then, check your local phone book - there's probably an ad for Ophamp
Technical Books in it, listing their 800 number.  Call and get their free
catalog.  You can then choose some appropriate books.  If their number
and ad are not there, call 1-800-555-1212, and get it from Information -
they are in Los Angeles.

Next, some books you may already have may have brief assembler info on
them (to read while waiting for a real book).  The MacsBug Reference and
Debugging Guide has 35 pages of assembler primer, and may also recommend
books.  Scott Knaster's "blue book" has some info on it.

Inside Mac has "Assembly Language notes" throughout.

Get an assembler programming environment and some example source and
start working with it.  Then when you get some books you can become more
adept at it.  You'd have to get an envronment anyway, regardless of
whether you got a book, if you want to program in assembler, so get that
part over with.  I don't know what's available for PPC's, but there are a
few 68k ones out there.  It may be too early to get into PPC assmbler
with ease.  Likely there are not many books on it, except from Motorola.

Does that help?

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Judy Ann Kettenhofen)
Date: 3 Sep 1994 01:04:28 GMT
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)

Guang Mei ([e-mail]) wrote:
: Hi:

: I need to learn assembly language on Mac and I cann't find any book(s) to

About 4-5 years ago I considered co-writing a book on 680x0 Asm.
I was informed that I'd have a hard time finding a publisher, because
asm books just weren't that much in demand.  A number of asm books
I own currently are out of print (these are 680x0), so it's difficult
to recommend a book that you will be able to find.

What are you trying to accomplish?  Are you attempting to write
a complete program in asm or do you just need to write a little
piece?

So....your learning tasks can be chunked like this:

1. Understanding, generally, about machine language, memory
addressing and so forth.
1.5 Become familiar with the major types of addressing modes
and cpu models (i.e., 680x0 uses a set of general purpose
registers; 80x86 has registers which must be used for specific
purposes.)

2. Become familiar with 680x0 instruction set & addressing modes.
Your task will be made immeasurably simpler if you start with
just the 68000 stuff.  With the advent of the 68020, Motorola
added several new addressing modes which have a variety of
permutations, such that the number of permutations is greater
than the number of 68000 addressing modes.

3. Learning specifically what it means to program in asm on
the Mac.  This means becoming familiar with the Macintosh
runtime model; e.g., jump tables, a5 offsets, loading segments,
etc.  The MPW Assembler, for instance, makes certain assumptions
which make it somewhat easier to program in asm on the Mac by
in essence hiding information from you, especially when it comes
to a5 offsets.

4. If you use the MPW Asm, there are possibly other idiosyn-
crasies with which you will want to become familiar. Most of
these can be found by looking at the various directives.  IN
particular, the MPW Asm will optimize your asm instructions to
equivalent faster instructions unless you explicitly tell it
not to.

Good Luck,

--Judy

PS Anyone use the "OPT SYNON" directive in the MPW Asm that was
put in in MPW 3.3?

--former MPW Asm hack.

: start with. Could any one recommend any good book(s) to read? I have no
: assembly language programming experience before so the book should be for
: beginners.

: Please post your answer here or e-mail your response to  [e-mail]

: Thanks.

: --
: -------------
: Guang Mei   [e-mail]     Tel:[phone] ext 374
: Program of Architectural Dynamics in Living Cells
: Marine Biological Laboratory, Woods Hole, MA 02543

+++++++++++++++++++++++++++

>From [e-mail] (Charles Bouldin)
Date: 4 Sep 1994 13:19:13 GMT
Organization: NIST

In article <[e-mail]>, [e-mail] (Ken Long) wrote:

> Several options:
>
> First, call your closest Motorola representative and have him send you a
> catalog of their publications.
>

Also, very old by now, but "The complete book of Macintosh assembly language"
by Dan Weston is quite complete. Probably out of print, but you might find
an old copy somewhere. ISBN # 0-673-18379-3 from Scott, Foresman and Co.

+++++++++++++++++++++++++++

>From [e-mail] (Judy Ann Kettenhofen)
Date: 4 Sep 1994 21:33:59 GMT
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)

Charles Bouldin ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail] (Ken Long) wrote:

: > Several options:
: >
: > First, call your closest Motorola representative and have him send you a
: > catalog of their publications.
: >

: Also, very old by now, but "The complete book of Macintosh assembly language"
: by Dan Weston is quite complete. Probably out of print, but you might find
: an old copy somewhere. ISBN # 0-673-18379-3 from Scott, Foresman and Co.

When Dan's book came out, it was definitely a great book.
However, there have been enough changes in programming the Mac
using his examples can now lead to frustration.  If it weren't
for that, I would recommend his book enthusiastically and without
hesitation. Incidentally, he also wrote a vol II of that book.

+++++++++++++++++++++++++++

>From [e-mail] (Bill Hofmann)
Date: Wed, 7 Sep 1994 15:37:36 GMT
Organization: Fresh Software


Personally, I'd do these things:
1. Buy a 68000 manual (note I said 68000, not 68020 or 68030 or 68040).
   Why? 68000 assembler is fairly simple, it gets hairier and hairier as
   you go on.
2. Buy a PowerPC manual (after all, it's a Mac).
3. Buy any CS textbook in assembler programming that looks relatively practical
4. Work through it.
5. Forget it all and use C or C++: it's much more portable, easier to learn,
   quicker to develop,etc.
6. When, after developing what you've developed, if there are sections that
   *really* need assembler (as opposed to a better algorithm), then you can
   code those sections in assembler.

I've done more than my share of assembler, and personally, I'd just as soon
beat my head against a brick wall.
--
Bill Hofmann                                   [e-mail]
Fresh Software and Instructional Design        voice: [phone]
1640 San Pablo Ave #C Berkeley CA 94702 USA    fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Pat Caudill)
Date: Thu, 8 Sep 94 03:57:21 GMT
Organization: Teleport - Portland's Public Access [phone]


You might ask at Powell's Bookstore (Technical books). They have a fairly
large technical section (it's got it's own building). Their catalog is on
line on the net. Send email to "[e-mail]" and
you will get accessing information. I dont work for them, just one of the
browsers there.

Pat Caudill

---------------------------

>From [e-mail] (Byron Han)
Subject: FYI: Fun Bug with CustomGetFile
Date: Tue, 6 Sep 1994 20:52:29 GMT
Organization: Institute for Astronomy, Hawaii

If you write a custom hook proc so that you can select a folder or an
alias (like ResEdit does) and you try to select an alias on the desktop,
standard file will munge your vRefNum/dirID returned in the sfFile
filsspec field...

Try selecting an alias on the desktop with ResEdit and you will see what
I mean.  Also writing a snippet of code to reproduce is trivial as well.

Solution is safe off the sfFile structure when sfOpenAlias is received
in your hookProc (and you transmogrify the item to sfOpenItem) and to
restore the sfFile structure at lastCall time...



+++++++++++++++++++++++++++

>From [e-mail] (Daniel Azuma)
Date: Wed, 07 Sep 1994 08:08:14 -0700
Organization: California Institute of Technology

[e-mail] (Byron Han) wrote:

> If you write a custom hook proc so that you can select a folder or an
> alias (like ResEdit does) and you try to select an alias on the desktop,
> standard file will munge your vRefNum/dirID returned in the sfFile
> filsspec field...

Yup, that one's been around for a while-- I first ran into it several
years ago, soon after System 7 came out. It happens only if you try to
select an ALIAS on the DESKTOP of a NON-STARTUP volume. (Selecting an
alias on the desktop of the startup volume works fine.)

What's going on is, the vRefNum/dirID ALWAYS specifies the desktop folder
on the startup volume in this case. To see this happen, create two aliases
with the same name on the desktop, one on the startup volume, and one on
another volume. Now try to use a program that supports opening aliases
(like ResEdit or FileTyper) to open the alias on the non-startup volume.
It will open the startup-volume alias instead.

One would think Apple could have fixed this by now. Geez.

Dan

- ----------------------------------------------------------------
  Daniel Azuma            | "Rejoice in the Lord always; again I
  Caltech                 |  will say, Rejoice..."
  [e-mail]  |              --Philippians 4:4
- ----------------------------------------------------------------

---------------------------

>From [e-mail] (Sak Wathanasin)
Subject: How to call 68K lib from PPC code?
Date: Mon, 5 Sep 94 23:22:46 BST
Organization: Network Analysis Ltd

I'm working on a a port of a largish appl to native PPC. The 68K
version calls a third party 68K lib to which we do not have the
sources. How can we call this 68K lib from native PPC code? I've read
chp 2 of "Inside Mac: PPC System Software" and I understand how to
create a UPP and call it, but how do I get the 68K code into memory?
The PPC linker won't slurp it in, of course.

The only thing I can think of is to make a 68K code resource, which
links with the 68K lib, and provide some glue that creates UPPs on
the PPC and calls the lib funcs directly on the 68K. Is there a
better way? Or am I horribly confused, and there's a really easy way
to do this that is so obvious it isn't worth mentioning in Inside Mac
(say "yes", please...).

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Tue, 06 Sep 1994 11:59:45 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Sak Wathanasin) wrote:

>I'm working on a a port of a largish appl to native PPC. The 68K
>version calls a third party 68K lib to which we do not have the
>sources. How can we call this 68K lib from native PPC code? I've read
>chp 2 of "Inside Mac: PPC System Software" and I understand how to
>create a UPP and call it, but how do I get the 68K code into memory?
>The PPC linker won't slurp it in, of course.

You have to build a standalone code resource out of the 68k
library. If the 68k library doesn't come in a standalone
version, you're hosed.

If the library is "Word Solutions Engine" by DataPak, they've
done the UPP part already, and are willing to sell it to you
for $400. Could be cheaper than your time to do the same, could
be more expensive, depending on how good (and expensive :-) you
are.

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  "Have a bearable day."


+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Wed, 7 Sep 94 13:15:23 BST
Organization: Network Analysis Ltd


In article <[e-mail]>
(comp.sys.mac.programmer), [e-mail] (Jon W{tte) writes:

> In article <[e-mail]>,
> [e-mail] (Sak Wathanasin) wrote:
>
> >I'm working on a a port of a largish appl to native PPC. The 68K
> >version calls a third party 68K lib to which we do not have the
> >sources. How can we call this 68K lib from native PPC code?....
>
> You have to build a standalone code resource out of the 68k
> library. If the 68k library doesn't come in a standalone
> version, you're hosed.

Not sure what you mean by a "standalone version" - it's just an MPW
".o" file. I have had a private response from someone at Apple who
confirmed that making a code resource out of the lib is indeed the
way to go about it.

> If the library is "Word Solutions Engine" by DataPak,

It isn't, worse luck.

> they've
> done the UPP part already, and are willing to sell it to you
> for $400. Could be cheaper than your time to do the same, could
> be more expensive, depending on how good (and expensive :-) you
> are.

I charge a bit more than $400 (:-)....

Many thanks to everyone who responded.

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Harold Ekstrom)
Date: Wed, 07 Sep 1994 18:36:52 -0800
Organization: Ag Group

In article <[e-mail]>, [e-mail] (Jon
W{tte) wrote:

> In article <[e-mail]>,
> [e-mail] (Sak Wathanasin) wrote:
>
> >I'm working on a a port of a largish appl to native PPC. The 68K
> >version calls a third party 68K lib to which we do not have the
> >sources. How can we call this 68K lib from native PPC code? I've read
> >chp 2 of "Inside Mac: PPC System Software" and I understand how to
> >create a UPP and call it, but how do I get the 68K code into memory?
> >The PPC linker won't slurp it in, of course.
>
> You have to build a standalone code resource out of the 68k
> library. If the 68k library doesn't come in a standalone
> version, you're hosed.

That's right. There was a recent MacTech article about how to do this,
but I can't recall exactly what month it was.

> If the library is "Word Solutions Engine" by DataPak, they've
> done the UPP part already, and are willing to sell it to you
> for $400. Could be cheaper than your time to do the same, could
> be more expensive, depending on how good (and expensive :-) you
> are.
>
> Cheers,
>
>                                 / h+
>
>
> --
>   Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
>


>   "Have a bearable day."
- ------------------------------------------------------------
Harold Ekstrom
[e-mail]
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp


+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Thu, 8 Sep 1994 17:05:47 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Sak Wathanasin) writes:


>In article <[e-mail]>
>(comp.sys.mac.programmer), [e-mail] (Jon W{tte) writes:

>> In article <[e-mail]>,
>> [e-mail] (Sak Wathanasin) wrote:
>>
>> >I'm working on a a port of a largish appl to native PPC. The 68K
>> >version calls a third party 68K lib to which we do not have the
>> >sources. How can we call this 68K lib from native PPC code?....
>>
>> You have to build a standalone code resource out of the 68k
>> library. If the 68k library doesn't come in a standalone
>> version, you're hosed.

>Not sure what you mean by a "standalone version" - it's just an MPW
>".o" file. I have had a private response from someone at Apple who
>confirmed that making a code resource out of the lib is indeed the
>way to go about it.

It has to be *linkable* into a code resource. In this case this means
that you have to be able to build a dispatcher for each of the calls
in the library. It also cannot use any global space (either *variables*
or *constants*) unless you want to jump through hoops to create an A5
world for the library to store its globals and constants in. Check
out the tech note called "globals in standalone code" for more info.

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

---------------------------

>From [e-mail] (Mathias W. Richter)
Subject: PROBLEM: Serial Port Programming & PowerBooks
Date: Tue, 30 Aug 1994 13:57:39 GMT
Organization: Dept. of Computer Science, University of Zurich

I have a problem with an application that reads/writes data
from/to an external unit (bicycle computer that collects
data) via the serial ports of the Mac.

The application runs fine on all Macs except for the PowerBooks.
On PowerBooks, during

                                        error:=FSWrite(currentOut, count, Ptr(outBuffer));
                                        {* outBuffer: ARRAY [1..7] OF BYTE; *}

the serial driver goes into an infinite loop somewhere in its code.
In MacsBug it looks like this:

                    _vSyncWait    MOVE.W        $0010(A0),D0
                                                            BGT.S             _vSyncWait

D0 stays $01 forever...

This only happens, when I use "external modem" in the portable control
panel (which I must when using the unit to communicate with) or when
I use the printer port with the "internal modem" set (which doesn´t
make sense for my application, but I tried it anyway).

I am opening the serial driver with the "OpenDriver" routines and I stick
to the tool box calls of the Driver Mgr. and the Serial Mgr.

On my old Macintosh Portable  (as on all other Macs incl. PowerMac) it
runs just fine.
The error occurs no matter which fax/etc. software is or is not
installed and it occurs independently of the make of the installed modem.

PLEASE HELP!

Mathias.
- ---------------------------
Dept. of CS
University of Zurich
Switzerland
email: [e-mail]
- ---------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 30 Aug 1994 08:07:58 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Mathias W. Richter) writes:
>I have a problem with an application that reads/writes data
>from/to an external unit (bicycle computer that collects
>data) via the serial ports of the Mac.

You forgot to set the handshake.

OSErr:=SerHShake(refNum_integer,flags_SerShk);



Xavier

P.S. I know because I made the same mistake. :-)




--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Tue, 30 Aug 1994 22:29:16 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Mathias W. Richter) wrote:

>data) via the serial ports of the Mac.
>
>The application runs fine on all Macs except for the PowerBooks.

This, if anything, SHOULD go into the FAQ. Any volounteers for
a Q&A on this?

The PowerBooks serial drivers default to handshaking ON - you
have to call SerHShk to set handshaking to what you need.

However, calling FSRead/FSWrite on the serial ports is bad
style; using asynchronous PBReads and PBWrites are better, and
doing that while also using the Threads Manager takes you to
the upper half of the coolness ladder.

Oh, and _vSyncWait is where all drivers go to die, temporarily,
until the synchronous call they wait for completes and sets the
result code of the parameter block.

Cheers,

                    / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 31 Aug 1994 23:18:04 +1200 (NZST)
Organization: (none)

[e-mail] (Mathias W. Richter) writes:
> I have a problem with an application that reads/writes data
> from/to an external unit (bicycle computer that collects
> data) via the serial ports of the Mac.

This is the standard PowerBook Serial Port Lockup FAQ.

You need to call SerHShake to turn hardware handshaking off if you
don't want to use hardware handshaking.

Hardware handshaking is turned on by default when you reset the serial
ports, but it just happens that on desktop Macs you can usually get away
with leaving the handshaking pins unconnected.  Not so on portables.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosen)
Date: 7 Sep 1994 17:03:14 GMT
Organization: Massachusetts Institute of Technology

Here's the code I use now.  I'm certainly not a Serial Driver
expert, but it works for me.  Note taht all I'm sending is a dial string
("ATDT" etc.), so I'm not worrying about flow control or async
routines.

--Alex

OpenDriver("\p.AOut", &outDriver);
OpenDriver("\p.AIn", &inDriver);

    // Turn off hardware handshaking.
SerShk    shake;
memset( &shake, 0, sizeof(shake) );
SerHShake( outDriver, &shake );
SerHShake( inDriver, &shake );

    // set baud rate and stuff
SerReset(outDriver, baud300 | stop10 | noParity | data8);
SerReset(inDriver, baud300 | stop10 | noParity | data8);

    // send string
long count = strlen(toModemBuf);
FSWrite(outDriver, &count, toModemBuf);



---------------------------

>From [e-mail]
Subject: Using CLUTs to simulate page flipping?
Date: 1 Sep 94 21:15:11 -0300
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

Has anyone tried using CLUTs to simulate page flipping on the Mac? This
would involve using 16 colours in a 256 colour palette. The top and bottom
nybbles of the byte would hold the values for "page 1" and "page 2". Games
like Oxyd and Syndicate show that very good looking 16-colour games can be
made.

How would this work? For the byte XXXX0000, for instance, you'd make 16 of
your CLUT entries (00000000, 00010000, 00100000, etc.) the same colour and
so on for the 16 possible low nybble values. For the byte 0000XXXX you'd do
the converse. To "flip" the pages you'd change the CLUT.

Would the fact that you could save the blit to the screen outweigh the overhead
of using half-bytes and changing the CLUT? Anyone have any best guesses on
this?

Sean

+++++++++++++++++++++++++++

>From Hiep Dam <[e-mail]>
Date: Fri, 2 Sep 94 00:39:54 -0500
Organization: Delphi ([e-mail] email, 800-695-4005 voice)

<[e-mail]> writes:

>Has anyone tried using CLUTs to simulate page flipping on the Mac? This
>would involve using 16 colours in a 256 colour palette. The top and bottom
>nybbles of the byte would hold the values for "page 1" and "page 2". Games
>like Oxyd and Syndicate show that very good looking 16-colour games can be
>made.

I believe (though I can't be sure) that Arashi does this. Actually I'm
pretty sure. For those not familiar with Arashi, it's basically a clone
to that cool Atari game of years past, Tempest. I think Arashi uses 2
16 color "planes" within a 256 color palette, and does simulate page
flipping with this.

You can find the source code to Arashi, along with the "Vector kit", at
all the popular sites you find source code at. It's was originally written
by the Jurri Munkki, with additional help from team members of Project
Storm.

Note however that Arashi's method isn't fullproof. While it works fine
on my IIsi, I get some errant "writes" to the screen on my PowerBook Duo
230 (when docked, of course).

Hiep
[e-mail] += [e-mail]
"If we are to be labeled, I would have preferred 'Might Morphin Generation X'"

+++++++++++++++++++++++++++

>From [e-mail] (Hugh Fisher)
Date: Fri, 02 Sep 1994 13:46:24 +1000
Organization: BAMBI, Australian National University

In article <[e-mail]>, [e-mail] wrote:

> Has anyone tried using CLUTs to simulate page flipping on the Mac? This
> would involve using 16 colours in a 256 colour palette. The top and bottom
> nybbles of the byte would hold the values for "page 1" and "page 2". Games
> like Oxyd and Syndicate show that very good looking 16-colour games can be
> made.
>
> How would this work? For the byte XXXX0000, for instance, you'd make 16 of
> your CLUT entries (00000000, 00010000, 00100000, etc.) the same colour and
> so on for the 16 possible low nybble values. For the byte 0000XXXX you'd do
> the converse. To "flip" the pages you'd change the CLUT.
>
> Would the fact that you could save the blit to the screen outweigh the overhead
> of using half-bytes and changing the CLUT? Anyone have any best guesses on
> this?
>

  I've played around with this a bit, and found two problems.

  The minor one is that if you use the Palette Manager, changing the CLUT
  is *slower* than blitting to the screen. I imagine this is because of the
  need to scan and update the other palettes, because it seems to depend on
  on the mix of other applications open at the time.

  You can get around this by using the lower level device calls instead,
  which would be real unsociable for a regular application but acceptable
for
  a game I guess.

  The major one is that drawing to the screen becomes a real pain, because
  you can't touch the high/low 4 bits in each pixel. You have to use
logical
  AND mode (or OR if you know where you are drawing is clear) and use pixel
  values with the high/low bits all set. For bitmapped images, this means
  keeping two copies of each.

  Of course, you could try writing your own graphic primitives...but as the
  FAQ for this group explains in detail, this is a Really Bad Idea.

  My "guess" therefore is that it is a worthwhile technique if you're
prepared
  to put a lot of time and effort into it (maybe someone already has?) but
  not if you want a quick, easy, and portable solution.

        Hugh Fisher
        Biochemistry and Molecular Biology, Australian National University

+++++++++++++++++++++++++++

>From [e-mail] (Edward Keyes)
Date: Sun, 4 Sep 1994 21:47:10 GMT
Organization: Vanderbilt University

In article <[e-mail]>,
Hiep Dam <[e-mail]> wrote:

> <[e-mail]> writes:
>
> >Has anyone tried using CLUTs to simulate page flipping on the Mac? This
> >would involve using 16 colours in a 256 colour palette. The top and bottom
> >nybbles of the byte would hold the values for "page 1" and "page 2". Games
> >like Oxyd and Syndicate show that very good looking 16-colour games can be
> >made.
>
> I believe (though I can't be sure) that Arashi does this. Actually I'm
> pretty sure. For those not familiar with Arashi, it's basically a clone
> to that cool Atari game of years past, Tempest. I think Arashi uses 2
> 16 color "planes" within a 256 color palette, and does simulate page
> flipping with this.

I have always thought that this method would be just superb in combination
with a pair of LCD shutter glasses for a 3D effect.  Just put the left eye
view in the top nybble and the right eye view in the bottom and install an
interrupt routine that animates the palette in synchronization with the
monitor's refresh rate while simultaneously sending the appropriate signal
across a serial or ADB port to the glasses to flip the shutters.

And presto!  30+ fps true stereoscopic graphics with a lot less processor
overhead than having to individually blit the left and right eye views
over and over again.

Has anyone had any luck with adopting a set of those old Sega 3D glasses
to the Mac for this sort of thing?

- ------  Edward Keyes ([e-mail])  --------
--  "This is what the LORD Almighty, the God of Israel says:  --
--  'Drink, get drunk and vomit, and fall to rise no more.'"  --
- --------------------------------  Jeremiah 25:27  ------------

+++++++++++++++++++++++++++

>From [e-mail] (Amanda Walker)
Date: Tue,  6 Sep 1994 14:55:43 -0400
Organization: InterCon Systems Corporation, Herndon, VA  USA

Hiep Dam <[e-mail]> writes:
> I believe (though I can't be sure) that Arashi does this. Actually
> I'm pretty sure. For those not familiar with Arashi, it's basically
> a clone to that cool Atari game of years past, Tempest. I think
> Arashi uses 2 16 color "planes" within a 256 color palette, and
> does simulate page flipping with this.

Actually, Arashi uses two 3-bit (8 color) planes, and one 2-bit background
plane.  It also has the smoothest code for doing this sort of stuff on the Mac
that I've yet seen in the public domain.


Amanda Walker
InterCon Systems Corporation



+++++++++++++++++++++++++++

>From [e-mail] (Dr. Jon Gerard Temple)
Date: 6 Sep 1994 20:02:49 GMT
Organization: Naval Research Laboratory

In article <[e-mail]>
[e-mail] (Amanda Walker) writes:

> Hiep Dam <[e-mail]> writes:
> > I believe (though I can't be sure) that Arashi does this. Actually
> > I'm pretty sure. For those not familiar with Arashi, it's basically
> > a clone to that cool Atari game of years past, Tempest. I think
> > Arashi uses 2 16 color "planes" within a 256 color palette, and
> > does simulate page flipping with this.
>
> Actually, Arashi uses two 3-bit (8 color) planes, and one 2-bit background
> plane.  It also has the smoothest code for doing this sort of stuff on the Mac
> that I've yet seen in the public domain.
>
>

It runs pretty smoothly, too.  I don't understand why people over at
comp.sys.mac.games think it is a weak Tempest clone.  It is one of the
best clones I have ever seen, and it is free, as well as a little more
colorful than the original. I actually sent Juri Munkki a "fan" letter
after seeing an early beta (called "STORM" then).  Tempest was one of
the few games I really missed from my teen years...

+++++++++++++++++++++++++++

>From Darrin Cardani <[e-mail]>
Date: Wed, 7 Sep 1994 17:10:59 GMT
Organization: AT&T Global Information Solutions, Atlanta

>In article <34iht9$[e-mail]> Dr. Jon Gerard Temple writes:
[...stuff about Arashi...]
>It runs pretty smoothly, too.  I don't understand why people over at
>comp.sys.mac.games think it is a weak Tempest clone.  It is one of the
>best clones I have ever seen, and it is free, as well as a little more
>colorful than the original. I actually sent Juri Munkki a "fan" letter
>after seeing an early beta (called "STORM" then).  Tempest was one of
>the few games I really missed from my teen years...>

Geez! If they think Arashi is weak, they should see the
piece of crap version I have on my Windows machine at
work. It blinks really bad, firing doesn't work correctly.
Oh well.

Darrin







+++++++++++++++++++++++++++

>From [e-mail] (Jim Bumgardner)
Date: Wed, 7 Sep 1994 19:33:55 GMT
Organization: Time Warner Interactive Group

[e-mail] wrote:
: Has anyone tried using CLUTs to simulate page flipping on the Mac? This
: would involve using 16 colours in a 256 colour palette. The top and bottom
: nybbles of the byte would hold the values for "page 1" and "page 2". Games
: like Oxyd and Syndicate show that very good looking 16-colour games can be
: made.

I wrote some sample code that uses an extension of this idea to do
cross fades (cross dissolves) some months ago for a book
I was working on.  I've made the code available by ftp from ftp.netcom.com
in the directory pub/jbum.  The file is called CrossDissolveExample.sit

Although changing the CLUT is slower than blitting to the screen, it
does allow for an extremely smooth crossfade effect which is especially
effective for displaying movie credits.  The program "Credits" included
with the archive demonstrates this.


--
--
-- Jim Bumgardner                 |   [e-mail]
-- Time Warner Interactive
-- GSC/MUd--p(-)c+++!lu+e-m*s/+n++(---)h--f!gw+t+ry++

---------------------------

>From [e-mail] (Vincent Partington)
Subject: Why is AppleScript type checking absent?
Date: 6 Sep 1994 08:37:27 GMT
Organization: FWI, University of Amsterdam

Hi,

Why is that the AppleScript Script Editor doesn't warn me about passing the
wrong type of data to requests while the 'aete' resource tells it what sort
of data to expect?

The following line will compile just fine:
open {file "hard disk:hello.c"}
Although it should be:
open {alias "hard disk:hello.c"}

Most of the time the first line will work because most handlers ask the AEM
to coerce the argument into an FSSpec. But it's still wrong.

The following will also compile:
open {"hard disk:hello.c"}

That won't work of course, but why won't AppleScript tell me about it?
Why can't is see the open-event wants a list of aliases and either tell me
it's wrong or (even better) convert it into an alias for me?

Thanks, Vincent.
--
appel peer banaan baksteen           ||| The Fingerware Project:
schelp zon zand rolstoel             ||| Put your code snippets in your .plan!
groen wit geel flatgebouw            ||| If you want to know more
boer postbode bouwvakker roos        ||| finger [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Scott Bronson)
Date: 6 Sep 1994 19:33:45 GMT
Organization: University of California, Santa Barbara

In <34h9o7$[e-mail]> [e-mail] (Vincent Partington) writes:

>open {file "hard disk:hello.c"} vs. open {alias "hard disk:hello.c"}
>Most of the time the first line will work because most handlers ask the AEM
>to coerce the argument into an FSSpec. But it's still wrong.

No, it's correct.  The AppleScript Language Guide, p. 81, tells how
automatic coercion works.


>The following will also compile:
>open {"hard disk:hello.c"}

>That won't work of course, but why won't AppleScript tell me about it?
>Why can't is see the open-event wants a list of aliases and either tell me
>it's wrong or (even better) convert it into an alias for me?

Actually, sometimes it works.  This very script just executed perfectly
not two minutes ago...

tell application "Scriptable Text Editor"
        open {"Dev.CD Sep 93:Reference Library:Periodicals:develop:develop Issue 15:develop 15 code:Floaters:Source:floaters.make"}
end tell

My guess is that coercion from a string to an alias is automatic, although
the Language Guide does not make this obvious.  If an application's
dictionary is set up differently than the Scriptable Text Editor's,
your mileage may vary.

The reason the following is not flagged at compile time...

tell application "Scriptable Text Editor"
        open {1}
end tell

...is because the open routine asks for a list, and that is exactly
what you are passing.  AppleScript doesn't worry about the contents
of the list, because they may change or be able to be coerced at run
time.

These are all just guesses, but I think I'm close...

    - Scott

+++++++++++++++++++++++++++

>From [e-mail] (Peter Kocourek)
Date: 07 Sep 94 18:15:17 +
Organization: Care Net Holland

Vincent Partington wrote on 06 Sep 94:

 VP> Why is that the AppleScript Script Editor doesn't warn me about
 VP> passing the wrong type of data to requests while the 'aete'
 VP> resource tells it what sort of data to expect?

[snip]

 VP> The following will also compile: open {"hard disk:hello.c"}
 VP>
 VP> That won't work of course, but why won't AppleScript tell me
 VP> about it? Why can't is see the open-event wants a list of aliases
 VP> and either tell me it's wrong or (even better) convert it into
 VP> an alias for me?

I think it's probably related to coercion handlers; the Script Editor cannot
know which coercion handlers will be present at runtime, because applications
can install their own. So while there is no built-in handler for coercing
typeFSS to typeAlias, there could be one present by the time the application
is run.

So you're left with run-time type checking. I'm not particularly happy about
it myself, but I don't see any other alternative. Perhaps adding coercion
information in a resource? Then the Script Editor could take the built-in
coercions for granted, and add to that the coercion handlers the application
promises to install if it is run.


YHS:QSI!
;Simple help instructions for fileserv via a GIGO gateway..
; ASCII               Forces ASCII dump (ie text,etc)
; BINARY              Forces UUENCODED binary files (autosplit)
; DETECT              Autodetects ASCII/BINARY
; GET filename.ext    gets a single file
; GET filename.      gets anything starting with filename.
; HELP                this help file
; INDEX               Asks for the host's list of public files
; SIZE xxx            Size per split (1500-45000)
;Note on filenames: DOS wildcards are accepted, but not unix regex.
;
;
;Questions? Email [e-mail] ..

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 07 Sep 1994 17:56:10 -0700
Organization: Internet for the Olympic Peninsula

I believe it was in this thread earlier that I noticed a statement that a
path ("Vol:Folder:file") could be used...this is an artifact of (at least)
the Jon's Commands Scripting Addition, which installs a coercion osax
which converts from (suitable) TEXT to 'fss '.  Remove Jon's Commands (or
whatever other osax is installing the handler) and restart, and the
ability will go away (unless the target app itself installs a TEXT->fss
handler).

Simple, eh?  No wonder there's no type checking.  --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   "Occasionally...astronomers add a second to either June 31 or
    December 31..."   IM: OS Utilities, p 4-12
   [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 8 Sep 1994 01:37:46 GMT
Organization: Apple Computer

Vincent Partington, [e-mail] writes:
> Why is that the AppleScript Script Editor doesn't warn me about passing the
> wrong type of data to requests while the 'aete' resource tells it what sort
> of data to expect?

The data types in the 'aete' are just guidelines or documentation. There are
plenty of cases where several types can be passed to a parameter, and the
'aete' doesn't indicate that. For that reason and others, AppleScript does
not use that information when compiling a script. It's a dynamic language
(like Smalltalk or Dylan) that does not do type checking at compile time;
this does let you make mistakes in your scripts, but it also allows you a lot
more flexibility.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

---------------------------

>From [e-mail] (Chris Burns)
Subject: [Q] _PBCatSearch vs Recursive Indexed _PBGetCatInfo
Date: Mon, 05 Sep 1994 09:01:48 +1200
Organization: AucklandUniversity:ComputerScience:HMU

Hi all,

I'm just about to start working on a spare-time project that involves
scanning disk directories.

Now, there seem to be (at least) two ways fo doing this:

(1) _PBCatSearch (if supported)

(2) Indexed calls to _PBGetCatInfo, recursing when a directory is found. I'd
    probably use the modification to this algorithm suggested by John Norstad
    (this takes multiple processes creating, moving and deleting files and
    directories into account).

I've implemented (2) before and it was not particularly speedy on my 1GB
hard disk at work (~10,000 files!). Does anyone know if (1) is any faster?
I realize the search parameters probably make a huge difference on the
speed (partial filenames etc), but I'd probably use a "find-all" parameter
set.

Any help, flames or pointers appreciated,

Thanks In Advance,

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 5 Sep 1994 02:27:10 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (Chris Burns) writes:

>I've implemented (2) before and it was not particularly speedy on my 1GB
>hard disk at work (~10,000 files!). Does anyone know if (1) is any
faster?
>I realize the search parameters probably make a huge difference on the
>speed (partial filenames etc), but I'd probably use a "find-all"
parameter
>set.

In general, PBCatSearch is faster. The only condition I've seen where
PBCatSearch is slower is if you are looking for *all* matches (i.e., all
files and directories) on an AppleShare volume.  The AppleShare client
asks for the CatSearch matches four at a time which doesn't shove the
information across the network as efficiently as indexed GetCatInfo calls
which are translated into afpEnumerate requests (which collect as many
directory entries as will fit into a full sized ATP response).  If you're
expecting just a few matches to specific criteria, however, PBCatSearch is
faster because all of the searching is done on the server and only the
matches are returned over the network.

>Any help, flames or pointers appreciated,

A couple of suggestions:

First, read the Technical Note "FL 31 - Searching Volumes-Solutions and
Problems". When I updated it a couple of years ago, I tried to cover much
of what you're asking.

Second, get MoreFiles v1.2.1.  I added an indexed search routine
(IndexedSearch) that is parameter block compatible and functionally
compatible with PBCatSearch except that you get to specify the directory
you want to search (for example, to search the whole volume, you just pass
fsRtDirID). I also added a glue routine (PBCatSearchSyncCompat) that calls
PBCatSearch if PBCatSearch is available and calls IndexedSearch if it's
not. MoreFiles can be found at:

    ftp.apple.com (IP address 130.43.2.3)

    /ftp/dts/mac/sc/more-files-1-2-1.hqx

- Jim Luther


+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Mon, 05 Sep 1994 19:17:00 +1200
Organization: AucklandUniversity:ComputerScience:HMU

In article <[e-mail]>,
[e-mail] wrote:

> Hi all,
>
> I'm just about to start working on a spare-time project that involves
> scanning disk directories.

Well, since nobody had replied to my post for at least 2 hours :)
I wrote a quick test app.

Results:

Power Mac 8100/80, 1GB HD with 9,461 items (557.8 MB in disk)

_PBGetCatInfo:      ~1450 Ticks
_PBCatSearch:       ~65 Ticks

Wow!

I compiled the app with CodeWarrior CW4 and both PPC and 68K versions
performed similarly as expected (program involveds much heavy file I/O).

I'd be interested to see any other results...

Later,

Chris B

Code Follows...


///////////////////////////////////////////////////////////////////////////////

void Prime_PBGetCatInfo (void);
void Enumerate_PBGetCatInfo (long CurDirID);
void Prime_PBCatSearch (void);
void Enumerate_PBCatSearch (void);

///////////////////////////////////////////////////////////////////////////////

CInfoPBRec      gCInfoPB1;
Str255          gName;

///////////////////////////////////////////////////////////////////////////////

void Prime_PBGetCatInfo (void)
{
    gCInfoPB1.dirInfo.ioNamePtr = gName;
    gCInfoPB1.dirInfo.ioVRefNum = -1;
}

///////////////////////////////////////////////////////////////////////////////

void Enumerate_PBGetCatInfo (long CurDirID)
{
short   CurDirIndex = 0;
OSErr   Err;

    do
    {
        CurDirIndex++;

        gName[0] = 0;

        gCInfoPB1.dirInfo.ioFDirIndex = CurDirIndex;
        gCInfoPB1.dirInfo.ioDrDirID = CurDirID;

        Err = PBGetCatInfoSync(&gCInfoPB1);

        switch (Err)
        {
            case noErr:
                if (gCInfoPB1.dirInfo.ioFlAttrib & 16)
                    Enumerate_PBGetCatInfo(gCInfoPB1.dirInfo.ioDrDirID);
                break;

            case fnfErr:
                break;

            default:
                DebugStr("\p_PBGetCatInfoSync FAILED");
                break;
        }
    }
    while (Err == noErr);
}

///////////////////////////////////////////////////////////////////////////////

CSParam         gCSParamPB;
CInfoPBRec      gCInfoPB2;

///////////////////////////////////////////////////////////////////////////////

void Prime_PBCatSearch (void)
{

    gCSParamPB.ioNamePtr = nil;
    gCSParamPB.ioVRefNum = -1;

    gCSParamPB.ioMatchPtr = (FSSpecPtr)NewPtr(sizeof(FSSpec) * 1000);
    if ((gCSParamPB.ioMatchPtr == nil) || (MemError() != noErr))
        DebugStr("\p_NewPtr FAILED");

    gCSParamPB.ioReqMatchCount = 1000;

    gCSParamPB.ioSearchBits = 0;

    gCSParamPB.ioSearchInfo1 = (CInfoPBPtr)&gCInfoPB1;
    gCSParamPB.ioSearchInfo2 = (CInfoPBPtr)&gCInfoPB2;

    gCSParamPB.ioSearchTime = 0;

    gCSParamPB.ioCatPosition.initialize = 0;

    gCSParamPB.ioOptBuffer = NewPtr(16 * 1024L);
    if ((gCSParamPB.ioOptBuffer == nil) || (MemError() != noErr))
        DebugStr("\p_NewPtr FAILED");

    gCSParamPB.ioOptBufSize = 16 * 1024L;
}

///////////////////////////////////////////////////////////////////////////////

void Enumerate_PBCatSearch (void)
{
OSErr   Err;

    do
    {
        Err = PBCatSearchSync(&gCSParamPB);
        switch (Err)
        {
            case noErr:
                break;

            case eofErr:
                break;

            default:
                DebugStr("\p_PBCatSearchSync FAILED");
                break;
        }
    }
    while (Err == noErr);
}

///////////////////////////////////////////////////////////////////////////////

void main (void)
{
long    StartTicks;
Str255  Str1;
Str255  Str2;

    InitGraf(&qd.thePort);

    Prime_PBGetCatInfo();
    StartTicks = TickCount();
    Enumerate_PBGetCatInfo(fsRtDirID);
    NumToString(TickCount() - StartTicks,Str1);

    Prime_PBCatSearch();
    StartTicks = TickCount();
    Enumerate_PBCatSearch();
    NumToString(TickCount() - StartTicks,Str2);

    SysBeep(0);
    DebugStr(Str1);
    DebugStr(Str2);
}

///////////////////////////////////////////////////////////////////////////////
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 05 Sep 1994 17:34:17 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Chris Burns) wrote:

>I've implemented (2) before and it was not particularly speedy on my 1GB
>hard disk at work (~10,000 files!). Does anyone know if (1) is any faster?

PBCatSearch linearly searches the directory tree; and can be
fast for things like name searches, but it's practically
worthless if you want to know about file hiearchies.

PBGetCatInfo isn't too bad, especially if you read all the
files FIRST, remembering which folders there were and going
back to them after doing the scan (this is because there is
some "next pointer" cache in the file system, it seems)

You should also remember how many files there are in the
folder, and only iterate for that many if you want speed; the
"miss" giving eofErr at the end can take magnitudes longer time
than a "hit" for an indexed search!

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
   This signature is kept shorter than 4 lines in the interests of UseNet
   S/N ratio.


+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Tue, 06 Sep 1994 10:13:49 +1200
Organization: AucklandUniversity:ComputerScience:HMU

In article <[e-mail]>,
[e-mail] wrote:

> In article <[e-mail]>,
> [e-mail] wrote:
>
> > Hi all,
> >
> > I'm just about to start working on a spare-time project that involves
> > scanning disk directories.
>
> Results:
>
> Power Mac 8100/80, 1GB HD with 9,461 items (557.8 MB in disk)
>
> _PBGetCatInfo:      ~1450 Ticks
> _PBCatSearch:       ~65 Ticks

Well, it gets more interesting...

FileSharing:                    On  |    Off
- ----------------------------------+--------
PPC App:  _PBGetCatInfo:     ~5050  |  ~1450
          _PBCatSearch:        ~65  |    ~65
                                    |
68K App:  _PBGetCatInfo:     ~5030  |  ~1480
          _PBCatSearch:        ~65  |    ~65

Seems like FileSharing causes a big hit on _PBGetCatInfo!

Later,

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Tue, 06 Sep 1994 13:28:28 +1200
Organization: AucklandUniversity:ComputerScience:HMU

In article <34ednu$[e-mail]>, [e-mail] (Jump
Long) wrote:

> In general, PBCatSearch is faster. The only condition I've seen where
> PBCatSearch is slower is if you are looking for *all* matches (i.e., all
> files and directories) on an AppleShare volume.  The AppleShare client
> asks for the CatSearch matches four at a time which doesn't shove the
> information across the network as efficiently as indexed GetCatInfo calls
> which are translated into afpEnumerate requests (which collect as many
> directory entries as will fit into a full sized ATP response).  If you're
> expecting just a few matches to specific criteria, however, PBCatSearch is
> faster because all of the searching is done on the server and only the
> matches are returned over the network.

I tried this, and Jim is correct.

PPC App:  _PBGetCatInfo:     ~4820 Ticks
          _PBCatSearch:      ~5155 Ticks

Thanks Jim!

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 6 Sep 1994 00:07:06 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(Jon W{tte) writes:

>You should also remember how many files there are in the
>folder, and only iterate for that many if you want speed; the
>"miss" giving eofErr at the end can take magnitudes longer time
>than a "hit" for an indexed search!

That's not a good idea because the number of items in a directory can
change - another process or another client using a shared volume could
delete or add one or more files/directories to the folder you're indexing
through.  There also could or may be foreign file systems that don't
return the ioDrNmFls.

- Jim Luther

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Tue, 06 Sep 1994 11:59:27 +0200
Organization: Royal Institute of Something or other

In article <34gpta$[e-mail]>,
[e-mail] (Jump Long) wrote:

>>You should also remember how many files there are in the
>>folder, and only iterate for that many if you want speed; the
>>"miss" giving eofErr at the end can take magnitudes longer time
>>than a "hit" for an indexed search!

>That's not a good idea because the number of items in a directory can
>change - another process or another client using a shared volume could

Yes. I should have made it clear that this was a trade-off. You
can make sure that you get all files by reading the previous
info right after you read the next info, and check that it's
"still there". You can get the name of the last file once you
get the number of files, and then start over if the file with
index <lastIndex> does not have the name <nameOfLastFile>. Etc.

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  "Have a bearable day."


+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosenberg)
Date: Tue, 6 Sep 1994 10:04:30 GMT
Organization: Hackers Anonymous

In article <[e-mail]>,
[e-mail] wrote:

<All sorts of interesting stuff deleted>
> Seems like FileSharing causes a big hit on _PBGetCatInfo!

File Sharing adds information to the response from PBGetCatInfo. This
information is rather complicated to determine. File Sharing makes no
changes to the response from PBCatSearch.

- -------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  [phone]          - Nobody is my employer so       - :-)         -
-  [phone]          - nobody cares what I say.       -             -

---------------------------

End of C.S.M.P. Digest
**********************