Prev: HP 50g fails simple SOLVE. Comparing to TI-89, which succeeds
Next: HPGCC problems
From: Albert Graef on 21 Feb 2007 04:23
John H Meyers wrote:
> If you have a string for which STR\-> or OBJ\-> indicates an error,
> you can locate the error (on calc or emulator) using:
>
> \<< \->STR "" { V } ROT + INPUT \>>
>
> Pressing ENTER then either returns an error-free string
> or highlights the error and awaits correction;
> you might append STR\-> if you want to compile the string
> immediately upon successful correction.

Neat little trick, thanks. The \->STR can actually be omitted since
presumably a string is already in level 1. And we can add the STR\->
command to do the compilation and invoke the above code in case it
errors out:

\<< IFERR STR\-> THEN "" { V } ROT + INPUT STR\-> END \>>

Now if we had the source code of HPUserEdit then we could modify it to
do all that automatically, and even fix the broken transfer when using
the 49G+/50G KML. :( Is that program still being maintained?

Albert

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
From: John H Meyers on 21 Feb 2007 07:59
On Wed, 21 Feb 2007 03:23:26 -0600, Albert Graef wrote:

> The \->STR [at beginning of program] can actually be omitted
> since presumably a string is already in level 1.

And all argument checking (or forcing) can be omitted everywhere,
because presumably no argument is ever missing or of wrong type :)

> And we can add the STR\-> command [at the beginning]
> to do the compilation and invoke the above code in case it
> errors out:
>
> \<< IFERR STR\-> THEN "" { V } ROT + INPUT STR\-> END \>>

Good complete program, but what if the error
was due to missing or wrong type original stack argument?
Nothing hazardous, due to inherent safety of UserRPL,
but sometimes one can catch it earlier, more obviously,
and perhaps avoid another error and leave things unchanged,
by merely doing something simple up front, such as \->STR

BTW, when IFERR is employed, it may be safer
to make sure that flag -55 has first been cleared
(or else the string won't be there after THEN...)

Programming would surely be simpler
if only inputs were never wrong :)

And so would all activity -- only a society
of HAL9000 computers will ever be perfect :)

> Now if we had the source code of HPUserEdit then we could modify it to
> do all that automatically, and even fix the broken transfer when using
> the 49G+/50G KML. :( Is that program still being maintained?

I'm so backwards that I just use Notepad and Emu48,
which has copy/paste from/to the stack
("Notepad" actually means my email/news client
in real life, which saves things more conveniently,
and also sends them right off to be posted
and/or backed up at Gmail :)

[r->] [OFF]
From: Wes on 21 Feb 2007 10:17
On Feb 21, 12:23 pm, Albert Graef <Dr.Gr...(a)t-online.de> wrote:

> Now if we had the source code of HPUserEdit then we could modify it to
> do all that automatically, and even fix the broken transfer when using
> the 49G+/50G KML. :( Is that program still being maintained?

Here's my simple klug to fix the broken transfer:

On the emulated 49g (not +), after the transfer it "presses" the keys
<RightShift><EVAL> to evaluate the "<< ... >>" STR-> on the stack. On
the emulated 49g+/50g, the two keys come out as <COS><LeftArrow>. The
COS causes the error beep and the LeftArrow puts you in the graph
screen. I got tired of hitting <CANCEL><EVAL>, so I simply assigned
an empty program << >> to the <COS> key and << EVAL >> to the
<LeftArrow> key. (Actually, I used KeyMan's IfE?P, ->TO? to keep the
arrow function in Edit mode.)

Works like a charm.

> Is that program still being maintained?

I hope so. I love its simplicity and functionality.

-wes

From: Albert Graef on 21 Feb 2007 18:11
John H Meyers wrote:
> Good complete program, but what if the error
> was due to missing or wrong type original stack argument?

Good point, but the original problem was dealing with a failed transfer
from HPUserEdit, in which case the stacktop not being a string would be
a "this can't happen" type of thing. ;-) But of course you can just add
the \->STR back in.

> BTW, when IFERR is employed, it may be safer
> to make sure that flag -55 has first been cleared
> (or else the string won't be there after THEN...)

Right, I forgot about that. Those silly system flags always get me. :)

> And so would all activity -- only a society
> of HAL9000 computers will ever be perfect :)

Well, they might just all go insane and kill each other. ;-)

> I'm so backwards that I just use Notepad and Emu48,

I prefer GNU Emacs. Having a user rpl mode for Emacs would be nice, but
I don't think that anyone has implemented one yet.

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
From: Alain on 22 Feb 2007 07:12
Sorry for the delay,

If i follow the examples in nosy.txt, the addresses on top of screen are
different for {!} for example, and in all subsequent screens also. Is that
normal? I think it's me misinterpreting due to my lack of
knowledge/experience...

Alain

"John H Meyers" <jhmeyers(a)nomail.invalid> a �crit dans le message de news:
op.tn2104k6nn735j(a)w2kjhm.ia.mum.edu...
> On Tue, 20 Feb 2007 04:13:09 -0600, Alain wrote:
>
>> I played a little with Nosy on the calc, and noticed that the function
>> addresses are not the same in the 49G+ and the 50G, though those calcs
>> are
>> supposed to be the same, only the 50G got relooked and a better
>> (hopefully)
>> keyboard. Is that normal? I assume it is, because I have updated the 50G
>> firmware with the latest version which must be different from the latest
>> 49G+ version.
>
> Since 49G+ and 50G (and 48Gii) use the exact same ROM series,
> differences should be due only to different ROM versions,
> which thus far are interchangeable between calcs.
>
> What gives you the impression of different function addresses
> between 49G+ and 50G?
>
> [r->] [OFF]


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: HP 50g fails simple SOLVE. Comparing to TI-89, which succeeds
Next: HPGCC problems