newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[rprosperi]

(03-01-2017 04:05 AM)Claudio L. Wrote:  ...Let's say a typical routine that reads an integer number directly from the keyboard using WAIT. You'll be dealing with the numbers, Enter, Backspace, and perhaps cursors left and right.

...Do you still see no benefit?

Ah, as I feared, I wasn't following the proper context for the discussion. If this proposal only pertains to WAIT and related keyboard input commands, then this may have merit, and I also agree that for these cases, all machines differ.

I thought the proposal was to replace use of the rc.p parameters in all use cases, such as key assignments, etc. where I think the existing system should be retained.

Sorry for being only partially in-touch, thanks for clarifying.

[Han]

I am a bit late for this, but on the SD<blah> commands, I think they don't show up well on the menus. What I mean is that all the menu items show SDxyz so that we barely actually see what the menu button corresponds to. I think it would be better to make the commands <blah>SD. For example, instead of SDCRDIR, I think CRDIRSD would show up better. Suppose there is a menu button for all the SD commands. We press this menu button, which then shows pages of SD related commands. In the menu, I find it more useful to have the command first with a suffix of SD because I can see more of the command name since I already know that they are all SD-related. It seems that having "SD" always as the first two characters is neither as informative, and even redundant in the case of having browsed into these pages of commands.

[Han]

Question regarding the newRPL matrix object: the Saturn matrices had 5 nibbles that provided data type information (e.g. matrix of complex numbers) but there does not seem to be any such information for newRPL matrices. Any object is acceptable (which is fine -- great, in fact) but it seems based on what I have distilled from the sources that the only way to check if a matrix is completely real/complex is to scan each element. Hopefully I am wrong. Is there a document that provides the internal data structure of each object (short of reading through all the .c files from each library)?

[Claudio L.]

(03-01-2017 04:29 AM)rprosperi Wrote:  Ah, as I feared, I wasn't following the proper context for the discussion. If this proposal only pertains to WAIT and related keyboard input commands, then this may have merit, and I also agree that for these cases, all machines differ.

I thought the proposal was to replace use of the rc.p parameters in all use cases, such as key assignments, etc. where I think the existing system should be retained.

Sorry for being only partially in-touch, thanks for clarifying.

First of all, *NEVER* apologize for expressing a valid opinion. I value everybody's input, whether they like or dislike what I did, and I acknowledge that this forum will always be very averse to change, understandably being a "museum".
As a matter of fact, I'm thinking now that the correct approach would be:
* Keep the string because it will make *new* programs more portable across devices, and code in general much easier to understand.
* Add 2 commands to convert rc.p format to string and vice versa, so if you are porting userRPL code to newRPL, all you have to do is add RCP->KEYCODE right after every WAIT. (the command name might vary, suggestions welcome). These 2 commands will have a conversion table rc <-> key_name that will have to change from device to device.

BTW, I am effectively using the string for all cases, including key assignments, wouldn't be consistent if I don't.

[Claudio L.]

(03-01-2017 04:14 AM)Han Wrote:  I wonder if perhaps we might benefit from an NTHCHAR command (assuming the three, single-character format I proposed). 1 NTHCHAR for the key, 2 NTHCHAR for the shift, and 3 NTHCHAR for the modifier. I think it would be fairly simple to code and (negligibly?) faster than NTHTOKEN and it keeps the return string to exactly 3 characters.

I'll think about your proposal, I like fixed length, not as easier to read when you are looking at code on the screen but worth exploring, perhaps we can use some Unicode symbols for some keys.
I will add NTHCHAR because I think it's useful and clean (not only for this purpose, but in general).
I will also add rc.p <-> String keycode conversion commands to improve compatibility.

[Claudio L.]

(03-01-2017 05:05 AM)Han Wrote:  I am a bit late for this, but on the SD<blah> commands, I think they don't show up well on the menus.

I know, I don't like the way everything looks the same on the menu. The long press showing the full name of the commands helps a bit but is not enough.
Putting SD at the end hurts the autocomplete, the idea is you type SD and now all SD commands are available with Alpha-hold + cursors up/down, making it easier to find the one without using the menu.

(03-01-2017 06:24 PM)Han Wrote:  Question regarding the newRPL matrix object: the Saturn matrices had 5 nibbles that provided data type information (e.g. matrix of complex numbers) but there does not seem to be any such information for newRPL matrices. Any object is acceptable (which is fine -- great, in fact) but it seems based on what I have distilled from the sources that the only way to check if a matrix is completely real/complex is to scan each element. Hopefully I am wrong. Is there a document that provides the internal data structure of each object (short of reading through all the .c files from each library)?

The matrix API is quite incomplete yet, but as of now there's no way other than checking each element's type. This might change if I find it too slow, but usually you would only do that once when you check arguments, then you decide if a numerical or symbolic method is applicable.
If we implement some bits telling you if a matrix is numeric, complex, symbolic, etc. then the scan would have to be done after each and every matrix operation in order to leave the resulting matrix with proper flags. Might be faster if the scan is done only when a command needs to know this.

Regarding docs: the developer's docs should do that, but it's quite old and incomplete right now, there's basically no objects there at all. I should write something with all object types low-level access, I just never had the time.

[Han]

(03-01-2017 08:50 PM)Claudio L. Wrote:  

(03-01-2017 05:05 AM)Han Wrote:  I am a bit late for this, but on the SD<blah> commands, I think they don't show up well on the menus.

I know, I don't like the way everything looks the same on the menu. The long press showing the full name of the commands helps a bit but is not enough.
Putting SD at the end hurts the autocomplete, the idea is you type SD and now all SD commands are available with Alpha-hold + cursors up/down, making it easier to find the one without using the menu.

Would aliases help? Libraries on the HP48 series allowed a command to have several names. At the sake of having extra command names, it would allow us to have both SD<command> and <command>SD

Quote:The matrix API is quite incomplete yet, but as of now there's no way other than checking each element's type. This might change if I find it too slow, but usually you would only do that once when you check arguments, then you decide if a numerical or symbolic method is applicable.
If we implement some bits telling you if a matrix is numeric, complex, symbolic, etc. then the scan would have to be done after each and every matrix operation in order to leave the resulting matrix with proper flags. Might be faster if the scan is done only when a command needs to know this.

Ideally these commands would work on symbolic matrices too once all is said and done. For now I'll put a check for element types (complex vs real vs other) to be used during argument checking.

[rprosperi]

(03-01-2017 08:22 PM)Claudio L. Wrote:  First of all, *NEVER* apologize for expressing a valid opinion. I value everybody's input, whether they like or dislike what I did, and I acknowledge that this forum will always be very averse to change, understandably being a "museum".
As a matter of fact, I'm thinking now that the correct approach would be:
* Keep the string because it will make *new* programs more portable across devices, and code in general much easier to understand.
* Add 2 commands to convert rc.p format to string and vice versa, so if you are porting userRPL code to newRPL, all you have to do is add RCP->KEYCODE right after every WAIT. (the command name might vary, suggestions welcome). These 2 commands will have a conversion table rc <-> key_name that will have to change from device to device.

BTW, I am effectively using the string for all cases, including key assignments, wouldn't be consistent if I don't.

I was apologizing for not having read the thread carefully enough to get that the conversation was about WAIT, not for the opinion (fortunately the correct one ) though I guess it turns out the context being discussed really did include all cases of key code use.

It's possible the string system will become intuitive, only use will tell that for sure, but I'm glad you've decided to include the conversion commands. For ASN and STOKEYS, how about allowing both formats? Neither of these commands is time-sensitive, so the impact of determining which style (string or rc.p) to use (by peeking at the 2nd argument) will have no real effect other than to be more flexible. In such case, it's reasonable to require the full STOKEYS list use only 1 type of key code. RCLKEYS is less important (for me) so the default format of output (strings) is fine.

[Claudio L.]

(03-02-2017 12:12 AM)rprosperi Wrote:  For ASN and STOKEYS, how about allowing both formats? Neither of these commands is time-sensitive, so the impact of determining which style (string or rc.p) to use (by peeking at the 2nd argument) will have no real effect other than to be more flexible. In such case, it's reasonable to require the full STOKEYS list use only 1 type of key code. RCLKEYS is less important (for me) so the default format of output (strings) is fine.

I can make ASN work with rc.p code (actually, it was renamed to ASNKEYS precisely because of the argument difference), but there's more to it: The string can represent more planes and key messages than rc.p code so using the old system you would miss out on some capabilities. Also, it requires a context number which indicates when the key definition is active, so you can have multiple definitions for the same key and key plane but to be used on different contexts (while at the stack, while in the command line editor, at the interactive stack, at a user custom form, etc.).
RCLKEYS and STOKEYS are means to backup/restore only, not for bulk editing of keys. The list format is internal and not meant to be edited by the user. No conversion or checks are happening during RCLKEYS/STOKEYS. Perhaps there should be a conversion to human readable string on RCLKEYS and reverse conversion on STOKEYS, but is not currently implemented.

[Claudio L.]

(03-01-2017 09:01 PM)Han Wrote:  Would aliases help? Libraries on the HP48 series allowed a command to have several names. At the sake of having extra command names, it would allow us to have both SD<command> and <command>SD

It's also allowed in newRPL, all you have to do is declare the commands independently, then make it fall to the same case XXX: statement for execution. It can quickly pollute the name space, as some people pointed out when I proposed to have SIN, SINR, SIND, SING for the different angle formats. The idea didn't fly back then and I think it wouldn't fly now.
I can try putting SD at the end to see how it looks on the menu, there will be many cases where it will still show the same name (SDOPENRD, SDOPENWR, SDOPENAPP, SDOPENMOD will all read "OPEN" in the menu!). But using less letters for the commands makes it more cryptic to read, as-is at least when you read a program you can guess that SDOPENWR is opening a file for writing on the SD card.

(03-01-2017 09:01 PM)Han Wrote:  Ideally these commands would work on symbolic matrices too once all is said and done. For now I'll put a check for element types (complex vs real vs other) to be used during argument checking.

Yes, I think that's the right approach, as you will probably need different algorithms for numeric and symbolic matrices. For example, I implemented the Bareiss inversion procedure because it's well suited for symbolics, but it's not efficient for numeric matrices and I have no idea how it will behave on ill conditioned matrices, so perhaps we need to add a more adequate numeric algorithm for purely numeric matrices.

Also, you won't be able to read numbers and operate on them directly, you'll always have to push them to the stack and call the overloaded operator. For instance, a complex number can be in rect or polar, if polar it can be in any angle system. This is all taken care by the operator, you'd have to reproduce all that if you want to have a quicker algorithm. In other words, you'll be writing an RPL algorithm, just coded in C.

When you implement the checks, don't go over each item in the matrix, get a pointer after the matrix hash table and check the objects as a list. Much faster since repeated objects are not stored.

[rprosperi]

(03-02-2017 04:50 PM)Claudio L. Wrote:  RCLKEYS and STOKEYS are means to backup/restore only, not for bulk editing of keys. The list format is internal and not meant to be edited by the user. No conversion or checks are happening during RCLKEYS/STOKEYS. Perhaps there should be a conversion to human readable string on RCLKEYS and reverse conversion on STOKEYS, but is not currently implemented.

I disagree, STOKEYS is much more flexible (and easier to use in many cases) than ASN, particularly when setting more than 1 assignment. Also, when changing some assignments, it's easiest to RCLKEYS, edit the list and then STOKEYS to save changes. In fact, the manual specifically recommends STOKEYS when making multiple assignments. Finally, STOKEYS also is the way one restores the default assignments via the initial "S" in the list.

I like the extra context modes, it will allow a bewildering set of assignments (a good thing, I think). So this is a benefit too.

Will CST be affected? I.e. can CST menu assignments be extended with the additional planes and contexts?

[Claudio L.]

(03-02-2017 05:27 PM)rprosperi Wrote:  I disagree, STOKEYS is much more flexible (and easier to use in many cases) than ASN, particularly when setting more than 1 assignment. Also, when changing some assignments, it's easiest to RCLKEYS, edit the list and then STOKEYS to save changes.

This I understand and agree, RCLKEYS/STOKEYS should have a translation to the internal format, but should be presented in user-editable form.

(03-02-2017 05:27 PM)rprosperi Wrote:  In fact, the manual specifically recommends STOKEYS when making multiple assignments. Finally, STOKEYS also is the way one restores the default assignments via the initial "S" in the list.

I like the extra context modes, it will allow a bewildering set of assignments (a good thing, I think). So this is a benefit too.

The reason is recommended is because they want to assign single commands which can only be typed inside a list. This is not needed in newRPL, you can put the command inside a program and it will work well.

The S feature doesn't exist in newRPL. Why? Because its purpose is to enable or disable the default behavior. This is exactly what changing the context does. Some contexts exist in the system and have default key assignments (like the stack, interactive stack, editor). Now other (user) contexts are a blank canvas. The context switching will be tied to the Forms engine, you can define as many contexts as you want/need for different activities in your application (like data input, viewing a plot, etc). You only make the custom assignments once at the beginning of your program, then simply switch contexts and keys will activate/deactivate. Context 0 is a wildcard for a key that works on all contexts.
Default behaviors are always there for the standard contexts and cannot be disabled globally (but can be overridden individually with a key definition). When your application ends, context goes back to the stack and all keys go back to normal, whether you cleanup your definitions or not.

In case you override an important key (like ENTER) in the stack and can't use the calc anymore, there's a flag to disable custom keys in the menu. I'll eventually add a shortcut with On+SOMETHING that disables custom keys.

(03-02-2017 05:27 PM)rprosperi Wrote:  Will CST be affected? I.e. can CST menu assignments be extended with the additional planes and contexts?

Menus are a completely different definition from keys, and for now are completely independent from contexts, although each Form will have their own keyboard context and menu, hence they will indirectly be linked. But to answer your question, menus won't be affected by the change.
Menu definitions support all planes except no key_UP, key_DN, or repeat events (just press and long press with various shifts).
Oh, and there's no 'CST' anymore. You can assign any variable identifier to the menu (as in 'MYVAR' TMENU), in other words, there's as many 'CST' menus as you want, named whatever you want.
There will be (eventually) a key named CST (still don't know where to put it in the keyboard), that will run a menu named 'CST' for old times sake.

[Helix]

(03-01-2017 08:50 PM)Claudio L. Wrote:  

(03-01-2017 05:05 AM)Han Wrote:  I am a bit late for this, but on the SD<blah> commands, I think they don't show up well on the menus.

I know, I don't like the way everything looks the same on the menu. The long press showing the full name of the commands helps a bit but is not enough.
Putting SD at the end hurts the autocomplete, the idea is you type SD and now all SD commands are available with Alpha-hold + cursors up/down, making it easier to find the one without using the menu.

Another possibility would be a key combination showing the names of all commands in the current active menu. This would avoid the boring long presses on all commands to find the right key. This would also be helpful with menus of submenus, to show the entire names (a long press in these menus does nothing).

The 50g does that, with Right shift – down arrow, and I find it useful.

(11-24-2016 03:47 AM)Claudio L. Wrote:  * "Back" menu key is at UNDO (M). Use it with right-shift for the first menu, and right-shift-hold for the second menu. There's a 10 level menu UNDO.

I'm late too, but wouldn't it be more logical to use Right - shift for the active menu, regardless it is in position 1 or 2, and right-shift-hold for the other menu? That would not change the behavior if the active menu is on top, but it would be more convenient if the active menu is at the bottom.

[rprosperi]

(03-02-2017 10:38 PM)Claudio L. Wrote:  The S feature doesn't exist in newRPL. Why? Because its purpose is to enable or disable the default behavior. This is exactly what changing the context does. Some contexts exist in the system and have default key assignments (like the stack, interactive stack, editor). Now other (user) contexts are a blank canvas. The context switching will be tied to the Forms engine, you can define as many contexts as you want/need for different activities in your application (like data input, viewing a plot, etc). You only make the custom assignments once at the beginning of your program, then simply switch contexts and keys will activate/deactivate. Context 0 is a wildcard for a key that works on all contexts.
Default behaviors are always there for the standard contexts and cannot be disabled globally (but can be overridden individually with a key definition). When your application ends, context goes back to the stack and all keys go back to normal, whether you cleanup your definitions or not.

In case you override an important key (like ENTER) in the stack and can't use the calc anymore, there's a flag to disable custom keys in the menu. I'll eventually add a shortcut with On+SOMETHING that disables custom keys.

Some of these (impressive) extensions will be very interesting to check-out, but this raises an interesting question about newRPL (which may have been answered long ago and I missed it) and that is: what is the plan for documenting the changes in newRPL from vanilla 50g RPL? Various changes include different syntax, arguments, etc. which is straightforward to document (though not necessarily easy) but some, like this one, introduce totally new concepts, which are harder to document and typically need well thought-out examples to explain.

(03-02-2017 10:38 PM)Claudio L. Wrote:  Oh, and there's no 'CST' anymore. You can assign any variable identifier to the menu (as in 'MYVAR' TMENU), in other words, there's as many 'CST' menus as you want, named whatever you want.
There will be (eventually) a key named CST (still don't know where to put it in the keyboard), that will run a menu named 'CST' for old times sake.

Guess I should have asked about CUSTOM, and my 48-ness is showing... This expanded menu scheme sounds great, and clearly what it should have been all along.

Thanks

[Claudio L.]

(03-03-2017 02:32 AM)rprosperi Wrote:  Some of these (impressive) extensions will be very interesting to check-out, but this raises an interesting question about newRPL (which may have been answered long ago and I missed it) and that is: what is the plan for documenting the changes in newRPL from vanilla 50g RPL? Various changes include different syntax, arguments, etc. which is straightforward to document (though not necessarily easy) but some, like this one, introduce totally new concepts, which are harder to document and typically need well thought-out examples to explain.

Yes, there's some basic docs on the website, but my time is so limited that either I code or I document what I code. Luckily the team is expanding and I have some help coding, but we don't have a doc writer on board, they are really hard to come by.
The WP34 project was lucky they got one on the team, permanent vacations or not he did a great job with those manuals.
I guess once newRPL reaches the 48 level (meaning complete but no CAS) I'll have to go into bugfixes-only mode for let's say one full year, so the team can focus on writing docs and nothing but docs.

(03-03-2017 02:32 AM)rprosperi Wrote:  ... and my 48-ness is showing...

Can't blame you, I configured my 50g to work more like a 48, and newRPL is more 48ish than 50ish if you think about it.

[Claudio L.]

(03-03-2017 01:27 AM)Helix Wrote:  Another possibility would be a key combination showing the names of all commands in the current active menu. This would avoid the boring long presses on all commands to find the right key. This would also be helpful with menus of submenus, to show the entire names (a long press in these menus does nothing).

The 50g does that, with Right shift – down arrow, and I find it useful.

We could do that, not sure it's a definitive solution but it might help.

(03-03-2017 01:27 AM)Helix Wrote:  I'm late too, but wouldn't it be more logical to use Right - shift for the active menu, regardless it is in position 1 or 2, and right-shift-hold for the other menu? That would not change the behavior if the active menu is on top, but it would be more convenient if the active menu is at the bottom.

Makes sense, I'll put it in the bug tracker.

[rprosperi]

(03-03-2017 03:33 PM)Claudio L. Wrote:  Yes, there's some basic docs on the website, but my time is so limited that either I code or I document what I code. Luckily the team is expanding and I have some help coding, but we don't have a doc writer on board, they are really hard to come by.
The WP34 project was lucky they got one on the team, permanent vacations or not he did a great job with those manuals.
I guess once newRPL reaches the 48 level (meaning complete but no CAS) I'll have to go into bugfixes-only mode for let's say one full year, so the team can focus on writing docs and nothing but docs.

I agree, it would be tremendously helpful to have Walter create documentation for newRPL, but alas, he does not dabble with battleships; too bad too, as I would enjoy one of his manuals on newRPL, with the humor, insights and well-chosen examples we've become familiar with.

I like your plan to release the core numeric system for users to test, explore, report bugs, document, etc. while planning/working on CAS components in parallel. Though not the core reason to do so, the real-world effect is newRPL 1.0 will be available sooner.

(03-03-2017 03:33 PM)Claudio L. Wrote:  Can't blame you, I configured my 50g to work more like a 48, and newRPL is more 48ish than 50ish if you think about it.

I agree it is, and I agree it's a good thing! Thanks.

[Han]

Documentation is actually pretty easy with \( \LaTeX \) since you can programmatically design the structure of the manual. So long as the commands are well commented, it would not be too difficult to put together good documentation. The newrpl-ui program provides screenshots; and I have a few templates I have created that might be useful for manuals.

[Claudio L.]

(03-04-2017 12:44 AM)Han Wrote:  Documentation is actually pretty easy with \( \LaTeX \) since you can programmatically design the structure of the manual. So long as the commands are well commented, it would not be too difficult to put together good documentation. The newrpl-ui program provides screenshots; and I have a few templates I have created that might be useful for manuals.

Hehe... I have templates too... EMPTY ONES! :-)
I don't think formatting is difficult, creating the content is. Thinking of good examples, making sure they are correct, etc. I'm not a good writer, look at the couple of docs I created: boring and plain from start to end.
You are right that LATEX would allow accurate formatting to print hard copies, and once the templates are good, it's relatively painless to add content (if you know LATEX, I'm a little rusty but I've used it quite a bit a few years back).
On the other hand, HTML allows templating too, and would allow us to put the content online (for better searches!). I don't know, I'm outside my area of expertise.

[pier4r]

Hi. from the first post I read that firmware for testing is available, while from the project status ( here) I do see that the project is covering almost everything that it wanted to cover (I also like the "will not implement", clear decision always helps).

I am aware of the possibility of improving the current implementation, as almost in every software, but my question is: is the firmware stable? May I risk bricking my hp 50g or it is very unlikely?

Because checking the benchmark here, the speed improvement is pretty awesome. I wonder my last intensive tests how long they will last with the new RPL.

Aside from that, I do assume that the documentation is not yet complete (or extensive enough) so one has to go trial and error to discover which difference there is with a userRPL command and a newRPL command. But that's a minor problem.

Once again, thumbs up for the project and thanks for sharing!