sburke@jarthur.Claremont.EDU (Scott Burke) (04/25/91)
Hi.
Can anyone give me the SYSEVAL to force storage of a token name for the
purposes of providing an exactly correct error message, as in:
"ROUTINE" # _____h SYSEVAL @ store the token name ROUTINE
514 DOERR @ show "ROUTINE Error:
Bad Argument Value"
Does this make sense? I want to control what the first line of the error
message says.
Scott.
sburke@jarthur.claremont.eduftg0673@tamsun.tamu.edu (Rick Grevelle) (04/26/91)
In article <11898@jarthur.Claremont.EDU> sburke@jarthur.Claremont.EDU (Scott Burke) writes: > >Can anyone give me the SYSEVAL to force storage of a token name for the >purposes of providing an exactly correct error message, as in: > >"ROUTINE" # _____h SYSEVAL @ store the token name ROUTINE >514 DOERR @ show "ROUTINE Error: > Bad Argument Value" > >Does this make sense? I want to control what the first line of the error >message says. > Yes, this makes sense; but you can't do it via keyword programming, and what's more it can only be done from a library! Besides, SYSEVALing is an extremely poor method for accessing entry points in the 48's ROM because it's slower, it uses more memory, and it's quite, quite limited. This is because many of the most useful entry points can *not* be SYSEVALed, and require the individual to be familiar with the internal trappings of SYSTEM RPL. The address for which you've asked is one such example, and is considerably more complex than you've imagined. This is most often a problem with many user language programmers, and it seems to be worsening with the massive amounts on misinformation that so frequently finds it way to this news group. Those who are familiar with Wickes' lectures are well aware of his emphasis on the complexity of the RPL operating system. Unfortunately, knowing how to program using only keywords provides very little insight as to this complexity, and often leads individuals to falsely believe they are in fact experts; results of which are a deluge of less than wholesome software that's so frequently posted here. Personally, there are few individuals posting to this group whose software I'd trust to use without first inspecting. Furthermore, I would never purchase a piece of software written in user language for it would assuredly be pig slow, and severely limited. If an ISV is serious enough about a commercial venture into the 48 software market, then they should be prepared to pay the price and make the necessary investments. Anything less constitutes a ripoff, and it's sad that most consumers are completely unaware of the caliber of software they are purchasing. Hewlett-Packard's Equation Library Card is an example of quality software, for it fully utilizes the resources available internally. Those ISVs who have no access to these resources should be required to make this disclosure on all of the software they might be trying to sell. Because the Equation Library uses much of the same SYSTEM RPL as the ROM, it really could be considered to be an extension of the ROM. The difference in the performance of programs written in user language and SYSTEM RPL is day and night. Given both the choice along with the knowledge to make the distinction, most users would more than likely spend their money more eclectically. My extensive proselytizing was not intended to flame anyone, nor to promote an antidote; but rather to make the people reading this news group more aware of the enormous complexity of the RPL operating system. Outside of HP, there are very few who have spent the time reverse engineering the 48 and thought of as truly knowledgeable in regards to its operating system. Personally the longer I delve into the internals, the more ignorant I realize I really am about it. So please, let's all be a bit more careful in posting articles, and attempt to alleviate the misinformation. Rick Grevelle
akcs.aaron@hpcvbbs.UUCP (Aaron Boonshoft) (04/29/91)
> Can anyone give me the SYSEVAL to force storage of a token name for > the purposes of providing an exactly correct error message, as in: > > "ROUTINE" # _____h SYSEVAL @ store the token name ROUTINE > 514 DOERR @ show "ROUTINE Error: > Bad Argument Value" > > Does this make sense? I want to control what the first line of the > error message says. Hi Scott, The following will simulate an error message pretty closely. I think I know of another way that is more involved if this won't do the job. Post a response if you would like to see it. ...Aaron CET @ Call Routine with Error Trap ( 'routine_name' --> ) @ CET will evaluate a routine and take no other action @ unless there is an error. It will report any non-ATTN @ error with the 'routine_name' and then (after the user @ presses any key) will do an ATTN error to stop program @ execution. The stack display will then be updated. @ (When a user presses the ATTN key, a #0d error is caused.) @ WARNING: This code has not been fully tested. \<< DUP \-> n \<< IFERR EVAL THEN IF ERRN B\->R THEN n " Error:" + 1 DISP ERRM 2 DISP 1400 .075 BEEP -1 WAIT DROP END 0 DOERR END \>> \>> ROUTINE @ Example Routine with an Error \<< { } 1 * \>> CALLRTN @ Example Routine using CET \<< 'ROUTINE' CET \>> > ... I would never purchase a > piece of software written in user language for it would assuredly > be pig slow, and severely limited. If an ISV is serious enough > about a commercial venture into the 48 software market, then they > should be prepared to pay the price and make the necessary > investments. Anything less constitutes a ripoff, and it's sad that > most consumers are completely unaware of the caliber of software > they are purchasing... Hi Rick, I moved to Corvallis just this year to pursue a career as an ISV for the HP 48 and other handhelds. I and some of the other professionals that I have had the pleasure of meeting use user level RPL for the development of commercial programs. With the exception of game programs, I have to disagree with your view of programs written in user level RPL. When you talk about the caliber of software, are you sure your not referring purely to the how complicated the coding is or how many seconds faster it can run. It seems to me that there are other important factors to consider like dependability, documentation, friendliness, compatibility, portability and, of course, cost. While I am not trying to say that the user language RPL is superior to low level RPL for commercial software, it does have its advantages. * Unlike low level RPL, it uses commands that are much more likely to be supported on all versions of the HP 48, past, present, and future. (ROM A B C D E F?..., S SX SXII?... ) * Unlike low level RPL, it can be documented with the source code in such a way that end users may modify the programs with moderate ease. (Many end users can learn a lot about programming from such products.) * The development time is shorter than thus cost can be kept down. This results in less expense for the end user. I think that most HP 48 users would rather wait a few seconds than pay a LOT more for same program only faster. > ...Those ISVs who have no access to these resources should be required > to make this disclosure on all of the software they might be trying to > sell... Required by who? Wouldn't it make more sense for ISVs who DO USE the internal resources to advertise this fact. And, while their at it, they might want to make a disclosure saying that their program may not work on all models of the 48. > ...The difference in the performance of programs written > in user language and SYSTEM RPL is day and night... Yes, user language RPL is slower than the low level RPL, but for most applications (not counting games), it is fast enough to get to tasks done quickly enough that the user is not kept waiting more than few seconds. Last time I counted, there were 86,400 seconds in a day. :-) I love programing, but my idea of a "real" work is having well documented tools to work with and then creating something new, NOT spending time playing digital detective and then putting my future reputation on a product that is based on unsupported tools. Don't get me wrong, I am very impressed with those people who have the brains and time to create low level RPL code despite the fact that it is not supported by HP. But when it comes to professional code, user level RPL is a very respectable tool to work with. If you have any type of constructive rebuttal to my comments, I would truly like to hear them. Like I said, I'm new to this business and I'm aware that I have a lot to learn. ...Aaron
sburke@jarthur.Claremont.EDU (Scott Burke) (04/29/91)
Hi. Aaron's follow-up article on error messages is helpful. However, that is a method I've already implemented, and it does faithfully duplicate _nearly_ all error messages. Here's the difficult case: You write a user-defined function that takes an argument off the stack. In that user-defined function, the first command MUST be \-> varname. There is NO way to start with an IFERR or anything else, so you can't trap the \-> error that occurs if there are no arguments on the stack, so that you can replace the "\-> Error:" line with "Custom Error:". Give this one a try in user-RPL? I don't think it's possible. After a brief discussion with Rick, it doesn't seem to be solvable by any small amount of effort if you prefer to remain in user-RPL-land, which I do. Scott. sburke@jarthur.claremont.edu
akcs.aaron@hpcvbbs.UUCP (Aaron Boonshoft) (05/03/91)
Hi Scott, The IFERR statement would go OUTSIDE the userdefined function or the stack depth could be tested before the userdefined function is executed. If you want to execute the user defined function from the keyboard, you could try using vectored ENTER to test the stack depth or execute IFERR. I'm not sure I understand the problem your faced with. It's true that the user defined function will not catch the error (as far as I know) but why cant the calling program be used for that? Aaron