Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!hp-pcd!hpcvra.cv.hp.com!rnews!hpcvbbs!akcs.aaron
From: akcs.aaron@hpcvbbs.UUCP (Aaron Boonshoft)
Newsgroups: comp.sys.handhelds
Subject: Re: 48 Errors
Message-ID: <281b0c9e:2931.2comp.sys.handhelds;1@hpcvbbs.UUCP>
Date: 28 Apr 91 18:40:17 GMT
References: <11898@jarthur.Claremont.EDU> <15360@helios.TAMU.EDU>
Lines: 119

>  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