Threaded Mode | Linear Mode

Vtile · (This post was last modified: 12-30-2016 07:03 PM by Vtile.)

Nice..

How would one make a program in newRPL that would use +-key as in original 50g with the lists. I know you swapped the ADD and + commands functionality with the newRPL. I just like so much the way it works with original as lists are "data collector type" so compiling a list is so easy with the plus key (unshifted)...

Something like: << -> X Y << X TYPE 5 == Y TYPE 5 == OR IF THEN ADD ELSE + END >> >> ??
Then just +..P ANSKEY ??

I'm still just following and not participating, I admit. Sad

compsystems · 12-30-2016, 07:12 PM

I prefer that [+] [-] operators work in parallel in a list.

To have the "old" function a solution, could be
[/ ->] (hold right shift) & [+] or [-]

NEW-RPL should not be 100% compatible with the old-RPL, (this means staying in the past)

Vtile · (This post was last modified: 12-30-2016 08:16 PM by Vtile.)

(12-30-2016 07:12 PM)compsystems Wrote: I prefer that [+] [-] operators work in parallel in a list.

To have the "old" function a solution, could be
[/ ->] (hold right shift) & [+] or [-]

NEW-RPL should not be 100% compatible with the old-RPL, (this means staying in the past)

I didn't mean that it should stay the same. My question were more just a follow up on the new ASNKEY and how it works. Also I'm not fully sure how the programming goes so it would also answer that partly.. This or that I should reload the emu or even better flash my spare 50g unit to newRPL and try it out. Smile

Here is the last post from Claudio:

(12-30-2016 05:24 PM)Claudio L. Wrote: List of new features and changes:

* Added support for HALT, CONT, KILL, and a new feature: conditional breakpoints.
* Added support for custom key definitions (ASN renamed to ASNKEY, also implemented DELKEY, RCLKEYS, STOKEYS).

For those who want to try, here's how it works:

ASNKEY:
Action_Object KeyName Context

Action_Object is the program to execute when you press the key. It not only accepts programs, but any object. Most objects are EVAL'ed, others receive special treatment:
* If a list is given, the first object is EVAL'ed or inserted in the editor instead of always EVALed. This allows to include commands instead of programs as in { SIN }. When in D mode, SIN will be EVALed, in A mode SIN() will be typed, and in P mode SIN will be inserted. Secondaries :: ; inside a list are executed transparently when in the editor (normal behavior of a program is to close the editor, compile whatever was in the editor, then run the program, this runs the program without ever closing the editor). IDENTS behave much like they do in menu definitions (directories are changed without closing the editor, etc.). Also a string inside a list is treated as text to type (like a keyboard macro), rather than as a string object.

KeyName is a string (forget about those shift plane numbers!) with the format:

"KK[.SS[.EE]]"

Where KK is the name of the key (A thru Z, 0 to 9, +,-,*,/, DT for dot, SP for space, EN for enter, UP/DN/LF/RT for the cursors and BK for backspace).
.SS is the optional shift, and can be L, LH , R, RH, A, AH, OH for (Left, Left-hold, etc.)
.EE is the event type, and can be P for press (default), D for key down, U for key up, L for long press, R for repeat (only works on some keys), and T for long repeat.

Context is a number that indicates whether we are in the stack, the editor, etc. For now let's use 0 which means the key definition will act always.

Some key examples:

"Hello" "4..L" 0 ASNKEY --> Will assign the string "Hello" to the key 4, unshifted, when you do a long press.
"World" "4..T" 0 ASNKEY --> Will assign the string to the key 4, unshifted, long repeat.

Now press and hold 4 and you should see on the stack:
"Hello"
"World"
"World"
...
"World"

to delete this assignment just use DELKEY with the key name:

"4..T" DELKEY
"4..L" DELKEY

Key definitions don't overwrite each other, they add the new definition with higher priority than any existing one.
So you can define:

"Hello" "4..L" 0 ASNKEY
"World" "4..L" 0 ASNKEY

Now long-pressing 4 will show "World". Deleting this key:
"4..L" DELKEY will only delete the latest definition, and now long-pressing will show "Hello", which is still defined.
You need to delete the other definition as well with a second
"4..L" DELKEY

One last example (a prank?):
Make the 4 key work like a 7:
{ "7" } "4" 0 ASNKEY
{ "7" } "4.A" 0 ASNKEY
{ "7" } "4.AH" 0 ASNKEY

The first assignment takes care of the usual press, the second one changes it when in alpha mode, the third one changes the definition when in Alpha-Hold mode.

By the way, the System/Keys menu has a "DISABLE" key that allows you to enable/disable the custom keys, in case you make typing impossible (like the example above). This is flag -4, nothing special.

Have fun redefining the keyboard!

Claudio L. · 12-31-2016, 03:38 AM

(12-30-2016 08:15 PM)Vtile Wrote: My question were more just a follow up on the new ASNKEY and how it works. Also I'm not fully sure how the programming goes so it would also answer that partly.. This or that I should reload the emu or even better flash my spare 50g unit to newRPL and try it out.

Your idea is on the right track. However, the TYPE command is still not implemented.

As a workaround (for the time being), you could assign ADD to a long press on the + key:

{ ADD } "+..L" 0 ASNKEY

If you use ADD more than the addition, then assign + to a long press and ADD to the normal key with:

{ ADD } "+" 0 ASNKEY
{ + } "+..L" 0 ASNKEY

But of course, with this solution you'd have to long press every time you need to add a couple of numbers (since 1 2 ADD --> { 1 2 } and not 3 as in the 50g).

The Shadow · 01-19-2017, 07:22 AM

Is there any way to redefine the VAR menu so it doesn't do STO on left-shift? I have lost so many long programs by accident that way! Someone wrote me a short SysRPL program a while back to replace it with VISITB instead, which I truly love.

Nigel (UK) · 01-19-2017, 08:32 AM

(01-19-2017 07:22 AM)The Shadow Wrote: Is there any way to redefine the VAR menu so it doesn't do STO on left-shift? I have lost so many long programs by accident that way! Someone wrote me a short SysRPL program a while back to replace it with VISITB instead, which I truly love.

Following on from this, an UNDO feature for STO would be nice - maybe the previous contents of the variable could go to LAST_STO, or something like that?

Nigel (UK)

Claudio L. · 01-20-2017, 03:57 AM

(01-19-2017 07:22 AM)The Shadow Wrote: Is there any way to redefine the VAR menu so it doesn't do STO on left-shift? I have lost so many long programs by accident that way! Someone wrote me a short SysRPL program a while back to replace it with VISITB instead, which I truly love.

Doing STO on left shift is a long tradition that works quite well in practice. newRPL gives you the next best thing: LOCKVAR and UNLOCKVAR commands.
These 2 commands make variables read-only so they cannot be deleted accidentally. It's especially good for programs you don't want to accidentally overwrite, not only from the VAR menu, but perhaps a rogue program could write a variable with the same name as your program.
It doesn't work on directories, though, only individual variables.

The Shadow · 01-20-2017, 04:04 AM

(01-20-2017 03:57 AM)Claudio L. Wrote: Doing STO on left shift is a long tradition that works quite well in practice. newRPL gives you the next best thing: LOCKVAR and UNLOCKVAR commands.

Quote: It doesn't work on directories, though, only individual variables.

Thanks for the reply. Do those commands accept lists as input?

I suppose I can eventually create my own version of VAR using TMENU. Being able to VISIT a program with a simple left-shift is so nice.

Claudio L. · 01-20-2017, 04:04 AM

(01-19-2017 08:32 AM)Nigel (UK) Wrote: Following on from this, an UNDO feature for STO would be nice - maybe the previous contents of the variable could go to LAST_STO, or something like that?

Nigel (UK)

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.

Claudio L. · 01-20-2017, 04:10 AM

(01-20-2017 04:04 AM)The Shadow Wrote: Thanks for the reply. Do those commands accept lists as input?

Yes, they do.

The Shadow · 01-20-2017, 04:36 AM

(01-20-2017 04:10 AM)Claudio L. Wrote:
(01-20-2017 04:04 AM)The Shadow Wrote: Thanks for the reply. Do those commands accept lists as input?

Yes, they do.

Ah good. And here's a thought - is there any way for a program to detect if a variable is locked? (Other than trying to STO into it!)

Claudio L. · (This post was last modified: 01-20-2017 07:43 PM by Claudio L..)

(01-20-2017 04:36 AM)The Shadow Wrote:
(01-20-2017 04:10 AM)Claudio L. Wrote: Yes, they do.

Ah good. And here's a thought - is there any way for a program to detect if a variable is locked? (Other than trying to STO into it!)

Not at the moment. It's not as common use case as you might think. Normally, if you need to know that is because you have something to store there, therefore you can trap the STO errors inside an IFERR, and perhaps rename the variable if it fails (no different from the case when you want to know if a variable of that name already exists, you do RCL and trap the error).

The Shadow · 01-21-2017, 05:02 AM

(01-20-2017 07:43 PM)Claudio L. Wrote:
(01-20-2017 04:36 AM)The Shadow Wrote: Ah good. And here's a thought - is there any way for a program to detect if a variable is locked? (Other than trying to STO into it!)

Not at the moment. It's not as common use case as you might think. Normally, if you need to know that is because you have something to store there, therefore you can trap the STO errors inside an IFERR, and perhaps rename the variable if it fails (no different from the case when you want to know if a variable of that name already exists, you do RCL and trap the error).

I get that, but I was thinking along the lines of, "Did I lock the files in this directory yet or not?" I suppose I could just RCL one and try to STO it back in. Or just lock them all again, won't hurt anything.

On another topic, it's trivially easy to write programs to decompile everything in a directory to strings and to recompile them for updates. But not so easy in RPL to do it for all directories at once. Would you consider commands to do this? I have to imagine it would be easier in C.

And on yet another, I make heavy use of symbolic vectors and matrices, and I've noticed some oddities. Only on the Windows version thus far, though, as my new 50g hasn't arrived yet. Is it up to date with the calculator version?

Claudio L. · 01-22-2017, 01:38 AM

(01-21-2017 05:02 AM)The Shadow Wrote: I get that, but I was thinking along the lines of, "Did I lock the files in this directory yet or not?" I suppose I could just RCL one and try to STO it back in. Or just lock them all again, won't hurt anything.

I see, eventually there will be a filer (var browser?) where you will be able to see if a variable is read-only or not.

(01-21-2017 05:02 AM)The Shadow Wrote: On another topic, it's trivially easy to write programs to decompile everything in a directory to strings and to recompile them for updates. But not so easy in RPL to do it for all directories at once. Would you consider commands to do this? I have to imagine it would be easier in C.

Updates will no longer require to recompile anything. Starting with the first official release of 0.8Alpha a month ago, things will stay where they are.

(01-21-2017 05:02 AM)The Shadow Wrote: And on yet another, I make heavy use of symbolic vectors and matrices, and I've noticed some oddities. Only on the Windows version thus far, though, as my new 50g hasn't arrived yet. Is it up to date with the calculator version?

The demo is identical to the calculator, any bugs will happen on the 50g too, so please describe what you call oddities. Bear in mind many of the commands will show up in autocomplete but will issue an "Invalid opcode" error because they are not implemented. Anything else might be a bug, either in symbolics or in the matrix lib.

The Shadow · (This post was last modified: 01-22-2017 04:08 AM by The Shadow.)

(01-22-2017 01:38 AM)Claudio L. Wrote: Updates will no longer require to recompile anything. Starting with the first official release of 0.8Alpha a month ago, things will stay where they are.

Ah, good to know.

Quote:The demo is identical to the calculator, any bugs will happen on the 50g too, so please describe what you call oddities. Bear in mind many of the commands will show up in autocomplete but will issue an "Invalid opcode" error because they are not implemented. Anything else might be a bug, either in symbolics or in the matrix lib.

Okay. (I've got my calculator now, btw, and newRPL installed without incident.) I started with the vector [1 2 3], and then divided by '3'. I expected to get:

[ '1/3' '2/3' '3/3' ]

What I got instead was:

'[ 1 2 3 ]/3'

So then I tried [ '1' '2' '3' ] and divided by '3'. This time I got an error, "/ Error: Not allowed in symbolics".

Finally I tried [ '1' '2' '3' ] and divided by 3. (Well, "3" not "3.") This time I got the decimal versions of the three fractions in the vector. ie, [0.333... 0.666... 0.999...] That last one in particular seems odd - why not just 1?

I would expect the symbolics inside the vector to work just like symbolics on the stack or in a list, but they don't.

(Incidentally, is there a command to change an integer into the symbolic version of that integer? ->Q changes 2 to '2/1' rather than '2'. Not sure if that's intended behavior - RPL changes real "2." to integer "2".)

A somewhat larger issue: Currently, if you do EVAL or EVAL1 on '2/1' or '2', you get 2. I wonder if that's a good idea? ->NUM should do that, certainly, but I don't see why EVAL should. I'd expect it to be '2' in both cases.

(By the way, let me thank you from the bottom of my heart for letting EVAL and EVAL1 evaluate the elements of matrices and lists, respectively. The number of times I have typed AXL <<EVAL>> MAP AXL on the regular 50g is ridiculous.)

The Shadow · (This post was last modified: 01-22-2017 05:09 AM by The Shadow.)

Okay, playing around tonight I've found some serious bugs:

If you put an integer in quotes, ie '2', and then do ->NUM, you get an invisible object on the stack. You get an error "Not allowed in symbolics" if you try to make it interact with other numbers, so I'm not sure what it is. It's definitely there, though, as it increments DEPTH.

DROP doesn't return an error if there's nothing on the stack. EDIT: To be more precise, if you enter DROP as a command it works properly; but if you press backspace in order to DROP it doesn't.

EDIT: Checking these on the Windows version confirms these bugs.

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

(01-20-2017 04:04 AM)Claudio L. Wrote:
(01-19-2017 08:32 AM)Nigel (UK) Wrote: Following on from this, an UNDO feature for STO would be nice - maybe the previous contents of the variable could go to LAST_STO, or something like that?

Nigel (UK)

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)

The Shadow · 01-22-2017, 02:59 PM

Something strange is going on with the DISABLE button in the Keys menu.

When I first installed newRPL, it showed up as INVALID and gave errors when you put anything on the stack while it was visible.

I figured my download was corrupted and reinstalled. It worked this time, for a while. But now it's doing it again:

>> Error:
Empty data stack (internal)

Then when you try to put anything on the stack, you get the same error. Though this time, the button isn't showing up at all, rather than saying INVALID.

A couple times I've seen a list spontaneously pop up that appears to be the button's TMENU specification.

Claudio L. · 01-22-2017, 08:30 PM

(01-22-2017 04:01 AM)The Shadow Wrote:
(01-22-2017 01:38 AM)Claudio L. Wrote: Updates will no longer require to recompile anything. Starting with the first official release of 0.8Alpha a month ago, things will stay where they are.

Ah, good to know.

Quote:The demo is identical to the calculator, any bugs will happen on the 50g too, so please describe what you call oddities. Bear in mind many of the commands will show up in autocomplete but will issue an "Invalid opcode" error because they are not implemented. Anything else might be a bug, either in symbolics or in the matrix lib.

Okay. (I've got my calculator now, btw, and newRPL installed without incident.) I started with the vector [1 2 3], and then divided by '3'. I expected to get:

[ '1/3' '2/3' '3/3' ]

What I got instead was:

'[ 1 2 3 ]/3'

So then I tried [ '1' '2' '3' ] and divided by '3'. This time I got an error, "/ Error: Not allowed in symbolics".

Finally I tried [ '1' '2' '3' ] and divided by 3. (Well, "3" not "3.") This time I got the decimal versions of the three fractions in the vector. ie, [0.333... 0.666... 0.999...] That last one in particular seems odd - why not just 1?

I would expect the symbolics inside the vector to work just like symbolics on the stack or in a list, but they don't.

It seems you caught a glitch in my definition of the '/' operation for vectors. Since division doesn't exist in matrix/vector world, it was implemented as "multiply by the inverse", so if you divide a matrix by another one it inverts the right argument then attempts to multiply. I obviously need to work on some special cases:

[ 1 2 3 ] 3 / --> First it does 3 INV --> 0.333333333.... then multiplies that, hence you get the 0.9999999999.... instead of one. For the case matrix / number this doesn't work well and needs to be fixed. It would work much better for scalars when you use the actual '/' operator element-by-element.

[ '1' '2' '3' ] 3 / --> Similarly, 3 INV returns an approximated value, then when multiplied by other numbers it spreads the approximation virally, and you end up with all approximated numeric answers (this is by design). Same fix as previous issue.

[ 1 2 3 ] '1/3' * --> Not allowed in symbolics. Because the interaction between them wasn't quite ready yet, you can't have vectors and lists inside a symbolic: '{ 1 2 }' will fail the same way. I think it's trying to create a symbolic '[ 1 2 3 ]*(1/3)' which is not permitted. I will have to work on that so it does the element-by-element multiplication, then of course I have to enable it.
It was giving me problems with lists, so I disabled it. The idea is to allow multiple inputs and multiple outputs:

{ 2 4 6 } 'X' STO
'X^2/2' ->NUM
should produce { 4 8 18 } as a result. This isn't working well yet.

(01-22-2017 04:01 AM)The Shadow Wrote: (Incidentally, is there a command to change an integer into the symbolic version of that integer? ->Q changes 2 to '2/1' rather than '2'. Not sure if that's intended behavior - RPL changes real "2." to integer "2".)

I need to fix ->Q, denominator of 1 is supposed to be removed.

(01-22-2017 04:01 AM)The Shadow Wrote: A somewhat larger issue: Currently, if you do EVAL or EVAL1 on '2/1' or '2', you get 2. I wonder if that's a good idea? ->NUM should do that, certainly, but I don't see why EVAL should. I'd expect it to be '2' in both cases.

There's no way to 'convert' an object into symbolic, other than operate on it with a symbolic object. All symbolics are passed through an autosimplify step that removes the symbolic ticks if the result is an exact number. If you have '1/3' EVAL it won't remove the quotes and the result will remain '1/3' because it wouldn't have an exact result.
It shouldn't cause any problems, if you find a use case where you need to keep an integer number symbolic let me know, I might have to add such a command.

(01-22-2017 04:01 AM)The Shadow Wrote: (By the way, let me thank you from the bottom of my heart for letting EVAL and EVAL1 evaluate the elements of matrices and lists, respectively. The number of times I have typed AXL <<EVAL>> MAP AXL on the regular 50g is ridiculous.)

It seemed natural to extend the element-by-element operation of EVAL1. Notice that EVAL on lists explodes the list, so you still have to do << EVAL >> MAP, but EVAL1 does it element-by-element. This was done for compatibility, but I'm open to a change.

Claudio L. · 01-22-2017, 08:37 PM

(01-22-2017 02:59 PM)The Shadow Wrote: Something strange is going on with the DISABLE button in the Keys menu.

When I first installed newRPL, it showed up as INVALID and gave errors when you put anything on the stack while it was visible.

I figured my download was corrupted and reinstalled. It worked this time, for a while. But now it's doing it again:

>> Error:
Empty data stack (internal)

Then when you try to put anything on the stack, you get the same error. Though this time, the button isn't showing up at all, rather than saying INVALID.

A couple times I've seen a list spontaneously pop up that appears to be the button's TMENU specification.

I'll try to reproduce it, but it's working well here. I wonder if it is due to some data corruption due to you playing with "unfinished" code. Try a full memory wipe and see if it works, perhaps some of your symbolics experiments is the one to blame. If you can find a sequence that could reproduce the problem from a fresh clean memory (don't worry, you can do that on the PC) it would make it much easier for me to hunt the bug.