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

[Claudio L.]

(01-22-2017 12:56 PM)Nigel (UK) Wrote:  

(01-20-2017 04:04 AM)Claudio L. Wrote:  It could be done, however, it directly affects performance of running code. The stack UNDO/REDO feature only takes a snapshot when the user starts a program from the UI, but never while a program is running so it doesn't cause any slowdown.
Making STO keep a copy of each thing it stores doubles (or more) the time it takes to store a variable, every single time you use STO, it can be disastrous for performance.

I wasn't thinking of having this feature active in programs; it is mistakes that I make from the keyboard that concern me! Thinking about it, it would be easy enough for a user to define a new STO command that places the old value in LAST_STO before storing the new value; can the user then bind this to the action of a left-shifted variable key?

Nigel (UK)

Yes, you can redefine anything. However, the menu keys are quite complex in their actions, I haven't really thought about writing a handler for that in RPL, as it would have to know somehow which variable is being displayed in the box.
Maybe I should add a command SAFESTO and use it or regular STO based on a flag.

[The Shadow]

(01-22-2017 08:42 PM)Claudio L. Wrote:  Yes, you can redefine anything. However, the menu keys are quite complex in their actions, I haven't really thought about writing a handler for that in RPL, as it would have to know somehow which variable is being displayed in the box.
Maybe I should add a command SAFESTO and use it or regular STO based on a flag.

Here's a thought: Maybe have two global variables in the .Settings directory that give the defaults for left-shift and right-shift on VAR identifier entries. Naturally, they would be STO and RCL by default, but people would be able to change them if they like.

Heck, you could throw in left-hold and right-hold, and the default decoration, and everything else!

[Claudio L.]

(01-22-2017 09:52 PM)The Shadow Wrote:  

(01-22-2017 08:42 PM)Claudio L. Wrote:  Yes, you can redefine anything. However, the menu keys are quite complex in their actions, I haven't really thought about writing a handler for that in RPL, as it would have to know somehow which variable is being displayed in the box.
Maybe I should add a command SAFESTO and use it or regular STO based on a flag.

Here's a thought: Maybe have two global variables in the .Settings directory that give the defaults for left-shift and right-shift on VAR identifier entries. Naturally, they would be STO and RCL by default, but people would be able to change them if they like.

Heck, you could throw in left-hold and right-hold, and the default decoration, and everything else!

It's not so simple. The key handler needs to check (for example, shift-var for RCL):
a) If it's the VARS menu or any other (custom or system) menu.
b) Assuming it's indeed VARS, the variable could be a directory, if it is it changes directory transparently (even within the editor!).
c) If the variable is not a dir, then do RCL but if the editor is open, don't put the result on the stack. In 'D' mode, close the command line and RCL the contents to the stack. In 'P' or 'A' mode, insert 'VAR' RCL in the command line.

So there's many cases to consider, a single << RCL >> in the settings directory wouldn't really do the trick.

[The Shadow]

newRPL STREAM behaves very differently from RPL STREAM. Which isn't bad in itself, but it does seem less flexible.

RPL STREAM puts the first two elements of the list on the stack, then runs the program. Then the next element, and runs the program; and so on until the list is done. The rest of the stack is still available - you can do PICK3 for example to use a constant elsewhere on the stack.

newRPL STREAM seems confined to the elements of the list; trying to access the rest of the stack returns 'Bad argument count' errors.

A more serious issue is that when I tried to get around that problem by using local variables instead, that also returned errors. The program used in STREAM doesn't seem to allow the use of local variables at all - an 'Exception: Data abort' is thrown and the program ends up on the stack with local variables replaced by 'INVALID_COMMAND'.

[Claudio L.]

(01-23-2017 07:19 PM)The Shadow Wrote:  newRPL STREAM behaves very differently from RPL STREAM. Which isn't bad in itself, but it does seem less flexible.

RPL STREAM puts the first two elements of the list on the stack, then runs the program. Then the next element, and runs the program; and so on until the list is done. The rest of the stack is still available - you can do PICK3 for example to use a constant elsewhere on the stack.

newRPL STREAM seems confined to the elements of the list; trying to access the rest of the stack returns 'Bad argument count' errors.

There is indeed a stack protection that prevents you from accessing the stack outside of the list you are processing.
Error handling seems broken, as it doesn't show the proper message. I will investigate.

(01-23-2017 07:19 PM)The Shadow Wrote:  A more serious issue is that when I tried to get around that problem by using local variables instead, that also returned errors. The program used in STREAM doesn't seem to allow the use of local variables at all - an 'Exception: Data abort' is thrown and the program ends up on the stack with local variables replaced by 'INVALID_COMMAND'.

I believe you hit a bug in the optimizer of the compiler. The problem happens because you declare a local variable with LSTO, and then the compiler "optimized away" the variable the next time you used it with direct GETLAM style opcodes (which are decompiled as "INVALID_COMMAND" as there's no user-visible text to decode these instructions, so that's normal). However, the optimizer is not supposed to go across << >> symbols, since this is code that will be stored in the stack to be executed separately when the local variable may or may not exist, hence it should be called by name, not optimized.
One more thing to investigate and fix. This was working fine, not sure at what point I broke it again...
An update will be coming in the next week or so with all these fixes. Thanks for testing and reporting!

[Claudio L.]

(01-23-2017 10:44 PM)Claudio L. Wrote:  An update will be coming in the next week or so with all these fixes. Thanks for testing and reporting!

FYI, both bugs were identified and fixed. In both cases I broke it unintentionally:
The compiler optimization when I made the compiler fully re-entrant, and the error handling in STREAM and all other list processing commands when I added conditional breakpoints.
It seems the main cause of bugs is myself fiddling with code that was already working and tested.

Keep testing! It helps a lot.

[The Shadow]

(01-23-2017 10:44 PM)Claudio L. Wrote:  There is indeed a stack protection that prevents you from accessing the stack outside of the list you are processing.

Pity, I actually prefer it the old way. But then, when I cut my teeth on RPL, I imbibed the idea that one was supposed to avoid local variables wherever possible. newRPL's philosophy is taking some adjustment.

Quote:The compiler optimization when I made the compiler fully re-entrant, and the error handling in STREAM and all other list processing commands when I added conditional breakpoints.

How do the breakpoint commands work exactly?

[Claudio L.]

(01-24-2017 06:17 AM)The Shadow Wrote:  Pity, I actually prefer it the old way. But then, when I cut my teeth on RPL, I imbibed the idea that one was supposed to avoid local variables wherever possible. newRPL's philosophy is taking some adjustment.

In general, I protected all list processing commands from doing "damage" outside of processing the list. But then this was before I had 8-levels of stack undo in place, perhaps I need to rethink this and remove the protection, since now you can go back to the stack with a single key stroke.

(01-24-2017 06:17 AM)The Shadow Wrote:  

Quote:The compiler optimization when I made the compiler fully re-entrant, and the error handling in STREAM and all other list processing commands when I added conditional breakpoints.

How do the breakpoint commands work exactly?

This is all new, will come out in the next update (although the framework was modified previously to incorporate these improvements), so you can't test it yet.
EDIT: I just realized this went out in the last release, you CAN test it!


There's quite a few improvements to the debug mechanism that allows:
a) Hardware-based HALT and AUTORESUME operations: For example, alarms can be triggered in the middle of your code (not yet implemented). If an alarm is triggered while you are running a program, the program is HALTed, the action for the alarm takes place (whether it is displaying a message or running a program), and then the program autoresumes like nothing happened. Timers also come to mind as a future implementation (same as alarms, really).
b) All normal debugging commands HALT, CONT, KILL are implemented in a compatible way. Also SST and SST[down arrow] do the same as usual.
c) Conditional breakpoints: To set a breakpoint you need to provide:

<< program to debug >>
Offset (an integer)
<< condition program >> (optional)

The command SETBKPOINT will "set" the breakpoint, CLRBKPOINT will remove it.
The arguments are as follows:
<< program to debug >> is any code or subroutine you want the breakpoint to be triggered on.
Offset is an index (1 to N) to provide a more specific location within the program. Consider the program as a list, when the Instruction Pointer is in front of, or within the object at index N, it will evaluate the condition to see if it needs to halt or not. Using an offset of 0 the breakpoint could trigger anywhere inside the given program.
The condition program is any arbitrary program that returns true/false (1 or 0) to the stack, but makes no other modifications to it. 1 means HALT, 0 means condition not met. This argument is optional, if it's not given then the breakpoint always triggers (it's the same as giving the condition program << 1 >>.

Then you run your program normally (no need to use DBUG or anything). When the IP reaches the specified location, the condition program will be executed. Because the condition program is running within the halted program, it has access to all local variables, including the counters inside a FOR loop, etc.

Once the breakpoint triggers, the program is HALTED the same as a HALT command. Unlike the static nature of HALT, you can now redefine (and/or move) the breakpoint while the program is halted, then keep debugging.

By the way, when a program is halted, you have access from the stack to all local variables:

If you do << 34 'X' LSTO HALT >>
Then X on the stack will recall 34. Trying to STO to X will overwrite the local copy, not the global variable. The variable will go out of scope on CONT or KILL.
I'm thinking there could be a LVARS menu that shows local variables when halted.
Also, there could be (should be?) a real interactive in-calc code debugger in the (not immediate) future.

[The Shadow]

Very nice! Are SST and SST(down) currently implemented, then?

[The Shadow]

Further questions:

Is it one breakpoint at a time globally, one breakpoint per program, or what?

If I forget to CLRBKPOINT, that breakpoint will remain on the program indefinitely?

[The Shadow]

I've been thinking some more about EVAL. It has always been a command that tried to wear way too many hats.

* It replaces variables.

* It simplifies expressions.

* It executes programs.

* It "executes" lists.

* It even makes Julienne French fries!

I get the compatibility argument. But I wonder if it's outweighed by the blessed ability to treat vectors, matrices, and lists in exactly the same way?

What if EVAL did only the first two things on the list above, and executing things was a new command? I notice there's a new command XEQSECO, which I assume is for executing secondary programs in some sense; what if there were a command XEQ which does for programs and lists what EVAL does now?

The only downside (other than compatibility) that I can see is that there'd be no obvious button to run a program on the stack. Really the only objection I have to EVAL is what it does to lists; maybe it could continue to run programs? Or maybe we map XEQ to where PRG is now and call it good.

P.S. Three totally unrelated things:

1. Shouldn't there be angle commands to 'label number as an angle of the current format, whatever that may be' and 'convert angle to current format'?

2. Is there any way to get a list of units that have been UDEFINE'd? Since they don't show up in directories, and there's no way to add them to the Units menu, I imagine it would be easy to lose track of them.

3. Is there any compelling reason not to use the left and right arrow keys as NXT and PREV? Or some shifted version, if it's felt important to keep the SWAP function on the right arrow? (I personally almost never use it.)

Oh, and I just noticed:

4. I wiped memory, but once again I'm getting the problem with the DISABLE key.

[Claudio L.]

(01-24-2017 05:50 PM)The Shadow Wrote:  I've been thinking some more about EVAL. It has always been a command that tried to wear way too many hats.

* It replaces variables.

* It simplifies expressions.

* It executes programs.

* It "executes" lists.

* It even makes Julienne French fries!

I get the compatibility argument. But I wonder if it's outweighed by the blessed ability to treat vectors, matrices, and lists in exactly the same way?

In newRPL EVAL is an overloadable operator. Each object can be defined to do whatever it wants on EVAL. If you define an object potatoes, it of course will do french fries.

(01-24-2017 05:50 PM)The Shadow Wrote:  What if EVAL did only the first two things on the list above, and executing things was a new command? I notice there's a new command XEQSECO, which I assume is for executing secondary programs in some sense; what if there were a command XEQ which does for programs and lists what EVAL does now?

The only downside (other than compatibility) that I can see is that there'd be no obvious button to run a program on the stack. Really the only objection I have to EVAL is what it does to lists; maybe it could continue to run programs? Or maybe we map XEQ to where PRG is now and call it good.

There's 3 overloadable operators in newRPL for this task: EVAL, EVAL1 and XEQ. From that point of view, it's not a command that does many things, but an operation defined differently by each object type.
XEQ is a short for Execute, and it's intended to get something done (right now run a program, everything else is just left in the stack untouched).
EVAL does evaluation, mainly anything that contains symbolics does a variable replacement (fully recursive), programs are also executed. The only exception is the list: I disagree with the current behavior of exploding the list, I think it should pass the EVAL to its elements, just like any other unary operator on a list. But it was kept there for compatibility, as I saw code using that to explode lists. I'm in favor to change it, maybe you should start a poll or something.
EVAL1 is the same as eval, but does only one step if possible (in other words, is not fully recursive, does only a single pass).

For example:
'X+1' 'X' STO
'X' EVAL --> 'X+1' in classic RPL
'X+1' EVAL --> Circular reference error in classic RPL, this is not consistent. Why does it try to evaluate 'X+1' ad infinitum, but 'X' just does a single step? In my mind it should be:
'X' EVAL --> Circular reference error (in all cases tries to evaluate recursively replacing everything).
'X+1' EVAL --> Circular reference error

Then EVAL1 comes to rescue:
'X' EVAL1 --> 'X+1'
'X+1' EVAL1 --> 'X+2'

Which allows you to use recursive formulae.

(01-24-2017 05:50 PM)The Shadow Wrote:  P.S. Three totally unrelated things:

1. Shouldn't there be angle commands to 'label number as an angle of the current format, whatever that may be' and 'convert angle to current format'?

They are both automatic operations, a number will be interpreted as an angle in the current format, so there's no need to "convert" from one another. For the same reason, an angle object will be automatically converted to a number in the current angle format before operating with a plain number.
EDIT: However, I already have this task in the bug tracker.

(01-24-2017 05:50 PM)The Shadow Wrote:  2. Is there any way to get a list of units that have been UDEFINE'd? Since they don't show up in directories, and there's no way to add them to the Units menu, I imagine it would be easy to lose track of them.

You can always add them to a custom menu, just use the unit object with a 1_[xxx] in the menu definition, and it will automatically behave the same as in the Units menu (even the 1_ will be hidden).
EDIT: I can probably add ULIST or something like that to do this, so ULIST TMENU would give you that special custom units menu.

(01-24-2017 05:50 PM)The Shadow Wrote:  3. Is there any compelling reason not to use the left and right arrow keys as NXT and PREV?
Or some shifted version, if it's felt important to keep the SWAP function on the right arrow? (I personally almost never use it.)

Yes, when you are in the editor, you still need NXT and PREV, but you need the cursors to move the cursor. All shifted versions are already used in the editor.

(01-24-2017 05:50 PM)The Shadow Wrote:  Oh, and I just noticed:

4. I wiped memory, but once again I'm getting the problem with the DISABLE key.

Sorry, can't reproduce it here. The label only switches a flag on and off, same as all other labels in that menu. I looked and everything looks fine, I don't know what else could it be.

[The Shadow]

(01-25-2017 08:22 PM)Claudio L. Wrote:  In newRPL EVAL is an overloadable operator. Each object can be defined to do whatever it wants on EVAL. If you define an object potatoes, it of course will do french fries.

But what if you say po-tay-to and I say po-tah-to?

Quote:The only exception is the list: I disagree with the current behavior of exploding the list, I think it should pass the EVAL to its elements, just like any other unary operator on a list. But it was kept there for compatibility, as I saw code using that to explode lists. I'm in favor to change it, maybe you should start a poll or something.

Yeah, I've used it that way myself. But I'd be all for changing it.

Quote:EDIT: I can probably add ULIST or something like that to do this, so ULIST TMENU would give you that special custom units menu.

That would be the ideal solution.

Quote: Yes, when you are in the editor, you still need NXT and PREV, but you need the cursors to move the cursor. All shifted versions are already used in the editor.

Sigh. Of course you're right, sorry about that.

[Claudio L.]

(01-24-2017 05:09 PM)The Shadow Wrote:  Further questions:

Is it one breakpoint at a time globally, one breakpoint per program, or what?

If I forget to CLRBKPOINT, that breakpoint will remain on the program indefinitely?

I forgot to clarify this: I designed it with 3 breakpoints (because they take permanent space, so we can't have that many). Of those 3, one is used for stepping between code (SST) which leaves 2 breakpoints for the user to manage. For now I included commands to set one of those SETBKPOINT/CLRBKPOINT. If in my daily use I find this feature useful, I'll add commands to set a second one, otherwise I'll cut the number to 2 and save some RAM. If you ever feel you *need* to have 2 let me know and I'll just add the commands SETBKPOINT2/CLRBKPOINT2.

Also, enabling a breakpoint slows down execution so we don't want to have many breakpoints unless absolutely needed.

[The Shadow]

I honestly can't imagine needing more than one breakpoint, I generally only work on one program at a time.

[Claudio L.]

Almost-February update!

Fixed bugs:
* Bad error handling on all list operations
* Compiler optimization error preventing the use of local variables in list processing programs.

New features:
* Interactive stack!

Keys:
Navigation + clipboard (same as in editor):
RS+Cursors usual navigation
LS-HOLD+Left = Copy
LS-HOLD+Right = Paste
LS-HOLD+Down = Cut

Stack manipulation:
Left cursor = ROLL
Right Cursor = ROLLD
Enter = PICK
+/- = Select single element
Space = Start multi selection/End multi selection/Clear selection

And that's it. As simple and intuitive as possible. Check it out.

When a block of objects is defined:
Right Cursor = MOVE to current location
Left cursor = COPY to current location
(this I believe should be reversed, as Right is also used for PASTE, it feels more consistent with COPY than MOVE)

But test and comments are welcome!

[Claudio L.]

Also fixed on this version (updated 02/07/17):
* EVAL on lists changed behavior: now it EVAL's every element instead of exploding the list. This is necessary for the next item.
* Symbolic operations with lists and matrices was fixed:

While you can't directly type a vector or matrix or list inside a symbolic (same as 50g), any variable in a formula may contain a matrix or a list and operations will be carried through as expected.
On the 50g, using lists in formulas was limited because of the '+' vs ADD, and the behavior of EVAL. In newRPL you can use lists to do simultaneous evaluation of multiple points in a function for example. If more than one variable has lists, the lists must have compatible dimensions to operate element-by-element.

* Numeric auto-simplification issues were fixed and improved.
* ->Q no longer returns fractions in the form 'N/1'
* Symbolic numbers stay symbolic after EVAL. This is a change in behavior necessary to prevent the loss of symbolic information during sequences of operations like inverting a matrix. Without this fix, for example a symbolic pivot '1/2' was being inverted to 2 (not '2'), and then used in a division in row-operations. Then an element of 1 would be divided by 2 instead of '2', returning 0.5 instead of the expected '1/2'.

* Command ULIST was added to list custom units per post in this thread.
* When a block of objects is defined in the interactive stack:
Right Cursor = COPY to current location
Left cursor = MOVE to current location
It was reversed from my previous post for consistency as PASTE feels more like COPY.
* Fixed symbolic numbers vanishing during ->NUM.
* Adds a bitmap cache to the stack display, making it faster (needed to speedup the interactive stack)
* The TYPE command was implemented (type numbers are different from 50g). Also added TYPEE (extended), which provides more information about the object (depending on type). For example for numeric types, TYPEE returns XX.MN, where XX=object type (=10 for numbers), M=digit that changes with the base the integer is in (1=decimal), N=digit that has certain flags: 1=APPROX. NUMBER, 2=EXACT INTEGER, 3=APPROX. INTEGER
So an exact integer in decimal base will return 10.12,while TYPE would return only 10.
Some objects don't have this extended information yet, will have it soon (for instance, an angle should tell you if it's in DEG/GRAD/RAD/DMS, etc., a matrix should say if it contains any complex numbers or symbolic items).

[The Shadow]

It's... It's like Christmas and my birthday both came early! Great update, Claudio!

[Claudio L.]

(01-31-2017 06:09 PM)Claudio L. Wrote:  Stack manipulation:
Left cursor = ROLL
Right Cursor = ROLLD
Enter = PICK
+/- = Select single element
Space = Start multi selection/End multi selection/Clear selection

Perhaps a clarification would help understand better why ROLL/ROLLD are pretty much the only commands that were implemented for the interactive stack.
Turns out that LEFT moves the element at the cursor to level 1, while RIGHT takes the element in level 1 and brings it back to where the cursor is.
So for instance to rearrange elements anywhere in the stack you point to the first one, press LEFT, then move to the new position and press RIGHT.

To swap 2 non-consecutive elements: go to the first one, press SPACE, then go to the second one, press LEFT, then UP (or DOWN, depending on whether your previous element is above or below) and RIGHT.

There could be other commands needed, one that comes to mind could be to reverse the stack (perhaps the 1/x key?) as follows:
* When no selection is made, reverse between level 1 and the cursor
* When selection is made reverse the order within the selected block

EDIT: I don't think I mentioned that the Back key drops the item at the cursor or the selected block.

Other suggestions welcome.

[Helix]

I miss the ->LIST command.