Hi,
	Has anyone seen a virtual calculator message "Error: Undefined XLIB 
Name"? If so, what does it mean? Can the undefined name be found 
somewhere? I have looked at all the temporary files, and search doesn't 
find it. Can the virtual calculator be queried?

	Thanks for any help.

Alan Ferguson

Most likely something is trying to call a command that doesn't exist
because a library isn't installed.  Whatever you are trying to do is
calling a library command that isn't there.  (say 354h 15h--this means
library 354 in hex and the 15h command in the library)

I am not sure what you mean by "virtual calculator".  Are you running
the emulator or something?

TW

Tim,
	I used the term "virtual calculator" to represent the the emulator. It 
is not a real calculator, although I guess it acts like one! My HP48G+ 
program is about 1600 lines long, and there are 62 subroutines that are 
included in this program, each of about 10 - 50 lines long. So, it is a 
lot to check to see where a LIB call might be getting done (I do not 
make any LIB calls (except MAKEARRY?), except that I just use all the 
normal instructions - not LIB routines that I make up). I am checking 
all the subroutine files to see if I have defined a MAKEARRY instruction 
in one of them. I am mostly finished now, and will finish later today.

	I was away just after you & Jean-Yves gave me the answer to the 
MAKEARRY instruction. I did respond yesterday, but you may not have seen 
the response (stale thread, etc). But thanks immensely. I wouldn't have 
found it without your assistance. But, there is still something wrong in 
my converted HP48G+ program. I'll keep checking.

	It would be nice for the calculator to say what LIB name it can't find. 
Then, I might have a clue!

Alan Ferguson

timwessman@gmail.com wrote:
> Most likely something is trying to call a command that doesn't exist
> because a library isn't installed.  Whatever you are trying to do is
> calling a library command that isn't there.  (say 354h 15h--this means
> library 354 in hex and the 15h command in the library)
> 
> I am not sure what you mean by "virtual calculator".  Are you running
> the emulator or something?
> 
> TW
> 

"Alan Ferguson" <alanf@sympatico.ca> wrote in message 
news:UVQ6f.2679$Nj3.104817@news20.bellglobal.com...
> Tim,
> I used the term "virtual calculator" to represent the the emulator. It is 
> not a real calculator, although I guess it acts like one! My HP48G+ 
> program is about 1600 lines long, and there are 62 subroutines that are 
> included in this program, each of about 10 - 50 lines long. So, it is a 
> lot to check to see where a LIB call might be getting done (I do not

Why not make a program that uses ->STR on your programs
and searches for "XLIB"
It could then report to a text file a home level
in which path it found the text and which POS
DO you really mean that you do searching always MANUALLY
on a programmable machine, which can easily do recursion?

> make any LIB calls (except MAKEARRY?), except that I just use all the 
> normal instructions - not LIB routines that I make up). I am checking all 
> the subroutine files to see if I have defined a MAKEARRY instruction in 
> one of them. I am mostly finished now, and will finish later today.
>
> I was away just after you & Jean-Yves gave me the answer to the MAKEARRY 
> instruction. I did respond yesterday, but you may not have seen the 
> response (stale thread, etc). But thanks immensely. I wouldn't have found 
> it without your assistance. But, there is still something wrong in my 
> converted HP48G+ program. I'll keep checking.
>
> It would be nice for the calculator to say what LIB name it can't find. 
> Then, I might have a clue!
>
> Alan Ferguson
>
> timwessman@gmail.com wrote:
>> Most likely something is trying to call a command that doesn't exist
>> because a library isn't installed.  Whatever you are trying to do is
>> calling a library command that isn't there.  (say 354h 15h--this means
>> library 354 in hex and the 15h command in the library)
>>
>> I am not sure what you mean by "virtual calculator".  Are you running
>> the emulator or something?
>>
>> TW
>> 

Veli-Pekka Nousiainen wrote:
> 
> Why not make a program that uses ->STR on your programs
> and searches for "XLIB"
> It could then report to a text file a home level
> in which path it found the text and which POS
> DO you really mean that you do searching always MANUALLY
> on a programmable machine, which can easily do recursion?
> 

Well, this is an interesting idea. I do know which program the undefined 
XLIB is in. However, it is a program file, so I do not know what format 
the code is in, so searching for an undefined XLIB might not find 
anything? This error looks like it is a pre-run (load?) error, as the 
compiler doesn't give any errors. I do reference static variables (in 
the HOMEDIR) from this program. If one variable was missing, would this 
give an undefined XLIB error? I believe that I have defined them all.

If I run the program as a verb, then it doesn't run at all, just the 
hourglass stays on (sort of like when I didn't know how to do the 
^MAKEARRY instruction). If I set the same program up as a LIB program, 
then I get the undefined XLIB error. My program is about 22kB long. Is 
this too long for a LIB program? I still have about 20kB left after 
loading my program, so there is still some free memory.

Can I just assume the a program file is a text file, ans that the 
undefined value should appear in it somewhere. However, shouldn't this 
also appear in one of the temporary files, such as the *.lr file? If it 
is not defined after linking, then surely it will have a problem when it 
tries to load? I don't have a good understanding of binary file formats, 
or loadable file formats. If you can suggest something concrete to 
search on in a LIB file, I'll try it.

I'm trying to get an HP48G+ program to work on the HP48Gii. The compiler 
didn't like the MAKEARRY instruction, and Jean-Yves Avenard straightened 
me out on that issue. I was hoping that was the only issue, but it seems 
that it isn't! Maybe I'll get somewhere with a search program!

Thanks for your suggestions.

Alan Ferguson

> 
>>make any LIB calls (except MAKEARRY?), except that I just use all the 
>>normal instructions - not LIB routines that I make up). I am checking all 
>>the subroutine files to see if I have defined a MAKEARRY instruction in 
>>one of them. I am mostly finished now, and will finish later today.
>>
>>I was away just after you & Jean-Yves gave me the answer to the MAKEARRY 
>>instruction. I did respond yesterday, but you may not have seen the 
>>response (stale thread, etc). But thanks immensely. I wouldn't have found 
>>it without your assistance. But, there is still something wrong in my 
>>converted HP48G+ program. I'll keep checking.
>>
>>It would be nice for the calculator to say what LIB name it can't find. 
>>Then, I might have a clue!
>>
>>Alan Ferguson

On Mon, 24 Oct 2005 23:11:26 -0500, Alan Ferguson wrote:

> the compiler doesn't give any errors.

It is a run-time error, rather than a compile-time error.

> If I run the program as a verb, then it doesn't run at all,
> just the hourglass stays on.  If I set the same program up
> as a LIB program, then I get the undefined XLIB error.

The error means that a command was compiled into a reference
to a library function, but that when encountered during execution,
the library number (or the particular function number
within that library) could not be located.

This could mean that the library was not installed (into a port),
or that you might be attempting STO/RCL operations
on a variable name, then let that name be included
into the library.

When you run a set of programs collected into a user directory,
then they reference each other by name, and if a name 'MYFUNCTION'
is missing at run time, then encountering that name in a program will
leave the name on the stack (which may change what you expect to be
on the stack) and then continue with the remainder of the program.

OTOH, when you convert a directory into a library, names which refer
to objects included in the library are converted into library function
calls (ROMPTR or "XLIB name"), and if the library (or function) is not
available when one of those is encountered, the "Undefined XLIB Name"
error will occur instead.

An error might also occur if you intend to use a named variable
to store data, but you forget to omit that name from being
included in the converted library (you can not store data
into library functions, nor can you even use 'MYDATANAME' RCL
if the named data variable is later to be included in a library).

One problem with locating the mistake is that when directories
(containing named variables) are converted into libraries,
all of the variable names are replaced by numbers (library number
and function number), and you would not be able to search
the converted library for any trace of any original names.

However, source programs in SysRPL
would usually contain the word "ROMPTR" in all such places.

> Is 22kB too long for a LIB program?

No; one library can occupy up to one memory bank (128K) in 48G/49G.

> I'm trying to get an HP48G+ program to work on the HP48Gii.

Well, have any *built-in* library function numbers changed
between those models? (as they did between 48G and 49G;
in fact, some even changed type, from ROMPTR to FLASHPTR);
if so, perhaps look for those.

[r->][OFF]

John,
	I just noticed that my program creates quite a few local variables that 
are to be contained within the library. I guess that this is not 
possible, so I will go back to trying to debug the program as a verb 
program (a variable in the HOMEDIR hierarchy). That is how it worked 
originally. In addition, I did use someone else's code to power off the 
calculator from one of the programmable (soft) keys, and perhaps there 
is a library call in there that has changed in the newer calculator. I 
will check shortly.

	Thanks for the suggestions. I will continue trying to debug it as a 
variable named program.

Alan Ferguson

John H Meyers wrote:
> On Mon, 24 Oct 2005 23:11:26 -0500, Alan Ferguson wrote:
> 
>> the compiler doesn't give any errors.
> 
> 
> It is a run-time error, rather than a compile-time error.
> 
>> If I run the program as a verb, then it doesn't run at all,
>> just the hourglass stays on.  If I set the same program up
>> as a LIB program, then I get the undefined XLIB error.
> 
> 
> The error means that a command was compiled into a reference
> to a library function, but that when encountered during execution,
> the library number (or the particular function number
> within that library) could not be located.
> 
> This could mean that the library was not installed (into a port),
> or that you might be attempting STO/RCL operations
> on a variable name, then let that name be included
> into the library.
> 
> When you run a set of programs collected into a user directory,
> then they reference each other by name, and if a name 'MYFUNCTION'
> is missing at run time, then encountering that name in a program will
> leave the name on the stack (which may change what you expect to be
> on the stack) and then continue with the remainder of the program.
> 
> OTOH, when you convert a directory into a library, names which refer
> to objects included in the library are converted into library function
> calls (ROMPTR or "XLIB name"), and if the library (or function) is not
> available when one of those is encountered, the "Undefined XLIB Name"
> error will occur instead.
> 
> An error might also occur if you intend to use a named variable
> to store data, but you forget to omit that name from being
> included in the converted library (you can not store data
> into library functions, nor can you even use 'MYDATANAME' RCL
> if the named data variable is later to be included in a library).
> 
> One problem with locating the mistake is that when directories
> (containing named variables) are converted into libraries,
> all of the variable names are replaced by numbers (library number
> and function number), and you would not be able to search
> the converted library for any trace of any original names.
> 
> However, source programs in SysRPL
> would usually contain the word "ROMPTR" in all such places.
> 
>> Is 22kB too long for a LIB program?
> 
> 
> No; one library can occupy up to one memory bank (128K) in 48G/49G.
> 
>> I'm trying to get an HP48G+ program to work on the HP48Gii.
> 
> 
> Well, have any *built-in* library function numbers changed
> between those models? (as they did between 48G and 49G;
> in fact, some even changed type, from ROMPTR to FLASHPTR);
> if so, perhaps look for those.
> 
> [r->][OFF]

Here is a thread about putting variables in a library.  Perhaps it will
help you.

http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/66d3e44d793aab51/ae60bd3a8dafae3e?q=variable+inside+library&rnum=1#ae60bd3a8dafae3e

TW

I would bet on the real cause of your undefined library
function being something used internally in the original HP48G
which either isn't in the "born again" version or has
changed its library or function number (or object type).

But as long as we're wandering into all this other territory,
here's more rambling discussion:

On Wed, 26 Oct 2005 00:49:23 -0500, Alan Ferguson wrote:

> my program creates quite a few local variables that are to be
> contained within the library. I guess this is not possible.

The term "local" (or "temporary") variable generally means
a LAM, and there is never a problem using LAMs in library
functions, since you dynamically create them during execution,
and otherwise they have no existence.

It is certainly also possible to use "global names" (ID)
in libraries; the only problem occurs when you
manufacture your library by first creating a directory,
and then use some sort of conversion program
to build a library whose template is taken from the directory.

Other things to watch out for are
not to use 'MyFunction' RCL (or ' ID MyFunction @)
if 'MyFunction' was once found in a variable,
but is to be converted to a library function,
because a ROMPTR is not a valid stack argument
for RCL (or @).

If you create your library from a directory, then you
must inform the conversion program which variable names
are templates for library functions, vs. which variables
are to be ignored (and omitted) from being converted at all.

Various "library from directory" programs take instructions
 from specially named "control variables" stored in the directory
itself; these variables -- named '$xxxx' -- do not become part of the
library, but just tell the library builder what you want to do.

Certain library builders for HP48 assumed that you'd want
to include all variables in the directory *except* those
listed in a control variable named $VARS.

The CRLIB command built right into the HP49G has an opposite
philosophy -- it ignores $VARS and assumes that you want
to include *only* variables mentioned in the union
of lists found in $VISIBLE and $HIDDEN

For the HP48, usually only one of $VISIBLE or $HIDDEN
would be supplied (and the latter superseded the former anyway),
but CRLIB needs both of these lists if you want both
named and unnamed library functions.

Below is a program to first purge and then [re-]create
a sample library on an HP49G (works in my ROM 1.19-6)
which uses an ordinary variable named 'X'
(originally already found in the source directory itself)
to store data during the execution
of its only named command.

Note that I have made up a library number;
when the test program begins, if the menu is non-empty
the very first time, then you already have that library
number installed, so instead of CONT type KILL, then
edit the test program to change the initially suggested
library number and re-run, until the *first* menu is empty.

You may also re-start the test program afterwards,
to purge the new library which you created for this test,
whose number appears on the stack during pauses
(just press CONT *once* and then type KILL, while
resisting the temptation to press MYcmd again :)

\<< 1437. @ Suggested library number
DUP TMENU "CONT to PURGE LIB" PROMPT
PATH OVER DUP HOME DETACH 0. TAG PURGE EVAL
DUP MENU "CONT to create LIB" PROMPT
DIR
   X "Original var 'X'"
   MYdata "Fixed LIB data"
   MYcmd \<< 2. MENU MYdata NEWOB X NEWOB
   "Changed var 'X'" 'X' STO 'X' RCL CONT \>>
@ "Control" variables:
   $TITLE "TestX"
   $ROMID "Invalid" @ will be changed below
   $CONFIG 1. @ special value for CRLIB only
   $VISIBLE { MYcmd }
   $HIDDEN { MYdata }
END 'MYdir' DUP PGDIR SWAP OVER STO EVAL DUP '$ROMID' STO CRLIB
      VARS TAIL PURGE 0. STO PATH OVER HOME ATTACH EVAL MENU
      "Press MYcmd" PROMPT \>> 'MYtst' STO

@ [r->][OFF]

I forgot to mention to do HOME 256 ATTACH
before transferring or typing any programs
containing the CRLIB command,
which is found in the internal library 256.

[r->][OFF]