jn163051@longs.LANCE.ColoState.Edu (Joel Nevison) (07/27/90)
Hi folks. I finally got USRLIB going, after fussing with a pc clone that apparently isn't configured correctly for the USRLIB program. (Crashed hard) Using libraries to make programs hidden, but globally accessible is great! I have a few programs that I access from redefined keys and I really don't need to modify them or even see their names in VAR. These are perfect candidates for library objects. Some observations: 1)I had to send my directory to the pc in binary mode, but had to receive the library back in ascii. 2)The library detaches itself whenever I do a system halt (ON C). 3)I put some general utilities in a library that are used by a number of other programs and I noticed that the other programs can't use the library routine unless I edit them after the library has been attached. (Ditto with key definitions) 4)If I make more than one library they can't call each other's routines. 5)I saved about 400 bytes by putting 6k of stuff into a library. Some questions: 1)Does anybody know of any ways to work around or minimize the above phenomena? Especially 3 and 4 above. 2)I have not hooked up to the hp bulletin board, is there any info regarding USRLIB that I'm missing? Any other good stuff from there that hasn't made it to comp.sys.handhelds or the mailing list? 3)what kind of things are others out there doing with libraries? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Substitution mass confusion / Joel Nevison | | Clouds inside my head / jn163051@longs.lance.colostate.edu | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
prestonb@hpcvra.CV.HP.COM (Preston Brown) (07/27/90)
2)The library detaches itself whenever I do a system halt (ON C). Include an object named $CONFIG in the library which has the attach command. The $CONFIG will be executed whenever a system halt is executed. Preston
daveo@hpcvra.CV.HP.COM (Dave Ochs) (07/28/90)
>3)I put some general utilities in a library that are used by a number > of other programs and I noticed that the other programs can't use > the library routine unless I edit them after the library has been > attached. (Ditto with key definitions) > >4)If I make more than one library they can't call each other's routines. ... >1)Does anybody know of any ways to work around or minimize the above > phenomena? Especially 3 and 4 above. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >| Substitution mass confusion / Joel Nevison | >| Clouds inside my head / jn163051@longs.lance.colostate.edu | >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ These two questions are related. When you enter or edit a program, the program is parsed and compiled as it is created from the edit line. More specifically, references to other objects may be compiled in several forms depending on the current state of the calculator WHEN THE PROGRAM IS COMPILED. If your program is \<< abc \>>, the compiler first looks for an object named 'abc' in the current directory, then it looks for an object 'abc' in any libraries attached to the current directory. If no matches are found, the same search occurs in the parent directory, then its parent, etc. until you reach HOME. If a user object is found (or no match is found), the reference is stored as a name (which will be evaluated at run time). If an object in a library is found, the reference is stored as an XLIB name. At runtime, the specified XLIB object is searched for ... if it isn't there, the program will error. In question 3 above, you must recompile each program that references an XLIB object in order to change the variable names into libarary XLIB names. The following program, which I will call COMPDIR, will recompile each object in the current directory by converting each into a string and then back again. \<< VARS OBJ\-> 1 SWAP START DUP RCL \->STR OBJ\-> SWAP STO NEXT \>> It will be easiest if you have a $CONFIG program for each library of the form \<< 800 ATTACH \>>, where 800 is the library id; otherwise you will need to re-attach the library every time the HP48 warmstarts (which occurs after you store a library in a port). The $CONFIG program runs each time the calculator warmstarts, saving you the bother of re-attaching. THE INSTRUCTIONS BELOW ASSUME THAT YOUR LIBARIES AUTO-ATTACH. It is also possible to have two libraries refer to each other. An example would probably make it clearest. I will create two libraries, ALIB and BLIB. After debugging the programs, the objects that will in each library should be moved into separate directories (e.g. directories 'A' and 'B'). The following procedure works ... it is assumed that you already know how to transfer directories/libraries in binary form, etc. 1. Transfer directory A to your PC, and create library ALIB with 'usrlib'. References in ALIB to routines in ALIB are now XLIB names. 2. Transfer ALIB to your HP 48, and store it in port 0. Turn your HP48 off and on (it will warmstart and clear the stack). 3. Run COMPDIR on the B directory. References in directory B to routines in ALIB are now XLIB names. 4. Transfer directory B to your PC, and create library BLIB with 'usrlib'. References in BLIB to routines in BLIB or ALIB are now XLIB names. 5. DETACH and PURGE library ALIB from port 0 (you will probably want to remove the user variable version too). 6. Transfer BLIB to your HP 48, and store it in port 0. Turn your HP48 off and on. 7. Run COMPDIR on the A directory. References in directory A to routines in BLIB are now XLIB names. 8. Transfer directory A to your PC, and create library ALIB with 'usrlib'. References in ALIB to routines in ALIB or BLIB are now XLIB names. 9. Transfer ALIB to your HP 48, and store it in port 0. Turn your HP48 off and on. Some thoughts: - Don't mess with the A or B directories while doing this procedure, since XLIB names depend on variable order within the directory, among other things. - Neither library can be completely functional alone, since they each refer to the other, so why have two? - It is MUCH easier to create "nested" libraries, where lib B uses routines from lib A, lib C uses routines from libs A and B, etc. It is also much easier to remember their relationship. A can be used independently, B requires A, C requires B and A, etc. - Enough already. Dave Ochs daveo@hp-pcd.hp.com
wscott@ecn.purdue.edu (Wayne H Scott) (10/30/90)
When are Macintosh owners going to have a version of UsrLib?
Has someone considered working on that?
An ugly port with no windows would be fine.
I'll do it, if someone gives me the source. :)
--
_______________________________________________________________________________
Wayne Scott | INTERNET: wscott@ecn.purdue.edu
Electrical Engineering | BITNET: wscott%ecn.purdue.edu@purccvm
Purdue University | UUCP: {purdue, pur-ee}!ecn.purdue.edu!wscott