DB48X: HP48-like RPL implementation for DM42

[spiff72]

I am trying to figure out if this is a bug, or operator error...

If I have a program stored in a variable, and recall it to the stack, I find that the editor is acting strangely. As a simple example, take the following program for converting a number on the stack from mm to in:
<< 25.4 * >>

I wanted to include actual units in this, so I attempted to edit it by recalling it to the stack, pressing the right arrow button to enter edit mode, and then placed the cursor after the first <<. If I try to enter a 1 and then append units of mm to this by using the 1st shift UNIT menu and picking length, next page, mm ... instead of appending the _mm to the 1 I just entered, the cursor jumps to the end of the 25.4 and appends it there instead. I tried this in the sim initially, and then on my hardware DM42, and the same thing happens.

If I enter the program from scratch at the command line, I am able to enter the program as I intended.

I'm assuming that this could be done with some of the units functions, but my end program looked like this:
<< 1_mm * 25.4_mm/in / >>

Why does the cursor jump to the 25.4 in this scenario?

[c3d]

(09-16-2024 03:27 PM)spiff72 Wrote:  I am trying to figure out if this is a bug, or operator error...

If I have a program stored in a variable, and recall it to the stack, I find that the editor is acting strangely. As a simple example, take the following program for converting a number on the stack from mm to in:
<< 25.4 * >>

I wanted to include actual units in this, so I attempted to edit it by recalling it to the stack, pressing the right arrow button to enter edit mode, and then placed the cursor after the first <<. If I try to enter a 1 and then append units of mm to this by using the 1st shift UNIT menu and picking length, next page, mm ... instead of appending the _mm to the 1 I just entered, the cursor jumps to the end of the 25.4 and appends it there instead. I tried this in the sim initially, and then on my hardware DM42, and the same thing happens.

If I enter the program from scratch at the command line, I am able to enter the program as I intended.

I'm assuming that this could be done with some of the units functions, but my end program looked like this:
<< 1_mm * 25.4_mm/in / >>

Why does the cursor jump to the 25.4 in this scenario?

This is clearly a bug. The editor is trying to make sure the unit is added at the end of the number and not in the middle. In that scenario, that leads it to incorrectly jump to the next number. Because the computation was just slightly completely entirely wrong.

This is bug #1192, and it should be fixed on the dev branch.

[spiff72]

(09-16-2024 07:20 PM)c3d Wrote:  

(09-16-2024 03:27 PM)spiff72 Wrote:  I am trying to figure out if this is a bug, or operator error...

If I have a program stored in a variable, and recall it to the stack, I find that the editor is acting strangely. As a simple example, take the following program for converting a number on the stack from mm to in:
<< 25.4 * >>

I wanted to include actual units in this, so I attempted to edit it by recalling it to the stack, pressing the right arrow button to enter edit mode, and then placed the cursor after the first <<. If I try to enter a 1 and then append units of mm to this by using the 1st shift UNIT menu and picking length, next page, mm ... instead of appending the _mm to the 1 I just entered, the cursor jumps to the end of the 25.4 and appends it there instead. I tried this in the sim initially, and then on my hardware DM42, and the same thing happens.

If I enter the program from scratch at the command line, I am able to enter the program as I intended.

I'm assuming that this could be done with some of the units functions, but my end program looked like this:
<< 1_mm * 25.4_mm/in / >>

Why does the cursor jump to the 25.4 in this scenario?

This is clearly a bug. The editor is trying to make sure the unit is added at the end of the number and not in the middle. In that scenario, that leads it to incorrectly jump to the next number. Because the computation was just slightly completely entirely wrong.

This is bug #1192, and it should be fixed on the dev branch.

Thanks!