From helens!shelby!rutgers!usc!sdd.hp.com!hplabs!hpl-opus!hpnmdla!darrylo Thu Jul 12 04:06:58 PDT 1990 Status: RO Article 2135 of comp.sys.handhelds: Path: helens!shelby!rutgers!usc!sdd.hp.com!hplabs!hpl-opus!hpnmdla!darrylo >From: darrylo@hpnmdla.HP.COM (Darryl Okahata) Newsgroups: comp.sys.handhelds Subject: Unix-link PATH searching for the HP-48SX Message-ID: <1570006@hpnmdla.HP.COM> Date: 11 Jul 90 20:20:39 GMT Organization: HP Network Measurements Div, Santa Rosa, CA Lines: 106 Here is yet another method for accessing programs in other directories. It introduces the concept of a Unix-like "PATH" variable, which gives a list of directories to search. This program, called "EXEC", works just like Jan Christiaan van Winkel's (jc@atcmp.nl) SVC function, except that it will search multiple paths. You enter the arguments to your function on the stack, enter the name of your function (e.g., 'MYFUNC'), and then execute "EXEC". To use it, you need a variable called "EXECPATH" in the HOME directory, and this variable should contain a list of directory paths (in list form). For example, one possible value for EXECPATH could be: { { SYS } { ETC } { ETC ETC } HOME { } } This causes EXEC to search the following directories for functions: { SYS } { ETC } { ETC ETC } HOME the current working directory Note that HOME does not have to be in a list (for that matter, directory paths with only one name do not have to be in a list, but it makes it easier to debug). Also note that placing HOME in this list is redundant; as everything searches HOME, HOME should never be placed in this list. Notes/problems: 1. EXECPATH does not necessarily come from the HOME directory. Strange things will happen if EXECPATH resides in the "current directory" or in one of the directories given by EXECPATH. 2. The name "EXECPATH" is too long. It should be shortened to save time and space. 3. EXEC is slow. The overhead in using EXEC is at least 0.1 sec (I don't know what the overhead in using SVS is, however). The actual overhead depends on how large and complex your EXECPATH happens to be. EXEC should be rewritten in assembly language. It should, perhaps, keep more things on the stack and not in local variables. 4. EXEC is big (240 bytes). 5. If "{ }" is not contained in the EXECPATH list, the current working directory will not be searched. 6. Some people will want to remove the code that handles "{ }" (searches the current working directory). This will increase speed and decrease program size. To do this, replace the lines that say: IF DUP SIZE 0 == THEN DROP cwd END EVAL with: EVAL 7. Searching HOME is redundant. -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@hp-sde.sde.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day. =============================================================================== Store the following in a variable called "EXEC" in the HOME directory. Checksum: #19683d ------------------------------------------------------------------------------- %%HP: T(3)A(D)F(.); \<< PATH EXECPATH SIZE 1 \-> cwd end i \<< DO EXECPATH i GET IF DUP SIZE 0 == THEN DROP cwd END EVAL IF IFERR RCL 1 THEN IF 'i' INCR end > THEN cwd EVAL " :NOT FOUND" + DOERR END 0 0 END THEN cwd EVAL EVAL 1 END UNTIL END \>> \>> From helens!shelby!decwrl!elroy.jpl.nasa.gov!sdd.hp.com!hp-pcd!hpcvia!scottb Thu Jul 12 17:04:36 PDT 1990 Status: RO Article 2145 of comp.sys.handhelds: Path: helens!shelby!decwrl!elroy.jpl.nasa.gov!sdd.hp.com!hp-pcd!hpcvia!scottb >From: scottb@hpcvia.CV.HP.COM (Scott_Burke) Newsgroups: comp.sys.handhelds Subject: Re: Unix-link PATH searching for the HP-48SX Message-ID: <31210042@hpcvia.CV.HP.COM> Date: 12 Jul 90 16:13:43 GMT References: <1570006@hpnmdla.HP.COM> Organization: Hewlett-Packard Co., Corvallis, Oregon Lines: 119 Here is a re-write of EXEC, a program written by Darryl Okahata that implements path searching on the 48sx. It addresses all of the unresolved issues Darryl mentions in his posting. It also fixes a bug, is half the size, and preserves the speed of the original. Entry syntax: Enter arguments and name of function on the stack. Then execute 'EXEC'. (I assign EXEC to the left-shifted EVAL key, since I never use ->Q.) The variable 'TRAIL' must be present in the HOME directory. It should be a list of all "leaves" in the directory tree. To understand this further, imagine a simple directory structure: (where W1, W2, W3, and GAMES are the "leaves") HOME /\ WORK PLAY / / \ \ W1 W2 W3 GAMES The purpose of 'EXEC' is to execute functions contained in the non-current sub- directory. If a function resides in W2, then 'TRAIL' must contain the list: { HOME WORK W2 } for that function to be findable. However, it is only neces- sary to include the path { HOME WORK } in 'TRAIL' if you SPECIFICALLY want to search { HOME WORK } BEFORE any of W1, W2, or W3. In that case, put the list { HOME WORK } BEFORE { HOME WORK W1 } etc. in the list 'TRAIL'. In the same vein, it is only necessary to include HOME or { HOME } in 'TRAIL' if it should be searched BEFORE other subdirectories. Thus, a normal 'TRAIL' variables for the above structure might be: { { HOME WORK W1 } { HOME WORK W2 } { HOME WORK W3 } { HOME PLAY GAMES } } In Darryl's version of EXEC, he allowed the inclusion of a blank list { } to represent the current working directory. I have two approaches to that problem. First (the elegant way): The current subdirectory ought to be one of the full lists in 'TRAIL', so nothing special needs to be done. Second (the other way): IF YOU REQUIRE THAT THE CURRENT DIRECTORY BE SEARCHED FIRST, then include the optional line of code shown in the listing below. That line checks for the presence of the function in the current directory BEFORE it does anything else. However, it slows down the code, and makes it bigger, so I don't include it in my personal version. Here are solutions/workarounds to some of Darryl's comments: > 1. EXECPATH does not necessarily come from the HOME directory. Strange > things will happen if EXECPATH resides in the "current directory" or > in one of the directories given by EXECPATH. I require that 'TRAIL' be present in the HOME directory. It's not a big deal. If you don't like to clutter your HOME directory, I suggest you implement the { HOME MAIN } work-around mentioned in a previous note, where HOME contains a whole bunch of garbage, but MAIN is the normal main working directory and right-shift ' (HOME) is assigned to << MAIN >>. > 3. EXEC is slow. The overhead in using EXEC is at least 0.1 sec (I > don't know what the overhead in using SVS is, however). The actual > overhead depends on how large and complex your EXECPATH happens to > be. EXEC should be rewritten in assembly language. It should, > perhaps, keep more things on the stack and not in local variables. With a large 'TRAIL' list, you're going to see a performance hit, even in assembly. Local variables vs. stack operations have negligible speed differences in the case of the type of code we're writing here. It's only when you're doing things like filtering lists of tens or hundreds of objects that it's noticeably faster to do it all on the stack. Therefore, in many cases, it's faster to use local variables because debugging is SO MUCH SIMPLER. > 4. EXEC is big (240 bytes). Make that 107 bytes (or 124.5 with the current directory check first) Oh yeah, the bug in the other version... If a function calls other routines it expects to be in the same directory as it is executing from (so much for grammar), Darryl's version crashes, because it has already returned to the current working directory BEFORE it executes the function it recalled to the stack. This is a matter of personal preference, because it occurs to me that someone may WANT to execute the function in the current directory; it may create a global variable that they may want to use. It's not too hard to modify the code to work that way, but mine executes everything in it's original directory and THEN returns to the current one. While I'm thinking of possible bugs, let me mention that my code REQUIRES the LASTARGS flag to be CLEAR (i.e., enabled). To do this, execute -55 CF. The reason is that when I do a RCL to try to get the function code, if the global variable is not present, RCL returns the name of the function for another try. If LASTARGS is SET (i.e., disabled), then the function name will have to be replicated each loop iteration or stored in a local variable. I don't change flag -55 because that is usually an impolite thing to do; I'd store the flags and recall them, but we're talking about way too much overhead there for such a small function. Here's the code for EXEC. << PATH -> p store the current working path << [optional line:] VARS OVER POS { EVAL } IFT check the current directory first 1 TRAIL SIZE FOR i loop from 1 to the size of TRAIL TRAIL i GET EVAL extract the next path from TRAIL IFERR RCL try to RCL the function code to stack THEN if we fail, don't do anything ELSE EVAL p EVAL KILL END else execute function, reset path, end NEXT p EVAL reset path; function wasn't found >> >> Scott Burke scottb@hpcvia.cv.hp.com or 503-750-3978 From helens!relgyro!shelby!rutgers!usc!sdd.hp.com!hp-pcd!hpcvia!scottb Thu Jul 12 17:04:47 PDT 1990 Status: RO Article 2146 of comp.sys.handhelds: Path: helens!relgyro!shelby!rutgers!usc!sdd.hp.com!hp-pcd!hpcvia!scottb >From: scottb@hpcvia.CV.HP.COM (Scott_Burke) Newsgroups: comp.sys.handhelds Subject: Re: Unix-link PATH searching for the HP-48SX Message-ID: <31210043@hpcvia.CV.HP.COM> Date: 12 Jul 90 17:51:05 GMT References: <1570006@hpnmdla.HP.COM> Organization: Hewlett-Packard Co., Corvallis, Oregon Lines: 8 Oops, small typo. In the optional line of the previous program (EXEC), insert a KILL after the EVAL in the list for the IFT. That way, bad things won't happen if you are going to use the option to search the current directory first. Ho hum. Too early in the morn. Scott Burke scottb@hpcvia.cv.hp.com or 503-750-3978