HFS Grep
Volume Number: | | 3
|
Issue Number: | | 1
|
Column Tag: | | Neon News
|
HFS Grep & Scrollers in Neon
By Jörg Langowski, MacTutor Editorial Board, Grenoble, France
HFS Tiny Grep Utility in NEON 2.0
We'll have a NEON column again after a long pause; just recently I received a beta copy of NEON's version 2.0 (already mentioned in the last column). NEON 2.0 is the long-awaited HFS compatible upgrade, with a lot of changes in the file class definitions and the introduction of a new class, pathlist. With this class, HFS search paths may be defined which are then scanned by the NEON system when files are accessed. Usually, you set up the default search paths in a text file which is kept in the NEON folder and read automatically at startup. If you've set the path names to the appropriate disk and folder names that you are using in your particular development system, the HFS tree search along the path list becomes completely transparent. You may then, for all practical circumstances, regard the collection of folders defined by the search path names as one contiguous MFS volume. With one important difference: pathlist is a subclass of ordered-col, and new search paths may be added to or removed from the list by sending add: or remove:. This can occur during the execution of a program, so you may dynamically change search paths as your application requires.
Applications written in NEON 2.0 can be installed as one single file, putting the kernel and the dictionary together (which were separate in earlier versions). Installed applications have access to the finder information block through another class, Fin. Therefore we may determine how many documents were opened together with the application and whether they are supposed to be opened or printed.
I'm not going to give you all the details on NEON 2.0; quite a number of bugs seem to have been removed, and all in all the system seems to be more stable than the earlier versions. Nevertheless, the version that I saw is a beta test, therefore some bugs can still be expected. Which leads us to this month's example, a string search utility for text files that will work on HFS volumes. It is very much like the NEON 'grep' utility, which only works for MFS, however (even in the 2.0 beta version).
Grep, incidentally, means general regular expression parser, which neither the NEON grep nor our example really are. We are just looking for simple strings in a set of files and cannot use more complicated expressions to define a whole range of strings to look for, such as a 'real' grep can do.
Anyway, a directory-search utility for HFS volumes with added string search in text files makes a good example for using HFS from within NEON, and might also be useful to replace the Grep module on the NEON system disk. Note that the program, given in listings 1 and 2, will not work with earlier versions since it contains some v2.0 specific words.
Even though NEON 2.0 works well with HFS, the HFS - specific traps are not (yet?) directly supported. Therefore we create a simple HFS dispatcher word, HFSd, which takes a parameter block address and a function code off the stack, passes them to the HFS dispatcher in registers A0 and D0, calls the dispatcher trap and puts the result code from D0 back on the stack. The function codes for the HFS-specific calls are given at the beginning of the listing. We use only openWD here, which given a path name in the parameter block, opens the corresponding working directory (folder) and returns a directory ID number in D0.
Scanning a directory for files and folders
There exists a NEON word, getidxfile, which can be used on MFS disks to get information about the i-th file in the directory. It calls the getFInfo trap and places the information in the fFcb parameter block, which in turn can be used to open the file. HFS volumes, however, have to be treated differently. getFInfo still works sometimes on the root level of a volume, and also, by setting the appropriate volume ID, in folders; but it won't find subdirectories and, worst of all, sometimes crashes (at least according to some experiments I did both in NEON and Mach2). The correct way to scan an HFS directory is to call the getCatInfo routine, which will return the i-th directory entry and also indicate whether it is a file or another folder. This is implemented in the getixHFSfile word (listing 1).
Scanning through all of the disk now becomes very simple: we start with the root directory, and as soon as we find an entry that is another directory, we call the scanning routine recursively and repeat the process (remembering the old directory ID and file index on the stack). Scanning will be finished when no more entries are found in a directory; then the recursion will back up one level, until one is back at the root level and finished with all of the disk.
The DIR routine implements this strategy of descending the directory tree. It makes use of another definition, $openWD, which expects a string address as an input parameter, opens that particular folder and returns the directory ID (or an error code) on the stack. Successive calls to nextFile will return file or folder names further and further down the list of the working directory; if a folder is found, it is opened and a DIR done on its contents. Note that words may be called recursively in NEON, since no smudge bit is set during a definition. If you wanted to rewrite DIR in Mach2, you would have to indicate explicitly that this is to be a recursive definition (besides doing all the other necessary changes...).
grepDIR, then, is our text file string searcher. It works exactly the same way as DIR, except that after a text file has been found, it is opened and scanned for the search string. All files except text files are ignored. The string search routine is part of the NEON source code, therefore we won't print it here. Simply take the grep source file, copy the searchfile definition out of it and paste it into the example text. I have not written the program as a NEON module, but this can easily be done and you can rebuild your system with the new grep utility. Included is a word grepOne which will scan a single file, and menu definitions to change disk drives and turn the printer on and off.
Control handling in NEON - an alternate way
NEON usually takes charge of tracking controls in a CtlWind automatically. As one of our readers, Phil Barnard, remarked in a letter (part of which I already quoted in my last column), this automatic tracking of controls sometimes can lead to a stack-heap collision (system error 28). NEONs default stack setting, 3000, seems somewhat low anyway, since one does get ID=28 bombs out of the blue even in other situations, such as when one changes repeatedly from the NEON window to a desk accessory like MockTerminal and back. Those situations can be avoided by re-installing the NEON kernel with a larger stack; I generally use 32K without any problems.
The second program example, listing 3 (by Phil Barnard), gives an explicit implementation of a vertical scroll bar class. It creates an example window on which this scroll bar is used. I quote from his letter:
" The existing vertical scroll bar class appears to have problems (even the demo scrolling bombs if not handled right), which seems to be caused by overflow of the return and methods stack during the repeated execution of the 'Pascal' procedure passed as a parameter to the TrackControl toolbox call. Am I right?
This may be avoided by passing (-1) instead and only using the TrackControl call to track the thumb as in the following demo (...). To run the demo, load it and type the word 'TEST'. After the demo, click in fWind and type 'FIX'. "
After my tests, this seems to be one other way to avoid stack crashing problems; it works with smaller stack sizes than the standard NEON controls. As a general remark, if you see strange things happening with some of the predefined words of any of the existing Forth or Forth-related systems, just try and redefine the offending part yourself. This is very easy in Forth since often the source code for large parts of the system is provided or can be easily decompiled.
Fig. 1: Example of the WinTool Inside Macintosh data base
WinTool - Inside Macintosh on line database
We have quite an active scene of Macintosh developers here in Grenoble. As an example of what is being thought up on the other side of the Atlantic, I'd like to present to with a very nice utility that I was able to preview recently and that I'm already heavily using. In fact, it opens up considerable space on my crammed desk, because I can leave the three volumes of IM on the shelves most of the time now.
The program is called WinTool; it is a small data base implemented as a desk accessory. Although at present meant to provide you with an instant means of getting IM information, it could be used as a general data base by setting it up appropriately.
Here's how it works: You install a desk accessory (quite a hefty one, takes 44K) which is used to access indexed data bases that you keep somewhere on your development disk. The copy that I looked at contained a Managers and a Toolbox database. (Those bases, by the way, also take up quite a bit of space, all in all, installing Wintools will add 300 K to your system.) When you call up a desk accessory, it'll add a new menu, from which you may select options such as opening and closing bases, or (most important) finding entries. See figure 1.
So you don't remember the parameters to pass to ModalDialog? Just select the appropriate entry, and the correct procedure call - with trap number and IM page reference - will come up almost instantly. Even on my two-floppy system. Much faster than browsing through Inside Macintosh. This is particularly useful (for Forth users) if you want to add a new glue routine to a trap that has not been provided in your standard system, want to know the exact location of a system global, the structure of a particular record, etc. etc. The managers database gives you some sort of an 'overview' of definitions contained in the individual sections of IM; the Toolbox database then gives the details of the definition. Words may be selected in a file that you're currently working on and then found in the data base with the menu option 'find selection'. You can also add to the existing entries as your disk space permits, e.g. if you've found some particular quirks about how a certain routine works, about bugs and so on. I'm going to create my own index for Forth words, because I can never remember all of them (working with too many different Forth systems).
PS: As you read this, WinTool might be obtainable through MacTutor mail order. [Watch for it in an up-coming issue.-Ed]
One last remark for our French readers
Since we seem to have quite a large readership in Europe and especially in France by now, I think it is appropriate to make one short remark about connecting a modem to the Macintosh in France. [Other readers may now skip to the next article.]
The Macintosh may be very easily connected to a standard Minitel by a three-wire connection. [For other readers, who are still with me: the Minitel is a videotext terminal containing a 1200 baud modem that the French postal service provides free of charge for you. Of course, they charge you to use it.]
The way to set up the connection is as follows: Get a 3-pin DIN plug that plugs into the interface socket of the Minitel. Make the following connections:
DIN plug Macintosh DB-9 Mac Plus mini-DIN
1 (TTL input) 4 (TxD+) 6 (TxD+)
2 (ground) 3 (ground) 4 (ground)
3 (TTL output) 8 (RxD+) 8 (RxD+)
and off you go. (Try using one of the standard terminal programs on it).
Last minute news: I just received a newsletter from Palo Alto Shipping that there is a new Mach2 upgrade on its way which contains an integrated debugger (finally reinstalled), integrated editor, automatic resource integration into turnkey applications, and more nice things. I'll keep you informed on it.
Listing 1: Tiny Grep and Directory Descent utility
\ © J. Langowski / MacTutor, 1986
\ written in NEON v. 2.0
DECIMAL
-35 CONSTANT nsvErr( no such volume error )
-43 CONSTANT fnfErr( file not found error )
HEX
3F6 CONSTANT FSFCBLen \ >0 if HFS is being used
-1 CONSTANT MFS \ -1 if MFS is running
( this global variable is given for your information. )
( It is automatically checked by the NEON 2.0 word hfs? )
10 CONSTANT Dir/File \ bit 4 determines whether it is
\ a file or directory
DECIMAL
\ Routine selectors for HFS traps
1 CONSTANT OpenWD
2 CONSTANT CloseWD
5 CONSTANT CatMove
6 CONSTANT DirCreate
7 CONSTANT GetWDInfo
8 CONSTANT GetFCBInfo
9 CONSTANT GetCatInfo
10 CONSTANT SetCatInfo
11 CONSTANT SetVolInfo
16 CONSTANT LockRng
17 CONSTANT UnlockRng
\ some more constants
80 CONSTANT FileParamSize
106 CONSTANT CatParamSize
\ offsets into parameter block
12 CONSTANT ioCompletion ( completion routine [long word] )
16 CONSTANT ioResult ( result code returned here [word] )
18 CONSTANT ioNamePtr \ holds pointer to file name string
\ or pathname string [long word]
22 CONSTANT ioVRefNum
24 CONSTANT FioFRefNum ( path reference number [word] )
26 CONSTANT FioFVersNum ( usually zero [byte] )
28 CONSTANT FioFDirIndex( index [word] )
30 CONSTANT FioFlAttrib ( file attributes byte [byte] )
31 CONSTANT FioFlVersNum ( version number [byte] )
32 CONSTANT FioFlFndrInfo
48 CONSTANT FioDirID
48 CONSTANT FioFlNum
0 value Index
0 value VolRefNum
0 value DirID
: ?dup dup if dup then ;
\ the HFS dispatcher...
create hfsD
popD0
popA0
$ A060 w,
pushD0
next,
: $openWD { name -- VRefNum / errcode 0 }
0 fFcb ioCompletion + !
name +base fFcb ioNamePtr + !
0 fFcb FioFDirIndex + w!
fFcb +base OpenWD hfsD extend
?dup if 0 else fFcb ioVRefNum + w@ then;
: getixHFSfile { indx \ ResCode -- errorResCode }
\ setup parameter block:
VolRefNum fFcb ioVRefNum + W! \ specify the volume
DirID fFcb FioDirID + ! \ pass directory id
pad +base fFcb ioNamePtr + ! \ expect file name here
indx fFcb FioFDirIndex + W! \ pass current index
hfs? IF fFcb +base GetCatInfo hfsD extend -> ResCode
ELSE fFcb fcall PBGetFInfo extend -> ResCode
THEN
ResCode \ pass ResCode on stack;
: NextFile 1 ++> index index getixHFSFile ;
0 value level
: indent cr level 4 * spaces ; ( for pretty printing )
: DIR { vol \ resCode -- }
0 -> Index ( initialize index )
vol -> VolRefNum ( choose volume in internal drive )
2 -> DirID ( specify root directory, significant in HFS )
BEGIN
NextFile -> resCode
ResCode 0=
IF
indent
fFcb FioFlAttrib + C@ ( get the attributes byte )
Dir/File AND ( file or directory ? )
IF indent
33 tface ." Directory -> " pad count type
0 tface
1 ++> level
index volrefnum ( push on stack )
pad $openwd DIR ( recursive call to DIR )
-> volrefnum -> index ( pop off stack )
-1 ++> level
indent
ELSE pad count type
THEN
THEN
ResCode
UNTIL ( error found )
ResCode ( which error ? )
CASE
fnfErrOF
level ?dup
IF cr 1- 4 * spaces
33 tface ." End of directory" 0 tface
ELSE cr 33 tface ." End of contents listing"
0 tface quit
THEN
ENDOF
nsvErr OF cr ." There is no disk in drive number " vol . ENDOF
cr ." Error #" ResCode .
ENDCASE
;
String gpattern
String linBuf
String target
0 value #lines \ total lines searched
\ SEARCHFILE - This routine searches a file for the presence of
\ gpattern, outputting all lines that contain the string.
\ It is contained in the 'grep' source file on the NEON 2.0 disk.
\ Please insert the appropriate source code here....
\ ...
\ ...
\ ...
: grepInit
0 -> #lines
indent ." Searching for: " print: gPattern CR
uc: gPattern 2drop
new: linBuf
;
: grepDIR { vol addr len \ resCode gcurs -- }
new: loadFile new: gpattern new: target
addr len str255 -base count put: gPattern
curs -> gcurs -curs \ Preserve cursor status
grepInit
0 -> Index \ initialize index
vol -> VolRefNum \ choose volume in internal drive
2 -> DirID \ specify root directory , immaterial for MFS
BEGIN ?pause
NextFile -> resCode
ResCode 0=
IF
indent
fFcb FioFlAttrib + C@ \ get the attributes byte
Dir/File AND \ file or directory?
IF indent
33 tface ." Directory -> " pad count type
0 tface
1 ++> level
index volrefnum \ push on stack
pad $openwd addr len grepDIR
\ recursive call to grepDIR
-> volrefnum -> index \ pop off stack
-1 ++> level
indent
ELSE pad count type
pad count name: topFile
volrefnum setVref: topfile
openReadOnly: topFile ?error 132
GetFileInfo: topFile drop
GetType: topFile txType =
IF searchfile THEN
close: topFile drop
THEN
THEN
ResCode \ go until error found
UNTIL
ResCode
CASE
fnfErrOF
level ?dup
IF cr 1- 4 * spaces
33 tface ." End of directory" 0 tface
ELSE cr 33 tface ." End of contents listing"
0 tface gcurs -> curs remove: loadfile quit
THEN
ENDOF
nsvErr OF
cr ." There is no disk in drive number " vol . ENDOF
cr ." Error #" ResCode .
ENDCASE
remove: loadfile
;
0 value drive
: grepone
new: loadFile
txtype 1 stdget: topfile
IF
" Enter search string:" doInDlg
IF new: gpattern new: target
str255 -base count put: gPattern
cls grepinit
openreadonly: topfile ?error 132
searchfile
remove: loadFile
THEN
THEN
;
: grepd 0 -> level
drive " Enter search string:"
doInDlg if cls grepdir else drop then
;
1 menu filemenu
3 menu editmenu
7 menu grepmenu
: drive1 1 -> drive 5 uncheck: grepmenu 4 check: grepmenu ;
: drive2 2 -> drive 4 uncheck: grepmenu 5 check: grepmenu ;
: pron +print 7 uncheck: grepmenu 6 check: grepmenu ;
: proff -print 6 uncheck: grepmenu 7 check: grepmenu ;
: init
" grepmenu.txt" getmtxt
drive1 proff
;
Listing 2: 'grepmenu.txt' Menu Text file for Listing 1
APPLEMEN 1
"$14"
"About Neon..." about
"(___________" null
"RES" DRVR \ get desk accy names
"\\\"
fileMENU 256
"File"
"Quit" bye
"\\\"
editMENU 261
"Edit"
"(Cut/X" null
"(Copy/C" null
"(Paste/V" null
"\\\"
grepMENU 262
"Grep"
"Grep one" grepone
"(___________" null
"Grep all" grepd
"Drive 1" drive1
"Drive 2" drive2
"Printer on" pron
"Printer off" proff
"\\\"
xxx
Listing 3: Example for directly accessed scroll bars in NEON
\ by Phil Barnard, Launceston, Tasmania, Australia.
\
\ actFW added since it is no longer contained in NEON 2.0
\ (J. Langowski)
: actFW enable: menubar
4 1 do i enable: filemen loop
decimal initFont
;
0 value part#
:CLASS vsBar <super object
rect vsRect
var wPtr
Handle ctlHndl
\ initializes the scrollbar rectangle from the port rectangle
:M PUTRECT: ( wPtr -- )
put: wPtr
getRect: [ get: wPtr ]
2swap swap drop
3 pick 16 -
swap 2swap
put: vsRect
;M
\ instantiates vertical scrollbar in window, returning handle in ctlHndl
:M NEW: ( -- )
0 \ room for ctlHandle returned
get: wPtr +base \ window pointer
abs: vsRect\ scrollbar bounds rectangle
nullOSstr\ null Str255
256 makeint\ visible
0 makeint\ value
0 makeint\ min
0 makeint\ max
16 makeint \ procID for scrollbars
0 \ refCon
call NewControl
put: ctlHndl
;M
\ disposes of heap storage for the scrollbars
:M KILL: ( -- ) get: ctlHndl call DisposControl ;M
\ draws scrollbars on update events
:M DRAW: ( -- ) get: wPtr +base call DrawControls ;M
\ hilites the given part number
:M HILITE: { thePart -- }
get: ctlHndl thePart makeint call HiliteControl ;M
:M PUTMIN: ( min -- )
get: ctlHndl swap makeint call SetMinCtl ;M
:M GETMIN: ( -- min )
word0 get: ctlHndl call GetMinCtl I->L ;M
:M PUTMAX: ( max -- )
get: ctlHndl swap makeint call SetMaxCtl ;M
:M GETMAX: ( -- max )
word0 get: ctlHndl call GetMaxCtl I->L ;M
:M PUTVAL: ( val -- )
get: ctlHndl swap makeint call SetCtlVal ;M
:M GETVAL: ( -- val )
word0 get: ctlHndl call GetCtlVal I->L ;M
\ tests to see which part got hit and returns 0 or partcode in part#
:M TEST: ( -- )
word0 get: ctlHndl where: fevent G->L
call TestControl I->L -> part#
;M
\ tracks the mouse, executing part handler's default procedure while
mousedown
:M TRACK: ( -- partNumber or 0 on mouse-up )
word0 \ space for INT result
get: ctlHndl
where: fevent G->L\ mouse point in local coordinates
-1
call TrackControl
I->L
;M
;CLASS
window edWind
vsBar edBar
\ close activate draw content handlers
: fix <[ 4 ]> 'cfas null actFW cr null actions: fwind
close: edWind cls ;
: ok? depth . depth 0 > if . then rdepth . mdepth . ;
\ define scrollbar handlers
: showValue 100 50 gotoxy getVal: edBar . ;
: PUp getVal: edBar 5 - putVal: edBar showValue ;
: PDn getVal: edBar 5 + putVal: edBar showValue ;
: LUp getVal: edBar 1 - putVal: edBar showValue ;
: LDn getVal: edBar 1 + putVal: edBar showValue ;
: doThumb track: edBar drop showValue ;
: doPart ( part# -- )
case 20 of LUp endof
21 of LDn endof
22 of PUp endof
23 of PDn endof
129 of doThumb endof
drop
endcase
;
: makeEdfalse setDrag: EdWind
false setGrow: EdWind
2 241 510 340 put: tempRect
tempRect " ed" 0 true false new: EdWind;
: drawAll draw: EdBar ;
: contEd
test: EdBar
part#
if part# hilite: edBar
begin stilldown? while
part# doPart
repeat
0 hilite: edBar
then;
: actF become actFW cls ;
: actEd begin
next: fevent
if 2drop then
again;
\ close activate draw content
\ instantiate both windows & bar and display bar
: test makeEd
set: EdWind-curs
addr: edWind putRect: edBar
\ setup vsRect from owning window
new: edBar
0 putMin: edBar 100 putMax: edBar
0 putVal: edBar draw: edBar
<[ 4 ]> 'cfas null actEd drawAll contEd actions: edWind
<[ 4 ]> 'cfas null actF null null actions: fWind ;