chips@tekchips.UUCP (Chip Schnarel) (03/31/86)
There is an inherent problem with the new hierarchical file system (HFS)
Note: I say problem and not "bug". What I am talking about is part of
what causes many programs fail under HFS, and that is the the nature of HFS
itself. Let me explain, and in the end I want to offer a solution.
The reason for the HFS is to hide the number of files and file information
from the finder. This is done both to organize files better and because
the finder has performance problems with more than a few files. However, when
the file information is hidden from the finder, it is hidden from the
application as well. This is what is causing us all the headaches. Programs
can't find other files, libraries, resources that they need because the
information as to where the files are is hidden by the file system.
One solution to the problem is to make every program search up and down the
file folder structure until it finds the file or exhausts the system. This
solution is not very efficient at best.
I ran across a better solution this last weekend when I attempted to get
the RASCAL programming environment to work with the new ROMs and my QuickDrive.
The first thing that I noticed was that the compiler could no longer find the
include (uses) files and that the linker could not find the libraries. After
contemplating throwing everything into the root directory (yes, I'm going to
fall back to UNIX terminology. The solution is borrowed from UNIX too.)
I finally decided to read the instructions. RASCAL has anticipated the problem
and has implemented a workable solution. Put simply, there is a string
resource which tells the RASCAL compiler where the libraries are. Just edit
the resource to give the explicit location of the library folder. RASCAL now
works fine. I have one minor complaint: the "path" search string should be
part of the configuration dialog.
Example:
Libraries:SomeVolume:SomeFolder:SubFolder:LibraryFolder
Utilities:SomeOtherVolume:DifferentFolder:FolderInFolder:...:UtilitiesFolder
Now Unix hackers will tell you, correctly, that it is bad practice to hard
code this sort of info into the application. What happens when you run the
app. on another system with the Libs in a different place? Here is a use
where resources show thier strength! The info is not "hard coded in" it is
an editable part of the application configuration. A reasonable solution I
believe.
Now some controversy: Should the form of these "path" resources be STANDARD?
I think so. Perhaps there should be a PATH resource type. On the other hand,
STR seems to work just fine.
Also some sort of relative addressing needs to be included.
Example:
PrintFile:CurrentFolder:SomeSubFolder:TempFileFolder
^^^^^^^^^^^^^--relative address
PrintFile:ParentFolder:SomeSubFolder:TempFileFolder
^^^^^^^^^^^^--relative address
Wild cards may also be useful.
OK, discussion time. This is not my idea, but I think it's a good one. Anyone
else have comments?
Chip Schnarel
...!tektronix!tekchips!chipsdarin@ut-dillo.UUCP (Darin Adler) (04/02/86)
In article <184@tekchips.UUCP>, chips@tekchips.UUCP (Chip Schnarel) writes: > Now some controversy: Should the form of these "path" resources be STANDARD? > I think so. Perhaps there should be a PATH resource type. On the other hand, > STR seems to work just fine. > Also some sort of relative addressing needs to be included. > > Example: > PrintFile:CurrentFolder:SomeSubFolder:TempFileFolder > ^^^^^^^^^^^^^--relative address > PrintFile:ParentFolder:SomeSubFolder:TempFileFolder > ^^^^^^^^^^^^--relative address HFS has, built into it, a relative addressing method. The following are Unix pathnames listed with the HFS quivalent. Unix HFS ---- --- /disk/file disk:file file file directory/file :directory:file /d1/d2/d3/file d1:d2:d3:file d1/d2/d3/file :d1:d2:d3:file . no equivalent ./file :file ../file ::file ../../file :::file directory/../file directory::file One thing that is missing on the Mac is a true PATH. In other words, more than one directory (folder) to search for files. If you want to use a "PATH" resource type as a standard, I would recommend that it be a string list (STR#) rather that a single string. Maybe someone wants to write some code the does what is necessary to search such a path??? > Wild cards may also be useful. Perhaps ... -- Darin Adler {gatech,harvard,seismo}!ut-sally!ut-dillo!darin "...'cause they don't go for what's in the book and that makes 'em bad..." Frank Zappa
barad@brand.UUCP (Herb Barad) (04/02/86)
In article <184@tekchips.UUCP> chips@tekchips.UUCP (Chip Schnarel) writes: >I finally decided to read the instructions. RASCAL has anticipated the problem >and has implemented a workable solution. Put simply, there is a string >resource which tells the RASCAL compiler where the libraries are. Just edit >the resource to give the explicit location of the library folder. RASCAL now >works fine. I have one minor complaint: the "path" search string should be >part of the configuration dialog. > >Example: > Libraries:SomeVolume:SomeFolder:SubFolder:LibraryFolder > Utilities:SomeOtherVolume:DifferentFolder:FolderInFolder:...:UtilitiesFolder > >Now Unix hackers will tell you, correctly, that it is bad practice to hard >code this sort of info into the application. What happens when you run the >app. on another system with the Libs in a different place? Here is a use >where resources show thier strength! The info is not "hard coded in" it is >an editable part of the application configuration. A reasonable solution I >believe. > >Now some controversy: Should the form of these "path" resources be STANDARD? >I think so. Perhaps there should be a PATH resource type. On the other hand, >STR seems to work just fine. I think that this approach is a good idea. Maybe a PATH resource in the system file (one that could easily be installed by unsofisticated users using some "PathEditor" application (i.e. don't force everyone to use ResEdit - some people will panic). Many applications can look to see if a PATH resource is defined for whatever it needs. Perhaps a PATH can be define for include files (for compiler applications). Or, a PATH might be defined for other types of data files that an application might need. This would allow a user to structure his/her HFS to their liking. If a PATH is not defined, then look in the root, some default directories, or in the current directory (more throwbacks to Unix). A PATH resource would be just one more way to allow (but not force) user's to customize their systems. -- Herb Barad [USC - Signal and Image Processing Institute] USENET: ...!sdcrdcf!usc-oberon!brand!barad or ...!{lbl-csam|trwrb|trwspp}!trwspf!herb or ...!{lbl-csam|trwrb|trwspp}!trwspf!brand!barad ARPANET: barad%brand@usc-ecl.ARPA
berry@tolerant.UUCP (David W. Berry) (04/03/86)
In article <184@tekchips.UUCP> chips@tekchips.UUCP (Chip Schnarel) writes: > >Example: > PrintFile:CurrentFolder:SomeSubFolder:TempFileFolder > ^^^^^^^^^^^^^--relative address > PrintFile:ParentFolder:SomeSubFolder:TempFileFolder > ^^^^^^^^^^^^--relative address Currently (As interpreted by the File System) Unix naming conventions are used for simplification. :Dir:File - refers to ./Dir/File ::Dir:File - refers to ../Dir/File Vol:Dir:File - refers to Vol:Dir/File Note that a leading ':' means path is relative to current folder. Absence of a leading ':' and presence of a later ':' indicates the first element is a Volume Name, not a Folder Name. File - refers to ./File :File - refers to ./File Note that in the above 'Dir:' really matches the pattern (Dir:)+ -- David W. Berry dwb@well.UUCP Delphi: dwb {ucbvax,pyramid,idsvax,bene,oliveb}!tolerant!berry I'm only here for the beer.
ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459) (04/03/86)
Chip Schnarel writes: > One solution to the [HFS] problem is to make every program search up and > down the file folder structure until it finds the file or exhausts the > system. This solution is not very efficient at best. > > [But in Rascal] there is a string > resource which tells the RASCAL compiler where the libraries are. Just edit > the resource to give the explicit location of the library folder. RASCAL now > works fine. > > Example: > Libraries:SomeVolume:SomeFolder:SubFolder:LibraryFolder > Utilities:SomeOtherVolume:DifferentFolder:FolderInFolder:...:UtilitiesFolder > > Now Unix hackers will tell you, correctly, that it is bad practice to hard > code this sort of info into the application. What happens when you run the > app. on another system with the Libs in a different place? Here is a use > where resources show thier strength! The info is not "hard coded in" it is > an editable part of the application configuration. A reasonable solution I > believe. I think a better solution is to use the path name if it exists, then fall back to exhaustive search (after warning the user?) if there's no path name or the files aren't there. Once the files are found, the application can update its own PATH resources. Alernatively, the user could be asked to point out the correct folder and then be given a choice of using this path once or permanently (i.e., reconfiguring).