Library Trouble
garth r sweet
I've noticed a couple of times that when I go to my libarary menu,
that a library name is duplicated. It's happened maybe 3 times now that I
noticed and all 3 times the library has been FMLIB, (the file manager by
James Donnelly (I think) that comes with the HP cable kit). Anyone have
any suggestions, (BTW the library IS attached to HOME).
My 2nd bit of trouble is that unless I attach a libarary from my
HOME directory I absolutly cannot get rid of it, is there a special trick?
IE I'm in a direcotory called MATH, and I have a library (# 1234) here's
what I do (I hope I don't screw this up because I'm writing from
memory).
Level 3 ...actual library
Level 2 :0:1234
Level 1 :0:1234
I do an ATTACH, and then a STO, then a OFF/ON.
Now by library should be attached to the directory MATH.
To get rid of it I do the following
Level 2 :0:1234
Level 1 :0:1234
I do a DETACH then a PURGE, and I get an ERROR LIBRARY IN USE.
(BTW Assume I made sure the old library variable wasn't in LAST STACK
etc.)
I try from the HOME directory and get the same thing, what am I doing
wrong? This works fine if I do the attach from my HOME directory.
+---------------------------+-------------------------------------------------+
+ name : Garth Sweet + Ultra-Mini HP 48 FAQ +
+ email: sw...@ug.cs.dal.ca + +
+ phone: 902-865-8987 + FAQ = (F)requently (A)sked (Q)uestions +
+---------------------------+-------------------------------------------------+
+ Q: Where can I get HP 48 stuff? A: EduCalc 1-800-535-9650 24hrs (Can/USA) +
+ Q: Where can I ftp HP 48 files? A: seq.uncwil.edu has a ton of stuff +
+ Q: How do I get files to my HP? A: You need a cable, check real FAQ +
+ Q: Where is the real FAQ? A: At seq.uncwil.edu of course! +
+ Q: What's FTP anyway? A: Mail me! +
+ Q: How do I get help on my HP? A: Post questions. We don't bite. *SMILE* +
+-----------------------------------------------------------------------------+
Steve VanDevender
My 2nd bit of trouble is that unless I attach a libarary from my
HOME directory I absolutly cannot get rid of it, is there a special trick?
IE I'm in a direcotory called MATH, and I have a library (# 1234) here's
what I do (I hope I don't screw this up because I'm writing from
memory).
Level 3 ...actual library
Level 2 :0:1234
Level 1 :0:1234
I do an ATTACH, and then a STO, then a OFF/ON.
Now by library should be attached to the directory MATH.
You cannot ATTACH a library before it has been initialized by
turning the calculator on or warm-starting. Most libraries these
days seem to auto-attach themselves to HOME as part of their
initialization (a library author can write a custom configuration
routine for his library).
To attach a library to a particular directory, first turn the
calculator off, then on, then go to the desired directory and
ATTACH it.
--
Steve VanDevender ste...@greylady.uoregon.edu
"Bipedalism--an unrecognized disease affecting over 99% of the population.
Symptoms include lack of traffic sense, slow rate of travel, and the
classic, easily recognized behavior known as walking."
william j. levenson
install libraries so I'll try to explain:
Most libraries have a bit of code that is automatically executed at each
warm start that attaches the library to the HOME directory. In this
case, all you have to do is recall the library to the stack, type 0, 1,
or 2 (depending on which port you want to store it in) and hit STO. Then
turn the calc off and on. You should see the calculator do a warm start
when it comes on (the same as hitting ON-C). Your library should now be
attached.
Garth...If what you did ATTACH and then STO, you did it out of order.
And if the library has the CONFIG code I spoke of, I'm not sure what
happens if you attach it to another directory yourself but what I suspect
has happened to you is you have stored several copies of the library in
you port and they have self attached to the HOME directory. That would
explain why you cannot DETACH them from the from your MATH directory.
If the library has no CONFIG code tht self attaches, you must attach it
yourself to the directory of your choice (1 library per directory, except
for the HOME directory, which takes any number of libraries). Attach
AFTER you store it. You must then detach from that directory when you
wish to purge the library.
To see if you have multiple copies stored in your port, push left-shift
LIBRARY PORT0 (or whatever port you have) and look at the contents of
that port, or alternately, push left shift MEMORY NXT 0 PVARS to see what
is in port 0.
I hope this helps
Bill Levenson
Daniel B. Kirkland
It is possible to have a library ATTACHED to more than
one directory (for example your HOME directory and some
subdirectory). If so the library must be DETACHED from
each directory that it is ATTACHED to.
This can be checked by using the LIBS command on the
second page of the MEMORY menu. It will return a list
of all the librarys ATTACHED to the current directory.
(there can only be one library ATTACHED to any subdirectory)
Also, make sure the library is not referanced by the HP.
(a copy of the library on the stack or in LAST STACK,
LAST ARG, LAST CMD)
Most libraries will automaticly ATTACH themselves to the
HOME directory when they are stored in a port and the HP
is turned off and back on again. And seeing that a library
that is ATTACHED to your HOME directory, is also visible
in any subdirectory. It does not make much sense to have
a library ATTACHED to both your HOME directory and a
subdirectory.
To avoid this problem, first store the library in a port,
then turn the HP off and back on again.
Second, DETACH the library from your HOME directory.
Then ATTACH the library to the desired subdirectory.
(the library will then be visible only in that directory
and all of its subdirectories.)
THERE IS ONE PROBLEM!
Many (most?) libraries will reattach to your HOME directory
at the next warmstart.
(Like when you store another library)
So the library may be ATTACHED to two directories anyway.
There are some programs (libraries) avaliable that will help
to avoid this problem.
(config aborting or config supressing libraries)
(somewere at seq.uncwil.edu)
(sorry I can't tell you exactly were)
hope this is of some help!
dan k
Douglas R. Cannon
>Most libraries will automaticly ATTACH themselves to the
>HOME directory when they are stored in a port and the HP
>is turned off and back on again. And seeing that a library
>that is ATTACHED to your HOME directory, is also visible
>in any subdirectory. It does not make much sense to have
>a library ATTACHED to both your HOME directory and a
>subdirectory.
So, in my opinion, it does not make much sense to have any library attached
to any directory but HOME. My HP ends up doing a warm start every other
day or so, so all my libs are suddenly attached to HOME.
Does anybody really use a lib that is attached to a sub-directory? I wouldn't
want it unless I could have it attached to the sub-directory, and not HOME.
Just my $0.02 (maybe less...)
Doug Cannon
william j. levenson
probably so that the user can attach the library to whatever directory he
desires. This might be advantageous if you only wanted to be able to run
a certain library from a certain directory. You can change the $CONFIG
of a library bydissassembling a library wihth the <-LIB-> library, change
the $CONFIG routine (or delete it) and reassemble the library. This
should work with most libraries. Just make sure that the $CONFIG routine
can never error or you'll get yourself into trouble.
Just my thoughts
Bill Levenson
Douglas R. Cannon
>I HAVE seen libraries that intentionally do not self attach. This is
>probably so that the user can attach the library to whatever directory he
>desires. This might be advantageous if you only wanted to be able to run
>a certain library from a certain directory.
True, but even a library that has no config object (and thus does not
intentionally attach itself to the HOME directory) will be automatically
attached to the HOME directory at the next warm start.
So, if you want to only execute certain library functions from a certain
directory, then you would attach that library to that sub-directory. Then,
those library functions would only be visible in that sub-directory. However,
at the next warm start the library is attached to the home directory (and
also stays attached to your sub-directory) and now your library commands are
visible everywhere.
The only solution that I see (with my limited understanding) is to create
a library that expressely detaches itself from the HOME directory at each
warm start. This is great unless the user actually WANTS it to be attached
to the HOME directory.
Heck, I dunno. Any other thoughts? It makes this whole attach-detach
thing look pretty useless to me since all libraries end up being attached
to the HOME directory eventually. Am I missing something?
Doug
william j. levenson
libraries that don't have $CONFIG files. Unless I'm doing something
wrong. I took out the $config routine from one of my libraries and used
<-LIB-> to create a new library. It did not attach itself to anything.
When I attached it to a subdirectory, it behaved as I expected it to...It
only appeared in the LIBRARY menu when that directory was active.
One thing did surprise me though. When I did a warm start, the library
without the config routine was still attached to the subdirectory. I
thought I would have to reattach it after a warm start???? Anyone...
Doug, I'm not sure why you're libraries without config routines are
attaching to the HOME directory. What are you using to create the
library? Maybe it's putting a config routine in there for you???
Bill Levenson
fatri
Or maybe he uses some Library Aborter, so that instead of running
the $CONFIG code , it just attach the library, even if there is no
$CONFIG in the library.
This is just an opinion.
Detlef Mueller
> [..]
>One thing did surprise me though. When I did a warm start, the library
>without the config routine was still attached to the subdirectory. I
>thought I would have to reattach it after a warm start???? Anyone...
Subdirectory ATTACHments are permanent and are not removed on warmstarts (like
the HOME ATTACHes). You can even purge a library if it's ATTACHed to a subdir
only.
Bye,
8-Detlef
--
+------------------------------------+--------------------------------------+
|`What a depressingly stupid machine'| Detlef Mueller |
| -- Marvin | det...@dmhh.hanse.de |
+------------------------------------+--------------------------------------+
Charles Patton
>>
>> I've noticed a couple of times that when I go to my libarary menu,
>>that a library name is duplicated.
>> My 2nd bit of trouble is that unless I attach a libarary from my
>>HOME directory I absolutly cannot get rid of it, is there a special trick?
>> I do a DETACH then a PURGE, and I get an ERROR LIBRARY IN USE.
>> (BTW Assume I made sure the old library variable wasn't in LAST STACK
>> etc.)
>> I try from the HOME directory and get the same thing, what am I doing
>> wrong? This works fine if I do the attach from my HOME directory.
All of these difficulties revolve around the related issues of storing/purging
configuring, and attaching/detaching libraries.
Since it is difficult to understand remember syntax without semantics, and since
no one has ever (to my knowledge) made clear to the public at large (or even to
developers, for that matter) what was the _intended_ usage of the attach/configure
options are, it is not surprising that it all remains a little mysterious. So,
here goes..
** What is the ATTACH/DETACH stuff?
During the design of the RPL system in '83-'84, we envisioned that plug-ins could,
and would, serve several distinct functions and and have correspondingly distinct
needs.
One such function would be to provide a unified, customized, "application environment"
dedicated to a single purpose and providing both functionality and "templates" in
the ROM. A good example of this would be a spreadsheet application with ready-made
forms in ROM which could be customized with minimal RAM usage (...think about what
that entails!...) Such an application would clearly require RAM resources dedicated
to it, provide for customized interpretation of keywords, commands, etc., and yet
not interfere with other such applications (even copies of itself!) From this
idea we developed the notion of a CONTEXT - a RAM/ROM pair consisting of a ROMPART
and a RAMPART linked together. From the usual user's point of view, this is simply
a subdirectory, but from a library's ( a.k.a ROMPART's ) point of view, the
subdirectory is to be considered an extension of the library, and could contain data
and other RAM resources necessary to the operation of the application.
In this kind of "application environment" the user would not "run a program" but rather
change to the relevant context (subdirectory) where all operations would be interpreted
according to the information in that context, without conflicting with other "application
environments" assignments or resources. I know of no such "application environments"
currently extant for the '48, although all the tools necessary to make them are around.
The ATTACH keyword keyword joins a subdirectory (RAMPART) with a library (ROMPART) to
create such an interpretation context, but if the resources are not used by the library,
the advantages (other than avoiding conflicts) are rather small. Since the subdirectory
"belongs" to the library after attachment, the attachement is not broken until the system
is specifically directed to do so (hence the DETACH keyword.)
Obviously, it would be advantageous to allow for a single library to "own" any number of
subdirectories, say one for each spreadsheet, document, or whatever. On the other hand,
it would defeat the idea of conflict-avoidance to have multiple libraries own (and hence
be required to share) a given sub-directory. Thus only one library can be attached to a
given sub-directory.....except the "HOME" directory (a.k.a. SYS RAMROM PAIR)....
Which brings me to a second function envisioned for libraries: localization and its relatives.
We anticipated the need to produced multi-lingual versions of the machine as well as
providing for system-wide re-definition of high-level aspects of the machine. In order
to be able to be re-defined on-the-fly, these aspects of the machine (Hash tables for
converting text to and from commands, and Message tables for defining standarized messages)
must, at the very least, have "hooks" in RAM.
These "hooks" for Hash and Message tables are provided in the ROMPART of the
HOME directory. Unlike subdirectories, the HOME directory can have multiple
libraries "attached" (although "attached" here cannot have same expectation
of exclusive ownership) and with each library attachment, a slot for the
library's Hash and Message table is allocated and filled, by default, with
the library's own Hash and Message tables. These, however, can be overwritten
with alternative versions at a later time.
A moment's thought will reveal to you that if you plug in two libraries, one
to localize the machine to, say, Finnish, and the other to localize it to Spanish,
at most one of these libraries can succeed. They are obliged to "compete" over the
fixed resources, and this competition normally occurs at warmstart, when a complete
inventory of libraries is taken, the HOME ROMPART is cleared and re-created anew,
and each library is asked, in turn, if there is anything it would like to do.
Another kind of library we expected was a system extension attempting to be as much
like the system (including providing for localization, etc.) as possible. They
would attach themselves to the HOME directory and do little else, simply extending
or revising the keyword set. Such libraries have the greatest potential for conflicts
and unexpected side-effects, since the system is tightly integrated and consistency
needs to be maintained, but there is no mechanism for negotiation at the time of
the configuration poll.
A final kind of library we expect was the "run-of-the-mill" kind with a few utilities
on board, but nothing fancy. Note that it is not necessary to have a library
attached either to the HOME directory or to any sub-directory for the purposes of
finding, executing, or displaying any word in any library found during the last
inventory of libraries. The only aspect of normal library operation which requires
an attachment is the process of automatically associating a library object with
a typed-in name (so-called "compilation".) This process, however, is modulated by
things other than library attachment. In particular, any object in the current
directory with takes precedence over any library object of the same name, no matter
where attached.
We expected these run-of-the-mill libraries, then, to take routes, other than attachement,
to providing access to their utilities, routes which have fewer potential conflicts. One
such method would be to let the user attach the library as desired. Another method would
be for the library, in response to the configuration poll, to create suitably named variables
in RAM, each variable consisting of a "rom-pointer" to one of the library words.
In summary...
We expected that application-environment libraries would take this opportunity
to check that there was at least one of its environments around, and if not,
to create one... AND THAT'S ALL!!
We expected that localization libraries would redefine the relevant Hash and Message
tables, with the "winner" of any competition being determined by the order in which
they are polled as to their preferences.
We expected system-extension libraries, carefully designed and few in number, to
attach themselves to the HOME directory in the same manner as the main system libraries,
thus allowing localization of these system extensions.
We expected the bulk of the libraries to not attach themselves anywhere at all, but
either allow the user to attach as desired, or create RAM-based access to their
contents, or follow some other convention which didn't require attachment.
What has occurred, however, is that the bulk of the libraries, following the
system library examples, and having little other guidance from our end of the street,
have chosen to attach themselves automatically to the HOME directory insuring
a maximum of confusion and conflicts.
**What's the difference between attaching and configuring?
As noted above, the system takes an inventory of libraries in the machine at various
times (such as, whenever the machine is turned on.) Because we need to keep close track
of various aspects of the libraries, including their location, only libraries in the
controlled-access area of the ports (port0, port1, and port2) are inventoried. For this
reason, you must store a library in one of the ports in order to have its existence
recognized by the machine.
All libraries which have been found at the last inventory are polled when the machine is
being re-configured. This happens, for example, whenever a new library is found, or an
old one is found missing, during the inventory. This poll allows the libraries to configure
themselves, as described above. During this time they may, or may not, attach themselves
to a directory or subdirectory.
*******************************************************
** Charles M. Patton **
** **
** char...@cv.hp.com **
** the usual disclaimers apply **
*******************************************************