akcs.macrokid@hpcvbbs.UUCP (Kevin Vashi) (03/13/91)
Hello,
First let me make it perfectly clear taht I don't wish to
make problems out of previous problems, esspecially when we get
free software from HP. In short, I don't care if the problems
are fixed or not because I don't want HP (Bill W., Jim D.) to
hesitate posting intresting programs that are followed by
numerous bug reports. I am just happy that the people named above
post free software which are a great learning tools and further
try to eliminate any bugs even though they are not obligated to
do so. So now, Lets move to a problem that arises if you use
the new IFERR library.
If you have created programs that have the IFERR..THEN..END structure
after the IFERR library is attached then, after unattaching or purging
the IFERR library leads to the replacement of IFERR structure by
XLIB 1793 0 object. Here is an example to reproduce the effect:
1) Install (ATTACH) IFERR library.
2) Store any program that contains the IFERR structure, eg
<< IFERR 0 DOERR THEN "Error" 1 DISP ELSE "No Error" END >>
'APRG' STO
3) DETACH IFERR Library, PURGE IFERR Library.
4) Recall 'APRG' by 'APRG' RCL.
You will notice that the program has changed to the following.
<< XLIB 1793 0 0 DOERR XLIB 1793 1 "Error" 1 DISP ELSE "No Error " END
>>
Is there any way of avoiding this situation.?
Since we are at it and I think that Mr. Bill Wickes will reply
to this post, maybe he can tell us a little bit about creating
librarys that contains built in commands which ends up
over riding the built-in commands. Some common pitfalls to
avoid and other hints that will help us avoid the problems that
he had will be greatly appreciated.
Thank You,
Kevin Vashi.
xvashi@ccvax.fullerton.edu <--- Not very reliable.
eaeu147@orion.uci.edu <--- Try this first.sburke@jarthur.Claremont.EDU (Scott Burke) (03/14/91)
Regarding the problem about the new IFERR library over-riding the built-in command IFERR: That's just how it works, and is a _desired_ feature! It simply means you must be careful when you are downloading your source code to the HP-48SX that you have the proper libraries installed. Personally, I would have preferred that the new IFERR library come out with a different name, because I am not about to revise the thousands of lines of code I have written which make integral use of the old IFERR, and if I were to download that code to the 48 with the new IFERR installed, I would be in trouble. (in fact, I did this once and got a big surprise!) In the future, I will use the new version, but it would have made most sense to me to call it IFERR2 or something like that. Anyways, it's not a stumbling block, which is why this is not a serious suggestion for change to HP; I simply don't install the library unless I'm developing code which makes use of it. By and large, there are few conflicts like this one, because most libraries use command words that don't overlap with the 48. (I did find that Jim Donnelly's Toolkit uses EXTRACT, as does the library posted a while back to do USRLIB stuff on the 48...) One thing to remember if multiple libraries are in place with the same names is that the _highest_ library ID number will be searched first. Scott. sburke@jarthur.claremont.edu
billw@hpcvra.cv.hp.com. (William C Wickes) (03/14/91)
Kevin Vashi writes: > If you have created programs that have the IFERR..THEN..END structure > after the IFERR library is attached then, after unattaching or purging > the IFERR library leads to the replacement of IFERR structure by > XLIB 1793 0 object. This is not a defect, it's the correct behavior. When you remove a library, the 48 can no longer display by name, or execute, any commands from that library. The best it can do is display the library number and the command number as XLIB n m. The confusion here might arise from the use of "IFERR" for the name of the new structure word, which might suggest that the library somehow modifies the behavior of the built-in IFERR. Actually, when you enter a program containing IFERR, if the library is present it compiles as a (XLIB) reference to the new version. External libraries are searched before the internal ones, so a library can always supersede a built-in command or structure word with a new one of the same name. Bill Wickes HP Corvallis