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

[Helix]

(10-25-2015 01:52 AM)Claudio L. Wrote:  

(10-24-2015 08:30 PM)Helix Wrote:  I'm not sure I undestand what you mean. An identifier without quotes is evaluated immediately. Could you give a short example of what you think?

Yes, but the quotes work only when the identifier is by itself, not inside an expression. The idea is that 'X.+2' evaluates X immediately, because the user "requested" it by adding the trailing dot.
There should be a command to make certain variables in an expression evaluate, perhaps:
'X^2+Y' 'Y' ->EVALNOW would produce the expression 'X^2+Y.' which would cause Y to be evaluated immediately next time the expressions is executed or operated upon. If Y is 4, then:

'X^2+Y' 1 + --> 'X^2+Y+1'
'X^2+Y.' 1 + --> 'X^2+5'

In the second case, only the Y was evaluated automatically, X will not be evaluated unless EVAL is called on the expression.

What I meant is that the name ->APPROX doesn't really work for variables, should be something like the EVALNOW above.

Thank you for your explanations, I understand now.
For this command, another possible name could be VAREVAL, or VEVAL, because it allows the evaluation of a variable, and this name is more consistent with existing RPL commands like PEVAL, SYSEVAL, KEYEVAL…
Or it could be also IMEVAL or IMDEVAL, for "immediate evaluation"…

(10-25-2015 12:45 PM)Claudio L. Wrote:  

(10-23-2015 10:04 PM)Helix Wrote:  ALPHA mode:
- it is easy to use now, and I can say it is intuitive for me.
- I think that ENTRY works now as it should work in program mode. In algebraic mode, I think that some keys should remain active, for example the HIST key (or the STO key depending of the settings for the menus). This would permit to create a variable A with the sequence:
' ALPHA A ' ' HIST (or ' ALPHA+A HIST) instead of ' ALPHA A ENTER HIST

This is no different from the 50g. Once you are in alpha mode, STO, HIST, etc. they all have letters, so I don't know how we could keep it active.
Alpha-hold+A then HIST does what you are looking for.

I've made a mistake in my previous post. Here is the corrected suggestion:
' alpha A alpha alpha HIST doesn't work
' alpha-hold+A HIST is equivalent, and doesn't work either.
I happen to use the equivalent sequence with my 50g when the variable A already exists, so I think this possibility is missing in the current version of newRPL.
The same thing applies to EVAL instead of HIST (but probably not very useful with EVAL).

(10-25-2015 12:45 PM)Claudio L. Wrote:  Autocomplete is quite simple and only tries to save you keystrokes, it's not a heuristic search engine. For instance, I found it very useful when I was doing some unit conversions the other day, just type CON and Alpha+Right will complete "CONVERT".
It's not intended as a replacement for a catalog. If you want a catalog where you can search for a command, that's a different feature, which will likely exist at some point.

I can understand that you find this feature useful, but if the list will remain incomplete and disordered I'm almost sure that I will never use it. In that case, to answer one of your previous questions, help comments for these commands in the status area is certainly not a priority for me.

[Claudio L.]

(10-28-2015 12:05 AM)Helix Wrote:  I've made a mistake in my previous post. Here is the corrected suggestion:
' alpha A alpha alpha HIST doesn't work
' alpha-hold+A HIST is equivalent, and doesn't work either.
I happen to use the equivalent sequence with my 50g when the variable A already exists, so I think this possibility is missing in the current version of newRPL.
The same thing applies to EVAL instead of HIST (but probably not very useful with EVAL).

I got it now! I forgot to bind all those keys when in 'A' mode. Easy fix.

(10-28-2015 12:05 AM)Helix Wrote:  I can understand that you find this feature useful, but if the list will remain incomplete and disordered I'm almost sure that I will never use it. In that case, to answer one of your previous questions, help comments for these commands in the status area is certainly not a priority for me.

I see. The list is not incomplete, it contains all commands currently implemented (is complete as far as newRPL development status is). As new commands are added to libraries, they will automatically "pop-up" in the autocomplete feature.

I'll think about it and see if something like that can be implemented efficiently somehow. The only issue is that it needs to allocate memory for potentially hundreds of suggestions to be able to sort them later. Right now it simply gives the current suggestion to one library and asks for the next one, which requires no memory and is quite fast. Obtaining all suggestions on every keystroke means scanning through all commands in all libraries every time, store them somewhere, then sort. This is CPU and memory consuming. To make things worse, the current text in the command line is at the end of TempOb (for easy growth/shrink). Allocating memory means that text would need to be copied again, which compounds on the CPU/memory issue. You'd be possibly triggering GC's in between keystrokes, and that can degrade the user experience with "hiccups" in the text editor.
While it seems a simple feature, internally is quite complex and it would consume resources much better spent elsewhere. But I'll think about it, perhaps I can find a way.

[Han]

(10-28-2015 01:50 PM)Claudio L. Wrote:  

(10-28-2015 12:05 AM)Helix Wrote:  I've made a mistake in my previous post. Here is the corrected suggestion:
' alpha A alpha alpha HIST doesn't work
' alpha-hold+A HIST is equivalent, and doesn't work either.
I happen to use the equivalent sequence with my 50g when the variable A already exists, so I think this possibility is missing in the current version of newRPL.
The same thing applies to EVAL instead of HIST (but probably not very useful with EVAL).

I got it now! I forgot to bind all those keys when in 'A' mode. Easy fix.

(10-28-2015 12:05 AM)Helix Wrote:  I can understand that you find this feature useful, but if the list will remain incomplete and disordered I'm almost sure that I will never use it. In that case, to answer one of your previous questions, help comments for these commands in the status area is certainly not a priority for me.

I see. The list is not incomplete, it contains all commands currently implemented (is complete as far as newRPL development status is). As new commands are added to libraries, they will automatically "pop-up" in the autocomplete feature.

I'll think about it and see if something like that can be implemented efficiently somehow. The only issue is that it needs to allocate memory for potentially hundreds of suggestions to be able to sort them later. Right now it simply gives the current suggestion to one library and asks for the next one, which requires no memory and is quite fast. Obtaining all suggestions on every keystroke means scanning through all commands in all libraries every time, store them somewhere, then sort. This is CPU and memory consuming. To make things worse, the current text in the command line is at the end of TempOb (for easy growth/shrink). Allocating memory means that text would need to be copied again, which compounds on the CPU/memory issue. You'd be possibly triggering GC's in between keystrokes, and that can degrade the user experience with "hiccups" in the text editor.
While it seems a simple feature, internally is quite complex and it would consume resources much better spent elsewhere. But I'll think about it, perhaps I can find a way.

During firmware compile time, is it not possible to generate an alphabetical list of all commands and embed this list statically? Perhaps even generate an offset table for offsets to the first A command, first B command, etc. A hash table may also be useful. This is how the entries tables for Jazz and MASD were created for quick lookup.

So when a user is typing, it should be easy to search for possible matches with the offsets and hash tables. No sorting is needed since the list of command names have already be pre-sorted when compiling the firmware. The only cost here is ROM size.

[Han]

Also, instead of giving a description of the command, I think it would simply be more useful to specify the arguments of the command (similar to the USAG program for the HP48). The small amount of space at the bottom is enough to specify what the stack should look like upon using the command.

[Han]

(10-25-2015 12:31 PM)Claudio L. Wrote:  

(10-25-2015 11:31 AM)Han Wrote:  While I think the "dot" notation is nice for immediate evaluation, it really seems to be contrary to the whole notion of RPN.

'X^2+Y' 1 + --> 'X' SQ 'Y' + 1 +
'X^2+Y.' 1 + --> 'X' SQ Y + 1 +

This is exactly right, but I fail to see why it's contrary to RPN (??).

Waxing philosophical:

You're using an algebraic expression. That's not very RPN-like in my opinion. Now, I understand that it may be easier to understand the content of a program if a formula is written algebraically rather than using RPN to build the expression. However, we can add comments with @ and comments are not removed. Or are they removed? RPL programs will never be "readable" but that's not the goal of RPL. Otherwise, you would have created a separate program compiler for newRPL like the HP50G did for "algebraic" (i.e. non-RPL) programs. An RPL program should be RPL, and include comments to make the code more readable. Anyone looking at the code will not only learn from the RPL code but also from the comments.

Claudio L. Wrote:

Quote:All you are telling the machine is that you want the value of Y replaced ASAP.
I think for instance of a quadratic solver.
You have the generic equation:
'a.*X^2+b.*X+c.' stored somewhere

Then the user defines 'a', 'b' and 'c' to his liking.
Next time you operate on that expression, all 3 values will be immediately replaced, but not X, so you can display the final equation even if X has a value. Doing EVAL would also replace the X if it has any value. This way you control what gets replaced in the expression.
Currently, you'd need to make sure X doesn't exist in current or higher directories to get the equation.

(10-25-2015 11:31 AM)Han Wrote:  But even with the feature, I am not sure it would be used as described. If I wanted immediate substitution, I imagine that I would still end up double checking the value of Y prior to having the calculator actually include it into a formula. So a quick RCL of the contents of Y would most likely occur -- and at this point I may as well just build my formula with the Y value already on the stack.

Ah, but you are thinking interactively only. The dot in the expression is most useful when executed inside a program, since the mere presence of the symbolic in the runstream would trigger the replacement. Without the dot, you'd have to break down the expression in the program so you can evaluate the different parts and then reconstruct the symbolic.

Think of my example above:
Currently:
<< a 'X^2' * b 'X' * + c + >>
Proposed:
<< 'a.*X^2+b.*X+c.' >>

They produce the same result.

In the HP48, one could type 'X.' and get an 2-character identifier whose name is X followed by a period. This would break in newRPL. I am not suggesting this feature would not be useful. However, I think that the feature can be achieved in a different way. When the command line is active, using left or right shift with a variable will insert: 'VARNAME' RCL or 'VARNAME' STO depending on the shift. I recommend that the these key combinations instead reveal what is stored in the variable (maybe a preview) using the status area at the bottom, or (via the other shift) recall the contents into the program area. Thus, the "." operation can be achieved by pressing the [VAR] key, finding the variable, previewing its contents if necessary, and inserting the content of a directly into the command line.

OR

You could optionally make the "." operation a key sequence that only works with a command line present. So the idea of immediate substitution could even happen DURING edit mode as opposed to after hitting the ENTER key. This would be even more useful because you can determine whether or not the content of the variable is in fact what you wanted (as opposed to having to go back into the program and check the code to see if it was right).

Either way, it does not break compatibility with "oldRPL" insofar as "." trailing an identifer name is concerned

EDIT: just to be clear -- I'm not opposed to the feature itself (I think it's useful) but I would rather it be implemented in a way that is compatible with old RPL code.

[rprosperi]

(10-28-2015 02:30 PM)Han Wrote:  When the command line is active, using left or right shift with a variable will insert: 'VARNAME' RCL or 'VARNAME' STO depending on the shift. I recommend that the these key combinations instead reveal what is stored in the variable (maybe a preview) using the status area at the bottom, or (via the other shift) recall the contents into the program area. Thus, the "." operation can be achieved by pressing the [VAR] key, finding the variable, previewing its contents if necessary, and inserting the content of a directly into the command line.

OR...

I think the use of [LS] [Fn] and [RS] [Fn] to STO to, or RCL from, a variable is such a fundamental feature of command-line RPL that changing it's behavior should be avoided. I've no strong opinion about the other suggestions, but think that some 'core' behavior of RPL must be retained to provide a comfortable environment while users are exploring these interesting newRPL enhancements.

[Han]

(10-28-2015 09:24 PM)rprosperi Wrote:  

(10-28-2015 02:30 PM)Han Wrote:  When the command line is active, using left or right shift with a variable will insert: 'VARNAME' RCL or 'VARNAME' STO depending on the shift. I recommend that the these key combinations instead reveal what is stored in the variable (maybe a preview) using the status area at the bottom, or (via the other shift) recall the contents into the program area. Thus, the "." operation can be achieved by pressing the [VAR] key, finding the variable, previewing its contents if necessary, and inserting the content of a directly into the command line.

OR...

I think the use of [LS] [Fn] and [RS] [Fn] to STO to, or RCL from, a variable is such a fundamental feature of command-line RPL that changing it's behavior should be avoided. I've no strong opinion about the other suggestions, but think that some 'core' behavior of RPL must be retained to provide a comfortable environment while users are exploring these interesting newRPL enhancements.

They wouldn't be changed if there is no active command line. The suggestion was to change their behavior while a command line was active. When a command line is active those shifted key sequences only provide a typing aid as is currently implemented in the HP48-HP50 series.

[rprosperi]

(10-28-2015 09:45 PM)Han Wrote:  They wouldn't be changed if there is no active command line. The suggestion was to change their behavior while a command line was active. When a command line is active those shifted key sequences only provide a typing aid as is currently implemented in the HP48-HP50 series.

Ok, I see the subtle difference; as in most cases terminology is the culprit. By "active" you mean that some commands have already been entered, but ENTER not yet pressed. Doing so ( [RS] [F1] on a 48G) does the actual RCL and processes/terminates the command line. Is this what you mean as a typing aid?

[Han]

(10-28-2015 11:15 PM)rprosperi Wrote:  

(10-28-2015 09:45 PM)Han Wrote:  They wouldn't be changed if there is no active command line. The suggestion was to change their behavior while a command line was active. When a command line is active those shifted key sequences only provide a typing aid as is currently implemented in the HP48-HP50 series.

Ok, I see the subtle difference; as in most cases terminology is the culprit. By "active" you mean that some commands have already been entered, but ENTER not yet pressed. Doing so ( [RS] [F1] on a 48G) does the actual RCL and processes/terminates the command line. Is this what you mean as a typing aid?

Here's how it currently works:

1. On the HP48, with nothing in the command line (i.e all you see is the stack) pressing [RS] [A] (or [RS][F1] on the HP50G) would recall the contents of the variable corresponding to the [A] key or [F1] key. And pressing [LS] [A] while an object is in level 1 would replace the content of the corresponding variable with the object on the stack.

2. If the command line is active, then the command line is terminated (as if one were to press ENTER) and then the same (as described above) would apply if not in programming mode. Otherwise if programming mode is active then #3.

3. On the other hand, if the command line is active, and in programming mode (e.g. inside << >>), then pressing [RS][A] would merely type in 'VARNAME' RCL (where VARNAME is the actual name of the variable corresponding to the [A] key). This is what I mean by typing aid. The command line is not terminated and continues to stay active for further editing (presumably a program).

My proposal leaves #1 and #2 as-is. My proposal would, however, eliminate #3 so that [RS][A] would have a different behavior (i.e. either preview the contents of VARNAME, or actually recall it directly into the command line -- maybe the latter since that behavior would more closely resemble #3). This would apply to both programming entry as well as algebraic entry or whichever mode people prefer.

[Claudio L.]

(10-28-2015 02:01 PM)Han Wrote:  During firmware compile time, is it not possible to generate an alphabetical list of all commands and embed this list statically? Perhaps even generate an offset table for offsets to the first A command, first B command, etc. A hash table may also be useful. This is how the entries tables for Jazz and MASD were created for quick lookup.

Not really, at least not the way I designed the libraries.
The core has a simple API to communicate with libraries, and I don't want to break that because it would hurt the expandability of the system. Libraries decide freely what commands to expose and how to store them, so there's no list of commands that could be "extracted", at least not as far as the core system knows.
In the real world, since I copied the same template for all libraries, there's a uniformity in the declarations that could allow to extract a list of commands (not directly, with some parsing effort). But, that would only work for core libraries in ROM, the idea is that user libraries installed will be (future tense) automatically included in autocomplete, just by the fact they are installed in the system, and shouldn't matter if they are written in RPL or C.

[Claudio L.]

(10-29-2015 12:00 AM)Han Wrote:  My proposal leaves #1 and #2 as-is. My proposal would, however, eliminate #3 so that [RS][A] would have a different behavior (i.e. either preview the contents of VARNAME, or actually recall it directly into the command line -- maybe the latter since that behavior would more closely resemble #3). This would apply to both programming entry as well as algebraic entry or whichever mode people prefer.

Can I make a new proposal?
How about long press on a variable key shows a preview on full-width status area (like error messages), and this preview disappears as soon as the user releases the key.
It's slow (1 sec delay until long-press activates), but wouldn't break anything.

[rprosperi]

(10-29-2015 12:00 AM)Han Wrote:  Here's how it currently works:

1. On the HP48, with nothing in the command line (i.e all you see is the stack) pressing [RS] [A] (or [RS][F1] on the HP50G) would recall the contents of the variable corresponding to the [A] key or [F1] key. And pressing [LS] [A] while an object is in level 1 would replace the content of the corresponding variable with the object on the stack.

2. If the command line is active, then the command line is terminated (as if one were to press ENTER) and then the same (as described above) would apply if not in programming mode. Otherwise if programming mode is active then #3.

3. On the other hand, if the command line is active, and in programming mode (e.g. inside << >>), then pressing [RS][A] would merely type in 'VARNAME' RCL (where VARNAME is the actual name of the variable corresponding to the [A] key). This is what I mean by typing aid. The command line is not terminated and continues to stay active for further editing (presumably a program).

My proposal leaves #1 and #2 as-is. My proposal would, however, eliminate #3 so that [RS][A] would have a different behavior (i.e. either preview the contents of VARNAME, or actually recall it directly into the command line -- maybe the latter since that behavior would more closely resemble #3). This would apply to both programming entry as well as algebraic entry or whichever mode people prefer.

Thanks for the detailed comments and breakdown by mode. I understand now what you are suggesting - recalling the variable's current value and inserting into the program being entered indeed is analogous to the proposed 'trailing dot' notation's meaning, i.e. immediate evaluation. Neat.

Thanks for the patient comments and explanation.

[Claudio L.]

(10-29-2015 02:12 AM)rprosperi Wrote:  I understand now what you are suggesting - recalling the variable's current value and inserting into the program being entered indeed is analogous to the proposed 'trailing dot' notation's meaning, i.e. immediate evaluation. Neat.

Except it's not quite equivalent. It produces the same effect when typing on the command line, sure, but not the same effect when you are running a program. Basically you'd be hard-coding the contents of the variable at compile time, the trailing dot replaces the content of the variable at run time.

[Claudio L.]

(10-28-2015 02:30 PM)Han Wrote:  Waxing philosophical:

You're using an algebraic expression. That's not very RPN-like in my opinion. Now, I understand that it may be easier to understand the content of a program if a formula is written algebraically rather than using RPN to build the expression.

From more practical perspective: expressions are objects in the RPL world, they aren't against it. We are here defining the foundations of a brand new CAS that will operate and modify those expressions automatically. The user needs a way to pass information to the CAS on what should or should not be evaluated immediately.
One way to do it is through text in the expression itself (I don't claim is the only way or the best way).

(10-28-2015 02:30 PM)Han Wrote:  However, we can add comments with @ and comments are not removed. Or are they removed?

I didn't implement comments yet, but yes, we agreed that one flag will control whether the @ comments are kept or removed during compile. We also agreed that @@ comments would be permanent and override any flag settings.

However, the objective of the trailing dot is not to make the code readable by using expressions instead or RPL commands. Code beauty is merely a byproduct.
The real objective is to pass some information to the CAS, to tell we want that variable replaced immediately, or in other words, that the symbol is secondary and we are not interested in wasting time manipulating it.

(10-28-2015 02:30 PM)Han Wrote:  In the HP48, one could type 'X.' and get an 2-character identifier whose name is X followed by a period. This would break in newRPL.

The trailing dot was used in the 50g to distinguish integers from reals, which was already changed in newRPL to define whether numbers should be operated upon immediately on a symbolic (even if the operation introduces an error, hence the "approximated" name) or kept as-is (exactly as typed, or operated upon using only exact operations).
I think I'd rather have consistency in newRPL meaning of the dot than trying to keep a relatively unused feature of the old RPL.
If you have an old program using variables that end in dots, it's trivial to replace with 'Xdot' for example, before passing the source code to newRPL.
Just converting from HP48 codepage to Unicode will be more difficult than that.
I don't think it causes a serious incompatibility.

(10-28-2015 02:30 PM)Han Wrote:  EDIT: just to be clear -- I'm not opposed to the feature itself (I think it's useful) but I would rather it be implemented in a way that is compatible with old RPL code.

I know, and I like these discussions, it's the very reason why I write these ideas for public input. While I may disagree with you on some point, during this discussion you brought up an interesting new feature: the variable content preview. I like that and will be implemented soon, we just have to find the right key combination to bind it to. I'd like for it to work always, not just in ALG mode.
I'm thinking the long-press will work, but I'd have to move the VAR menu hide/show feature to another key, no big deal (but it was quite intuitive to have it in VARS).

[Helix]

(10-28-2015 01:50 PM)Claudio L. Wrote:  

(10-28-2015 12:05 AM)Helix Wrote:  I can understand that you find this feature useful, but if the list will remain incomplete and disordered I'm almost sure that I will never use it. In that case, to answer one of your previous questions, help comments for these commands in the status area is certainly not a priority for me.

I see. The list is not incomplete, it contains all commands currently implemented (is complete as far as newRPL development status is). As new commands are added to libraries, they will automatically "pop-up" in the autocomplete feature.

I'll think about it and see if something like that can be implemented efficiently somehow. The only issue is that it needs to allocate memory for potentially hundreds of suggestions to be able to sort them later. Right now it simply gives the current suggestion to one library and asks for the next one, which requires no memory and is quite fast. Obtaining all suggestions on every keystroke means scanning through all commands in all libraries every time, store them somewhere, then sort. This is CPU and memory consuming. To make things worse, the current text in the command line is at the end of TempOb (for easy growth/shrink). Allocating memory means that text would need to be copied again, which compounds on the CPU/memory issue. You'd be possibly triggering GC's in between keystrokes, and that can degrade the user experience with "hiccups" in the text editor.
While it seems a simple feature, internally is quite complex and it would consume resources much better spent elsewhere. But I'll think about it, perhaps I can find a way.

Don't worry about that. The autocomplete feature is an addition compared to the current RPL behavior, and I lose nothing if there is no alphabetic order. I agree too that the calculator memory and your spare time will be better used in implementing more important features!

The good news is that the autocomplete suggestions give a list of already implemented commands, so I will certainly investigate them.

[rprosperi]

(10-29-2015 12:02 PM)Claudio L. Wrote:  

(10-29-2015 02:12 AM)rprosperi Wrote:  I understand now what you are suggesting - recalling the variable's current value and inserting into the program being entered indeed is analogous to the proposed 'trailing dot' notation's meaning, i.e. immediate evaluation. Neat.

Except it's not quite equivalent. It produces the same effect when typing on the command line, sure, but not the same effect when you are running a program. Basically you'd be hard-coding the contents of the variable at compile time, the trailing dot replaces the content of the variable at run time.

Sure, yeah of course. But this provides a means to do this, if that is what is desired; using the original, which inserts the VAR RCL into the program lets you use the VAR value at run time (vs. compile time), is still avail able by just typing it. This way, both options (evaluate at compile-time or at run-time) are available.

And I agree these conversations are productive. Thanks for 'sharing your mind' as you build newRPL.

[Claudio L.]

(10-29-2015 09:23 PM)rprosperi Wrote:  Sure, yeah of course. But this provides a means to do this, if that is what is desired; using the original, which inserts the VAR RCL into the program lets you use the VAR value at run time (vs. compile time), is still avail able by just typing it. This way, both options (evaluate at compile-time or at run-time) are available.

And I agree these conversations are productive. Thanks for 'sharing your mind' as you build newRPL.

I'm thinking this is basically a "paste from variable" on the command line, so perhaps should be grouped with the copy/paste functions of the text editor?

[Claudio L.]

New version of the firmware (11-14-2015) with very small but important changes:

* Working OFF function! Now you can finally turn it off and on like a normal calculator. However, the On function still restarts from scratch, so it doesn't preserve the stack. This will be fixed soon.
* Minor internal changes to make it more emulator friendly (x49gp).

To try it on x49gp, you need to build x49gp from the latest sources (needs latest patch to run newRPL):

x49gp Official Git Repository

Then do the following steps:

1. Copy the newrplfw.bin firmware to the x49gp folder
2. Delete the files flash-noboot and flash-50g
3. Run 'make FIRMWARE=newrplfw.bin flash-50g' from the command line
4. Run './newconfig' to reset the calculator
5. Finally, just run the emulator with './x49gp config'.
   

[Claudio L.]

I just updated the firmware image with a bug fix that made the timers go too fast when waking up from power off, and also now it preserves the stack properly when coming back on.
So if you downloaded the firmware and it doesn't restore the stack when turning on, then re-download the new version.

[Han]

Wait so does the OFF key work only in x49gp? or is it now working on the real hardware?

EDIT: Answered my own question with a firmware upgrade: Yes, OFF works in real hardware. But another question: what was it that was the key to getting OFF to work (just out of curiosity)