newRPL - build 1255 released! [updated to 1299]

[jpcuzzourt]

(11-11-2019 10:27 PM)Claudio L. Wrote:  That's actually an area where we could use some community effort. If somebody can come up with a printable overlay, I'd order a few myself! The keyboards I believe have physically the same geometry, so the same overlay would work for 50g, 40gs, 39gs, etc.
The best image I could find is what I used for newRPL Desktop, so if you have it installed just look in the program folder and copy the jpg from there. But I'm not sure it has enough quality for printing.

Thanks for this. I found newrpl-sources/bitmap/keyboard.png. It's useable when scaled in GIMP to 69x104mm* (261x393pixels), but it's a bit blurry and the shifted values are difficult to make out. I may work on it a little if I find some time.

Edit: I've started working on a clean newRPL keyboard layout graphic for us to use. I'll share when I have it in a useful state.

[Claudio L.]

All ROMs updated to build 1315.

New additions:
* RPN mode
* Assembly-like instructions

Please see the RPN mode thread for more details.

[The Shadow]

I started using HP calculators with the 48, so I'm not familiar with old-school RPN. Are the assembly-like instructions primarily useful for RPN users, or do they have uses in RPL?

[_nmr_]

Hello.
Claudio L. ,
is there a possibility to add cyrillic support (to use russian letters) to your project?

[JoJo1973]

(11-20-2019 06:52 AM)_nmr_ Wrote:  Hello.
Claudio L. ,
is there a possibility to add cyrillic support (to use russian letters) to your project?

Well, looking at the code basically it's just a matter of updating the existing fonts with the cyrillic alphabet glyphs, update a translation table, launch the provided conversion tool and recompile.

Problem is that there's eleven of them and without a font editor the process becomes time-consuming.

Tonight I'm going to update the wiki with some info.

[Claudio L.]

(11-20-2019 08:55 AM)JoJo1973 Wrote:  

(11-20-2019 06:52 AM)_nmr_ Wrote:  Hello.
Claudio L. ,
is there a possibility to add cyrillic support (to use russian letters) to your project?

Well, looking at the code basically it's just a matter of updating the existing fonts with the cyrillic alphabet glyphs, update a translation table, launch the provided conversion tool and recompile.

Problem is that there's eleven of them and without a font editor the process becomes time-consuming.

Tonight I'm going to update the wiki with some info.

The answer is yes, newRPL manages all text as Unicode, so it is not only possible but not all that complicated. However, it does take some work:

a) All fonts sizes and variants need to have glyphs added for cyrillic. Fonts are simply a bitmap (can be edited with GIMP or any other bitmap editor), and a text file that matches the symbols on the bitmap with their Unicode code. We have a font conversion tool that can read those bitmaps and text files, and output the font either as a standalone newRPL object that you can install as a user font, or you can output C code and replace the fonts in the ROM (for a more permanent fix).
b) Keyboard maps need to be added so you can type those symbols on-calc. Once more, this can be done altering the default maps in the source code, or through your own custom key definitions, that can be user-installed on the standard ROM.

As a bonus, you could also translate error messages (and some other texts) in the source code to have a full ROM customized for your language.
But if all you want is to display text in cyrillic in your own programs, a user-installed font and user-installed key definitions should suffice, and you can use the standard ROM (no coding necessary).

[Claudio L.]

(11-20-2019 04:47 AM)The Shadow Wrote:  I started using HP calculators with the 48, so I'm not familiar with old-school RPN. Are the assembly-like instructions primarily useful for RPN users, or do they have uses in RPL?

Assembly-like instructions are for everybody. They intermix with RPL as you wish. You can think of the registers as local variables that don't need to be declared, or as temporary storage to avoid (or reduce) stackrobatics.
I think that's the main usefulness: Reduce stackrobatics and cryptic code by making things more readable. The instructions are quite compact, think << :A+=B*C >> and compare with << B C * 'A' STO+ >>, so code is shorter and easier to read. Yes, there's a slight reduction in the overhead of running 1 command versus 5, so speed could end up improving (not tested yet as it wasn't the objective). On the other hand, the interpreter overhead is pretty thin as it is, so the improvement in speed won't be that impressive.
However, readability of numerical algorithms I think will improve significantly. It's easy to get lost in stackrobatics and these instructions can help keep the code clean.
An example: Given A, B, C on the stack, calculate the quadratic formula (-B+√(B^2-4*A*C))/(2*A)
I know, using a symbolic then ->NUM it's best for readability but for the sake of this excercise let's not use symbolics.
Using stackrobatics:

Code:


« PICK3 * 4 * OVER SQ SWAP - √ SWAP - SWAP DUP + / »

Using assembly-like code:

Code:


«
:A=RPOP.S1.#3     @ POP 3 VALUES FROM THE STACK STARTING AT S1, ASSIGN A=S3, B=S2, C=S1
:D=A*C
:D*=4
:E=B^2
:F=E-D
:F=SQRT.F
:F-=B
:F/=2*A
:P=F                   @ PUSH THE RESULT BACK TO THE STACK
»

There's 15 objects and commands on the stackrobatics version, vs. only 9 instructions in the assembly-like and it is more readable, once you get used to the syntax.

RPN people should find more at home with the assembly-like syntax than with plain RPL, but that doesn't prevent RPL people from using it too.

EDIT: A third way to code it, using locals:

Code:


« →  A B C « B SQ A C * 4 * - √ B - A 2 * / » »

This version improves readability (vs. stackrobatics), and in newRPL should be about the same speed as assembly-like code. Whether it is more or less readable than asm it's for the reader to decide.

[The Shadow]

Interesting, thanks for the explanation, Claudio!

I have to admit that after years of RPL programming, I don't find the "stackrobatic" (fun word!) version that hard to read! But the assembly version is certainly more compact.

[Claudio L.]

(11-20-2019 05:14 PM)The Shadow Wrote:  Interesting, thanks for the explanation, Claudio!

I have to admit that after years of RPL programming, I don't find the "stackrobatic" (fun word!) version that hard to read! But the assembly version is certainly more compact.

As you can imagine, I like RPL as it was, but RPN would be quite difficult to program with only 4 stack levels and no easy-access registers like most RPN calcs have. So implementing the stack limitation also required some kind of registers for additional storage. In the end you can code any way you like, with this addition I was hoping to get a few more users: the RPN converts. The modifications were nearly trivial so why not.

[JoJo1973]

(11-20-2019 03:01 PM)Claudio L. Wrote:  

(11-20-2019 08:55 AM)JoJo1973 Wrote:  Well, looking at the code basically it's just a matter of updating the existing fonts with the cyrillic alphabet glyphs, update a translation table, launch the provided conversion tool and recompile.

Problem is that there's eleven of them and without a font editor the process becomes time-consuming.

Tonight I'm going to update the wiki with some info.

The answer is yes, newRPL manages all text as Unicode, so it is not only possible but not all that complicated. However, it does take some work:

a) All fonts sizes and variants need to have glyphs added for cyrillic. Fonts are simply a bitmap (can be edited with GIMP or any other bitmap editor), and a text file that matches the symbols on the bitmap with their Unicode code. We have a font conversion tool that can read those bitmaps and text files, and output the font either as a standalone newRPL object that you can install as a user font, or you can output C code and replace the fonts in the ROM (for a more permanent fix).
b) Keyboard maps need to be added so you can type those symbols on-calc. Once more, this can be done altering the default maps in the source code, or through your own custom key definitions, that can be user-installed on the standard ROM.

As a bonus, you could also translate error messages (and some other texts) in the source code to have a full ROM customized for your language.
But if all you want is to display text in cyrillic in your own programs, a user-installed font and user-installed key definitions should suffice, and you can use the standard ROM (no coding necessary).

It took a bit longer than planned, but I've added a chapter in the appendix of the wiki about font creation.

Claudio and others, please let me now mistakes and omissions!

[The Shadow]

Claudio, I was curious - is there any way to define a new, non-absolute temperature unit? This isn't an urgent issue or anything, I just don't see any obvious way to do it.

[Claudio L.]

(11-24-2019 03:53 AM)The Shadow Wrote:  Claudio, I was curious - is there any way to define a new, non-absolute temperature unit? This isn't an urgent issue or anything, I just don't see any obvious way to do it.

No, there isn't. Any unit with a shifted zero needs to be handled carefully, only if added to the source code and marked as a special unit the system would understand it. Also, these type of units get associated with their corresponding delta units of change, so it's not that simple to present an interface for the user to add a custom temperature scale. And why would you need to invent a new temperature scale these days?

[The Shadow]

(11-24-2019 02:57 PM)Claudio L. Wrote:  No, there isn't. Any unit with a shifted zero needs to be handled carefully, only if added to the source code and marked as a special unit the system would understand it. Also, these type of units get associated with their corresponding delta units of change, so it's not that simple to present an interface for the user to add a custom temperature scale. And why would you need to invent a new temperature scale these days?

I figured as much. And I don't "need" to for any practical purpose... I just sometimes like playing around with unit systems which, while superior to what we have now, nobody will ever actually adopt.

(Yes, I'm weird. I even think we should switch to base 6 - which, given that the huge majority even of those who tilt at that particular windmill favor base 12, leaves me almost entirely alone in this world.)

[_nmr_]

(11-23-2019 05:21 PM)JoJo1973 Wrote:  It took a bit longer than planned, but I've added a chapter in the appendix of the wiki about font creation.

Thanks, JoJo.
Now I have a set of fonts from directory sources/bitmap/fonts with added cyrillic (rus) glyphs and TXT files for each BMPs.
Next step I'm failing to build bmp2font with Qtcreator. I (had?) downloaded Qt from qt-project.org and installed with "Desktop gcc 64-bits" enabled. When I opened project bmp2font.pro the "Configure Project" button was not active. May I download compiled bmp2font somewhere?

PS
I did it.
I was reinstall Qt, also make and qmake was not installed on system.

[_nmr_]

   

Hello.
I did add keyhandlers and key combinations to hal_keyboard.c for russian letters alike how is it done for greek letters. But it is not many unused key combinations. May be possible another way to make keyboard layouts?
And how to make custom key definitions, that can be user-installed on the standard ROM?

Bugreport:
When calculating the roots of the polynomial with the PROOT command with the vector [1 6 15 20 15 6 1] on the stack, the 49g+ hangs with a memory reset. PC-program hangs too.

[Claudio L.]

(11-30-2019 05:12 AM)_nmr_ Wrote:  Hello.
I did add keyhandlers and key combinations to hal_keyboard.c for russian letters alike how is it done for greek letters. But it is not many unused key combinations. May be possible another way to make keyboard layouts?
And how to make custom key definitions, that can be user-installed on the standard ROM?

Bugreport:
When calculating the roots of the polynomial with the PROOT command with the vector [1 6 15 20 15 6 1] on the stack, the 49g+ hangs with a memory reset. PC-program hangs too.

Thanks for the report, I'll take a look at PROOT.

Regarding key definitions: yes, you can redefine any key in any way you want from RPL, no need to modify the sources. But I'll have to write an entire section of the wiki for that. Give me a few days and I'll do it.

[JoJo1973]

(12-04-2019 11:44 PM)Claudio L. Wrote:  Regarding key definitions: yes, you can redefine any key in any way you want from RPL, no need to modify the sources. But I'll have to write an entire section of the wiki for that. Give me a few days and I'll do it.

A few days ago I added a Chapter 7 (Advanced Topics) to the wiki with stubs for topics such as keyboard handlers and custom menus. I also moved there the chapter about font redefinition because I think it belongs there.

At the moment I'm writing a chapter about using the stack, describing also the two RPN modes. For now it's just a bit more than a stub (these days I've very little free time).

Keep also an eye on the alphabetical list of commands, since now and then I'll add more commands.

[Claudio L.]

(12-05-2019 09:39 PM)JoJo1973 Wrote:  A few days ago I added a Chapter 7 (Advanced Topics) to the wiki with stubs for topics such as keyboard handlers and custom menus. I also moved there the chapter about font redefinition because I think it belongs there.

At the moment I'm writing a chapter about using the stack, describing also the two RPN modes. For now it's just a bit more than a stub (these days I've very little free time).

Keep also an eye on the alphabetical list of commands, since now and then I'll add more commands.

Sounds great! I updated your chapter on the assembly-like instructions with the latest developments, I'm getting ready to release the update in the next few days.
I'm also finishing up the "given that" operator to apply hints and rules to an expression as per a discussion we had here (page 26 or so in this thread). I'll have to write that up on the wiki as well.

Thanks for your hard work on the wiki, I'm sure everyone here will appreciate it.

[_nmr_]

(12-05-2019 09:39 PM)JoJo1973 Wrote:  

(12-04-2019 11:44 PM)Claudio L. Wrote:  Regarding key definitions: yes, you can redefine any key in any way you want from RPL, no need to modify the sources. But I'll have to write an entire section of the wiki for that. Give me a few days and I'll do it.

A few days ago I added a Chapter 7 (Advanced Topics) to the wiki with stubs for topics such as keyboard handlers and custom menus. I also moved there the chapter about font redefinition because I think it belongs there.

At the moment I'm writing a chapter about using the stack, describing also the two RPN modes. For now it's just a bit more than a stub (these days I've very little free time).

Keep also an eye on the alphabetical list of commands, since now and then I'll add more commands.

Thanks.
I found a lot of changes in the last few weeks.

[_nmr_]

(11-14-2019 07:36 AM)jpcuzzourt Wrote:  

(11-11-2019 10:27 PM)Claudio L. Wrote:  That's actually an area where we could use some community effort. If somebody can come up with a printable overlay, I'd order a few myself! The keyboards I believe have physically the same geometry, so the same overlay would work for 50g, 40gs, 39gs, etc.
The best image I could find is what I used for newRPL Desktop, so if you have it installed just look in the program folder and copy the jpg from there. But I'm not sure it has enough quality for printing.

Thanks for this. I found newrpl-sources/bitmap/keyboard.png. It's useable when scaled in GIMP to 69x104mm* (261x393pixels), but it's a bit blurry and the shifted values are difficult to make out. I may work on it a little if I find some time.

Edit: I've started working on a clean newRPL keyboard layout graphic for us to use. I'll share when I have it in a useful state.

May be it usefull. I did began this drawing for my 39gs, but later bought "second hand" 49g+. This overlay not tested with print. In QCAD needs to move text symbols.