Prev: Hacking calculators article
Next: is there an updated .formats.gx, .symbols.gx, and .comments.gx for sadhp?
From: Raymond Del Tondo on 23 Oct 2009 18:28
Confirmed. This will be fixed ASAP, hopefully within a few days:-)

Thanks for pointing out this bug.

"rs1n" <> schrieb im Newsbeitrag
news:a1f5a271-f6aa-4398-9228-7912d2eacc91(a)d4g2000vbm.googlegroups.com...
> Possible bug? Have alpha-mode lock on, but not lower-case lock. Now,
> press (and hold) left-shift to type lower-case letters. Only the first
> letter gets lower-case'd, and the remaining letters are still
> capitalised even while left-shift is held down.
>
> [alpha] [alpha] [leftshift (hold for next three keys)] [A] [B] [C]
>
> S4.6 mode on produces
>
> aBC
>
> whereas the normal behavior should produce
>
> abc


From: rs1n on 26 Oct 2009 10:17
Here's another bug (mostly cosmetic, but can be confusing). I was
editing the following program (entered here exactly as is viewed on
the HP48, including linebreaks).

<< TIME '1-COS(X^2+Y^2
^2)/(X^2+Y^2)' -3.5
3.4 -3.5 3.4 15 15
PLOT3D TIME ROT
HMS-
>>

Place the cursor on the 'C' in the function COS and press the DEL->
key. The screen shows:

<< TIME '1-COS(X^2+Y^2
<< TIME '1-^2)/(X^2+Y^...
3.4 -3.5 3.4 15 15
PLOT3D TIME ROT
HMS-
>>

Basically, keep pressing <-DEL or DEL-> on the menu and you will see
that the screen does not properly update. I'm guessing there was a
MOVEUP routine that did not have a followup routine to blank out
artifact pixels.

Out of curiosity, is the fast editing routine a part of UI.LIB? Or is
it part of CF.LIB? UI.LIB seems based off of Java, but yet is smaller.

Best wishes,
Han
From: Raymond Del Tondo on 26 Oct 2009 12:23
Hello Han,

thanks again for the bug report.
Actually the edit display row update bug
is in the todo list for a while,
however it's only a cosmetic thing,
but will be fixed, of course:-)

> Out of curiosity, is the fast editing routine a part of UI.LIB?
> Or is it part of CF.LIB?
>
Both. The display engine and decompiler resides in CF.LIB,
various new ML edit functions reside in UI.LIB

> UI.LIB seems based off of Java, but yet is smaller.
>
The fast stack display was not based on JAVA,
but on my own six level stack display routine,
which used a modification of the self-contained
standard frame POL for a 5-level stack display routine
from about 1991, which we used in the RPL48 package.

When I included the ML decompile routine from Will Laughlin,
I had to adjust various routines of my stack display
to match the output of the ML decompiler,
hence there are some similarities now.

The fast SpeedUI editor has nothing to do with the edit mode in JAVA,
the only commonly used routine is the ML decompiler from Will,
with some modifications from me.
Everything else was written new from scratch,
and that's why scrolling is that fast:-)


CF.LIB can be seen as base library,
a concentration of all functionalities which are
used in more than one SpeedUI component.
That's why CF.LIB is that big in size now;-)

In one of the next releases, there may be an option
for a stripped down CF.LIB , which doesn't
include the ML decompiler.
That'll save another 11 or 12K, but will of course
have some impact on the overall performance.

Best Wishes

Raymond





"rs1n" <handuongster(a)gmail.com> schrieb im Newsbeitrag
news:6d43bd00-70ea-49ee-b6a4-e291960ea436(a)u13g2000vbb.googlegroups.com...
> Here's another bug (mostly cosmetic, but can be confusing). I was
> editing the following program (entered here exactly as is viewed on
> the HP48, including linebreaks).
>
> << TIME '1-COS(X^2+Y^2
> ^2)/(X^2+Y^2)' -3.5
> 3.4 -3.5 3.4 15 15
> PLOT3D TIME ROT
> HMS-
>>>
>
> Place the cursor on the 'C' in the function COS and press the DEL->
> key. The screen shows:
>
> << TIME '1-COS(X^2+Y^2
> << TIME '1-^2)/(X^2+Y^...
> 3.4 -3.5 3.4 15 15
> PLOT3D TIME ROT
> HMS-
>>>
>
> Basically, keep pressing <-DEL or DEL-> on the menu and you will see
> that the screen does not properly update. I'm guessing there was a
> MOVEUP routine that did not have a followup routine to blank out
> artifact pixels.
>
> Out of curiosity, is the fast editing routine a part of UI.LIB? Or is
> it part of CF.LIB? UI.LIB seems based off of Java, but yet is smaller.
>
> Best wishes,
> Han


From: rs1n on 26 Oct 2009 14:43
>
> > Out of curiosity, is the fast editing routine a part of UI.LIB?
> > Or is it part of CF.LIB?
>
> Both. The display engine and decompiler resides in CF.LIB,
> various new ML edit functions reside in UI.LIB
>

I see. The ML edit is fantastic! SpeedUI continues to give the HP48
another breath of fresh air.

> > UI.LIB seems based off of Java, but yet is smaller.
>
> The fast stack display was not based on JAVA,
> but on my own six level stack display routine,
> which used a modification of the self-contained
> standard frame POL for a 5-level stack display routine
> from about 1991, which we used in the RPL48 package.
>
> When I included the ML decompile routine from Will Laughlin,
> I had to adjust various routines of my stack display
> to match the output of the ML decompiler,
> hence there are some similarities now.
>

Ahh, I see now. I actually still have RPL48 installed on an old
HP48SX. Was the POL you mentioned at all related to the SOL back when
folks were working on speeding up the HP48SX? Both were fantastic
packages. BTW, I REALLY love how nice the editor is with this latest
release of SpeedUI!

From: rs1n on 27 Oct 2009 14:51
One more cosmetic bug (perhaps?):

When set to use small fonts for algebraic objects, the display of the
stack level of certain algebraics is inconsistent.

1. Compare 'X^2' vs 'X-1' with small fonts enabled. Clear the screen,
then switch to medium fonts, and re-enter the same two equations.

2. Leave 'X^2' and 'X-1' on the stack, and switch between small and
medium fonts. The cache does not update, but the stack level indicator
changes sizes as seen in 1.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Hacking calculators article
Next: is there an updated .formats.gx, .symbols.gx, and .comments.gx for sadhp?