newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(09-07-2019 08:54 PM)cdmackay Wrote:  hi, just starting to use newRPL again, after a while away (no time).

I run my Android phone (Samsung Note 10+) in high-resolution mode (3040x1440); in this mode, the newRPL skin doesn't fit the screen: it's too wide. The skin does look OK in the lower res mode (2280x1080). Would you be able to provide a skin that works for the high res mode, please?

Also, when the app starts, there's a popup: "Detected problems with API compatibility". The phone runs Android 9.

Finally, I note that File->Exit doesn't actually exit. It pops up the prompt "do you want to save" twice, but doesn't actually exit.

Known issues?

thanks very much indeed.

There's one and only one skin, which gets stretched to fill up the screen (turn your phone 90degrees and see for yourself). The problem is I believe Samsung reports a fake screen size, reserving some size for the edge notifications in some models, and this confuses the QT framework. There's nothing I can fix, I'll upgrade to the latest QT version for the next release to see if they fix that eventually.

Exit also relies on the QT framework. In Android there's no such thing as exiting an app, you just switch to another one so it doesn't seem to work. Just don't use exit from the menu for the time being.

You are the first to report that API compatibility problem, newRPL is compiled to run on Android 5.0 and up. I'll update the SDK for the next build, to see if they solved whatever that is.

Thanks for the report, I wish I had better solutions...

[Claudio L.]

(09-07-2019 04:02 PM)The Shadow Wrote:  

(09-07-2019 08:40 AM)JoJo1973 Wrote:  Well, angles and gauge units are different cans of worms,

They aren't, though. In addition to newRPL's angle objects, there are also angle units.

Though it's true that angle objects should be handled properly by transcendental functions too, just as units are.

So we all agree: Unit objects need to be converted to their base units and simplified to see if they become non dimensional. This will also handle units of angles correctly since their base unit is the radian (angle objects already convert to radians automatically, that discussion is only a few pages up in this thread). If the units are NOT non-dimensional, then it shall throw an error of "Inconsistent units".
The result of the functions shall be a number, without any units.

Finally, regarding temperature units, newRPL already distinguishes temperature from change of temperature, and if everything works as intended, the conversion to absolute temperature is automatic during UBASE.

[The Shadow]

Sounds good to me, Claudio! Go for it.

[cdmackay]

(09-08-2019 12:29 AM)Claudio L. Wrote:  There's one and only one skin, which gets stretched to fill up the screen (turn your phone 90degrees and see for yourself). The problem is I believe Samsung reports a fake screen size, reserving some size for the edge notifications in some models, and this confuses the QT framework. There's nothing I can fix, I'll upgrade to the latest QT version for the next release to see if they fix that eventually.

Exit also relies on the QT framework. In Android there's no such thing as exiting an app, you just switch to another one so it doesn't seem to work. Just don't use exit from the menu for the time being.

You are the first to report that API compatibility problem, newRPL is compiled to run on Android 5.0 and up. I'll update the SDK for the next build, to see if they solved whatever that is.

Thanks for the report, I wish I had better solutions...

Thanks for the detailed reply, Claudio. Indeed, they're not big issues — I never use Exit anyway, as you say — just wanted to report them just in case you weren't aware.

thanks again!

[JoJo1973]

Claudio, a question about PI from the Constants library and PI0: the latter returns PI at double the current precision, but I recall having read that PI and 'e' always return 2000+ digits of precision.

Am I right? If so, what's the point in still having PI0 around then? Do I miss something?

[Claudio L.]

(09-17-2019 04:08 PM)JoJo1973 Wrote:  Claudio, a question about PI from the Constants library and PI0: the latter returns PI at double the current precision, but I recall having read that PI and 'e' always return 2000+ digits of precision.

Am I right? If so, what's the point in still having PI0 around then? Do I miss something?

The only reason is I still didn't take the time to remove pi0. It was a "hack of the moment" to have the constant pi before there were constants implemented in newRPL. It's not a constant but a command, and cannot be used in symbolics. But I couldn't debug angle conversions and angle objects without having a convenient pi to do some hand calculation checks.
So no, there's no point and it will be removed at some point.

[JoJo1973]

Hello Claudio,

what's the meaning of system flags -12, -45, -46 and -47?

[Claudio L.]

(10-11-2019 10:19 PM)JoJo1973 Wrote:  Hello Claudio,

what's the meaning of system flags -12, -45, -46 and -47?

Those flags belong in the newRPL UAUR (Ultra-Advanced User Reference):

Flag -12 is set/cleared every time the user presses a key in the soft menus.
It's cleared if the pressed key was in menu 1 (top), set if it was in menu 2.
It affects the commands xxxLST and xxxOTHR:
TMENU: Modifies the "Active" menu (active menu is controlled by flag -11, usually (-flag clear-) it's the top one).
TMENULST / TMENUOTHR: They do TMENU, but the former uses the menu in which the user pressed last, while the latter changes the menu the user did NOT press last (a.k.a the "other" menu). They are meant to be used to bring up menus within menu handlers. For example, a menu handler may use TMENUOTHR to open a custom sub-menu in the other menu.

RCLMENU / RCLMENULST/RCLMENUOTHR: Same as RCLMENU, but following the same logic.
MENUBK / MENUBKLST / MENUBKOTHR: Brings up the previous menu for all 3 cases.


Flag -45 = DONEXTCUSTOMKEY
This flag is cleared right before entering a custom (user) key handler. Normal case is that the key handler will consume the key press, once the handler executes, no other handler will be used. However, you can "chain" handlers: let's say you want to count how many times the user presses the number "4", so you create a custom key handler that increments a global variable and you ASNKEY to number 4. But you want the "4" key to still be functional, so you set this flag, and the system will continue looking for additional custom handlers (previously installed for that same key). This way your handler is completely transparent. There's no limit on the number of handlers you can have for the same key.

Flag -46 = DODEFAULTKEY
Similar to -45, but this one is cleared before the first custom key handler is executed (there could be more than one as per chain execution above). Once all the custom key handlers finished executing, if this flag is set, the system will execute the standard default handler for that key. In other words, if any one of the custom handlers decided that the key should do the default behavior, setting this flag achieves it. In the example above, for the number "4" to be functional, your handler would have to set both flags, -45 and -46. The user would never know that the key was being logged.

Flag -47 = Disable auto execution of programs sent via USB. By default, sending a program with USBSEND will execute it automatically in the remote calculator. This flag disables that behavior. When data is received and this flag is set, the "Rx" signal will show in the status area until USBRECV is executed to pick up the data. In general, it's best to leave this flag clear (auto-receive enabled), since newRPL Desktop needs it to communicate with the calculator to establish the connection (it retrieves newRPL version, serial number for selection, and is also needed to run the firmware update process). If you don't want to execute a program, simply run USBRECV on the remote before sending it (which incidentally can be sent from the remote!).

[Claudio L.]

All ROMs updated to 1299 (see first post for changelog).

As usual, please test and report back any issues.

[jklsadf]

Seems to be working well, I just installed on an HP 39gs. Can you update your original post/the wiki to emphasize that you have to use HP's connectivity kit to do the 1st update over USB? (I spent a long time trying to update using the Qt GUI, before reading through the complete thread and learning that the initial update has to be done with HP's connectivity kit.)

[Claudio L.]

(10-23-2019 12:25 AM)jklsadf Wrote:  Seems to be working well, I just installed on an HP 39gs. Can you update your original post/the wiki to emphasize that you have to use HP's connectivity kit to do the 1st update over USB? (I spent a long time trying to update using the Qt GUI, before reading through the complete thread and learning that the initial update has to be done with HP's connectivity kit.)

The wiki's installation section clearly says you need to use the connectivity kit that came with the calculator. I'd recommend you and everyone else starting with newRPL to read the first few sections of the wiki, they are going to guide you step by step to make your experience with newRPL easier, especially the chapter about the keyboard and menus, which are significantly different from the 50g. This way your frustration will be kept to a minimum, and you'll be up and running in no time.

[jklsadf]

Hi, I did read through your first post and then wiki instructions for installing newRPL, but missed the "that came with your calculator" part. Sorry about that, but I'd still appreciate having a note afterwards for dummies: (The PC simulator will *not* work for installing the newRPL firmware, you must use HP's connectivity kit).

Also perhaps add after this sentence in your first post to help new users:

(12-15-2017 10:15 PM)Claudio L. Wrote:  ** Important **: Starting with the build 1001 release, the PC simulator is also the connectivity kit (not just a demo), so go ahead and install it too!. Mac and Linux users have to build from sources but it's perfectly compatible.

I realize newRPL is quite different from the 50g, although a lot of parts are based on the 48/49/50 series. I do like the menu setup so far.

[jpcuzzourt]

(10-18-2019 03:03 PM)Claudio L. Wrote:  All ROMs updated to 1299 (see first post for changelog).

As usual, please test and report back any issues.

Great. Just as I'm getting in deep with playing with the WP-34S, I see I need to order a 39GS so I can play with newRPL too!
Thanks a lot Claudio!

It's on its way from China right now...

[Claudio L.]

(10-23-2019 03:35 AM)jklsadf Wrote:  Hi, I did read through your first post and then wiki instructions for installing newRPL, but missed the "that came with your calculator" part. Sorry about that, but I'd still appreciate having a note afterwards for dummies: (The PC simulator will *not* work for installing the newRPL firmware, you must use HP's connectivity kit).

I updated the first post and I put the requirement of the original connectivity kit in bold on the wiki so it stands out.

[JoJo1973]

Claudio,

a question about the purpose of a couple of commands:

1) BINPUTB/BINPUTW: the program

<< 8 MKBINDATA 0 #1122334455667788 4 BINPUTB >>

fills the first four bytes of the container with #88h #77h #66h #55h but

<< 8 MKBINDATA 0 { #1122h #3344h #5566h #7788h } 0 4 BINPUTB >>

stores { #22h #44h #66h #88h } instead of { #22h #11h #44h #33h }. A look at the code shows that this works as intended, but why? Is there a reason for the different behavior? BINPUTW obviously works the same way, but using 4-bytes words instead of bytes.

2) UNQUOTEID: while QUOTEID is useful to send unevaluated arguments to functions (but less versatile than userRPL's QUOTE, which accepts symbolic expressions too) I can't see an use for UNQUOTEID: where's its usefulness?

[Claudio L.]

(10-30-2019 11:29 PM)JoJo1973 Wrote:  Claudio,

a question about the purpose of a couple of commands:

1) BINPUTB/BINPUTW: the program

<< 8 MKBINDATA 0 #1122334455667788 4 BINPUTB >>

fills the first four bytes of the container with #88h #77h #66h #55h but

When given a single number, BINTPUTB interprets the integer part as a multi-bit number (little endian!), so you requested 4 bytes to be stored, the first byte to be stored is (N%256), the second byte will be IP(N/256)%256 and so on. This is simply consistent with the little endianness of the platform, which newRPL adopted as well.

(10-30-2019 11:29 PM)JoJo1973 Wrote:  << 8 MKBINDATA 0 { #1122h #3344h #5566h #7788h } 0 4 BINPUTB >>

stores { #22h #44h #66h #88h } instead of { #22h #11h #44h #33h }. A look at the code shows that this works as intended, but why? Is there a reason for the different behavior? BINPUTW obviously works the same way, but using 4-bytes words instead of bytes.

When given a list, each item is treated as an individual element (byte, word, whatever you selected by using BINPUTB, BINPUTW), so if you use BINPUTB, only the lowest 8 bits will be stored from each number (N%256). In other words, your argument of 4 means "store the first 4 elements of my list of bytes".
BINPUTB is consistent with BINGETB, so the string of bytes you get from one bindata object can be stored directly on another one (of course, we have much faster dedicated opcodes for those memory copies).
I guess the logic I used is: for BINPUTB you can request any number of bytes to store, therefore you need to provide a string of bytes. That can come either as a list of bytes, or all packed into a single binary number. Same thing for words.

(10-30-2019 11:29 PM)JoJo1973 Wrote:  2) UNQUOTEID: while QUOTEID is useful to send unevaluated arguments to functions (but less versatile than userRPL's QUOTE, which accepts symbolic expressions too) I can't see an use for UNQUOTEID: where's its usefulness?

There's some dark uses, but the most common case is very simple: to create strings for output, you put the variable name 'X' on the stack, do UNQUOTEID ->STR to get a clean "X" rather than getting the quoted name then trying to remove the quotes from the string.

[jpcuzzourt]

(12-15-2017 10:15 PM)Claudio L. Wrote:  Quick links section (this will remain on top, see below for other info):

Latest development ROMS can be found following these links for the 50g, the 39gs /39g+ and the 40gs

Android build is here:
newRPL for Android APK package

Currently they are at build 1299, while the official release remains at 1255.

Thanks for this cool project Claudio. I got my HP-39GS from China today and dove right into getting newRPL on it. I was able to load the newrpl39.bin firmware. And I set up my build environment on 64-bit Linux and managed to get a newRPL-ui desktop up and running. Thank you for the nice instructions since I haven't used QT before. I compiled my own newRPL39 firmware file and the newRPL-ui crashed after about 4% transfer. I had to reflash using the conn3x program in Windows. So something isn't quite stable on my system. But for the most part it seems to be working. USB device is recognized and the transfer begins.

I have a quick question. Is there a high quality graphic/scan of the HP50 keyboard attached to this project yet for 39GS/40 users to print out and tape over our keys?*

An overlay sticker and key sticker like Eric Rechlin made for the WP-34S would be nice for this.
In the meantime I'll print out whatever decent image I can find, just so I can play with it without constantly referring to the desktop simulator to find the keys.
Cheers,
JP

*edit : I got ahead of myself. I see now that the 50G keyboard isn't a match either - just a lot closer than the 39GS's layout. So I'm using an image from the user manual pdf that describes the keyboard layout. Good enough for now, and I understand this is beta and will probably change anyway. But if you can guide me to any better overlay graphics, I'd appreciate it lotses. Thanks.

[MaximBakulin]

I found this keyboard layout file of 48GII,maybe it will be useful.

Moderator note: Thank you for your post, but the .zip file attached has been removed to ensure no unintentional malware is posted.

[Claudio L.]

(11-10-2019 02:25 AM)jpcuzzourt Wrote:  I see now that the 50G keyboard isn't a match either - just a lot closer than the 39GS's layout. So I'm using an image from the user manual pdf that describes the keyboard layout. Good enough for now, and I understand this is beta and will probably change anyway. But if you can guide me to any better overlay graphics, I'd appreciate it lotses. Thanks.

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. The ideal overlay should be in a vector format (SVG or similar), so it can be printed at exact size, and also modified by the users using free tools. After all, you can customize the keyboard to your liking so people might want to move or add a few shortcuts.
You are right that being a beta things get added all the time. Change... not so much, once I get used to something being in one place I don't like to change it.

[MaximBakulin]

Keyboard layout file of 48GII calc in *.svg format.