The last couple of months were not the most productive but a lot got done in the project. The standalone compiler is now working and integrated into the build system. Libraries can now define objects like menus, command help and error messages in plain RPL. These RPL files allow easier translation to other languages, as well as providing an easy way for users to customize the system menus to their liking.

There's an ongoing effort now to review the libraries one by one, checking the commands that were implemented for correctness and compatibility, adding help for each command, adding menus, and any secondary commands that belong in a library but weren't implemented in the initial phase (like STO+, STO-, etc.).

As part of this effort, quite a few commands were implemented recently. The detailed status page has been updated with the latest implementations, and now the website also has a "todo" list with the tasks that are likely to be done next in the Project Status page.

On the hardware side, the auto-off feature is now enabled by default after 30 seconds of inactivity. This can be configured but there's no GUI to do that yet.

Slow but steady, the project keeps moving forward.

The past:

It's been two years since the newRPL project was born. The first year (2014) was almost entirely dedicated to the basic RPL language core and its many objects. The second year (2015) saw the project user interface develop, thanks to a Qt GUI front-end, and also saw the project become usable as a basic calculator on the 50g hardware.

The present:

Currently there's ongoing work in the menus and command help systems. However, the help, as well as other messages in the user interface need to be easy to replace, in order to support multiple languages. Internationalization needs to happen before these systems operate properly, so there's a barrier preventing massive implementation of menus at the moment.

2016 and beyond:

The first challenge is to be able to easily define the menus, their commands and help. The simplest and more portable way is to define the menus as RPL lists, ready to be used by TMENU. In order to do that, a new stand-alone newRPL compiler is needed.

  • The first task of 2016 is to make this new compiler work, and integrate it into the build process of the main projects. This will allow not only to define menus, but to include any other arbitrary RPL code in ROM.
  • After that, the interactive stack is the next pending item to provide a more complete user experience.
  • The command line is still lacking some refinement: cut/copy/paste, search and search/replace,
  • Add the last few missing object types: tags and hex strings (or some equivalent arbitrary data object)
  • Revisit all the commands already implemented for completeness and correctness.
  • Implement more commands, the goal for 2016 would be to reach the 25% mark in the detailed project status

There's great challenges ahead. Now it's time to work on them. 

The soft-menu engine is ready to go.
The engine is quite more flexible than the old one, while it remains mostly compatible.
The basic format is the same:
{ Item1 Item2 ... }
Each item can be a single object or a list with 3 individual components:
Item1   ...or... { Display Action Help }
When the item is an object, it will simply be used as follows:
  • An IDENT will be looked up as a variable, and the actions will behave as in the VARS menu. If it happens to be a directory name, then it will look like a directory does in the VARS menu. Long-press will display a preview of the contents of the variable.
  • A UNIT object with a numeric portion equal to 1 will be displayed without the numeric portion, and it will behave as if it was in the UNITS menu.
  • A command will work as expected, but also help will be automatically displayed upon long-press.
  • All other objects will be decompiled for Display, executed for action, and no help will be provided.

When the item is a list, there's 3 main components:


It can be a single object or a list with 2 elements. When it's a single object, it will behave as follows:

  • A program will be executed, and it must leave one object on the stack, which will take its place as the Display object.
  • A GROB will be displayed as-is in the soft menu.
  • A string will be displayed without quotes
  • A UNIT with a quantity of 1 will be displayed without the numeric part.
  • All other objects will be decompiled and the resulting string shown on the soft menu

The display object can be a list with 2 elements: { Display Decoration }

The Display object works as described above, while the decoration must be an integer that indicates if the element has to be displayed normally, inverted, as a directory, with a "checked" checkmark, with a "unchecked" checkmark, etc.


The action object will be executed when the user activates the soft menu. It can be an object, or a list of 3 or 5 components:

Action (all key combinations cause the same action)

{ Normal Left-Shift Right-Shift } (a different object will be called when the user presses the item in each shift state)

{ Normal Left-Shift Right-Shift Left-Hold-Shift Right-Hold-Shift } (a different object will be called when the user presses the item in each shift state, in this case it also distinguishes between shift and shift-hold presses)

When an action object is executed, the following rules are followed:

  • A single command or operator will be executed, or its name will be inserted in the editor if the command line is active
  • A UNIT object provides various actions depending on the shift used, similar to the UNITS menu.
  • An IDENT object has various actions, similar to variables in the VARS menu.
  • All other objects will be XEQ'ted.


The help object can only be a string. The string will be displayed when the user long-presses the soft-key.

Optionally, the item may not have a Help object (defined only as { Display Action }).


So where's the extra flexibility?

The display object can be a program! This allows to programatically change a menu item appearance.

A while ago, a benchmark was developed based on a slowly converging series, which was executed on the 50g and under newRPL as well.

For a more extensive discussion of the program utilized, see this discussion:

Originally, the benchmark compared userRPL with newRPL, but now that same benchmark will be used to compare the old newRPL results using the mpdecimal library versus the new decimal library. The userRPL result will be left there for comparison.

For the new library, two numbers are reported, the first one as perceived by the user including a period at slow speed, and a second one at full speed. The original results were reported before the clock management features were in place, therefore they were executed at full speed. Another difference to consider is that the old decimal library was most efficient when precision was a multiple of 9 (hence the choice of 36, 108 and 1008 digits). The new library is most efficient when the precision is a multiple of 8, so selecting 36 digits causes 40 digits to be used internally, with 4 digits being discarded at final rounding.


Algorithm userRPL newRPL/mp newRPL/dec
Series - 12 digit precision 87.4 s - 1.094s / 0.666s
Series - 36 digit precision - 0.893s 1.200s / 0.773s
Series - 108 digit precision - 1.615s 1.531s / 1.105s
Series - 1008 digit precision - 10.843s 5.887s / 5.459s

At 1008 digits, the speedup is almost 2x versus the old library, confirming that the extra effort of writing a new variable precision library paid off.

Back to comparing with classic userRPL, the speedup at the same 12-digit precision is 130x, while using the default 32-digit precision the speedup is still 118x.