newRPL: Alpha demo 0.9 released [UPDATED 2017-10-25]

[Claudio L.]

Quick links section (this will remain on top, see below for updates):

Here are the links to the hpgcc3.org ROMS for the 50g, the 39gs /39g+ and the 40gs

Also, please head to the newRPL Official Wiki for installation instructions and general useful information.

**UPDATE 2017-10-25 **
* Fixed bug 0+tiny number = 0
* Fixed SIZE returns size of string in bytes
* Fixed CRDIR overwrites directories
* Fixed local var names remain unquoted
* Fixed operators regression on lists
* Fixed FLOOR of -1<x<0 = 1
* New commands:
BASIS, CHOLESKY, CON,COND,CROSS, CSWP, DET, DOT
HADAMARD, HILBERT, IBASIS, IDN,
IMAGE,KER,PMINI,PROOT,RANK,LU
RANM, RCI, RCIJ, RDM, REF, RREF, RSWP

**UPDATE 2017-09-15 **
Fixed menu display glitch.
Fixed local variables optimization problem when LSTO is used inside a WHILE loop.
New features:
* Added reverse argument logic and improved list support to STO+, STO-,STO*,STO+, SINV, SCONJ.
* Added SADD command (STO+ADD).
* Added RHEAD, RTAIL commands.
* Added customizable user font support to the UI.


**UPDATE 2017-08-24 **
Important update that fixes a regression in LN of small numbers. Immediate update is recommended.

**UPDATE 2017-08-11 **
Roms for all 3 targets were updated to fix an important bug that caused erratic behavior between the debugging commands (SST, HALT, etc), the new HIDELOCALS command and the compiler optimizations on local variables.
Within a few days I will update the PC demo to 0.9a with these fixes. Stay tuned.

**** ORIGINAL POST BELOW ******

The next alpha demo (for PC) was released on the sourceforge project page.

The most notable addition to the demo is the ability to copy/cut/paste items from the calculator stack to the PC clipboard. Objects are copied in binary and decompiled form, so pasting into other applications will simply work as text.
Pasting text from other applications works as expected, allowing the use of an external editor to write RPL code, then copy/paste the text and compile on the simulator.
Also, it allows saving/loading to a file, in a format compatible with SDSTO/SDRCL, so objects can be exchanged between the demo and a real calculator using the SD card.

Also ROMs with the same version as the demo are released for all 3 targets (50g, 40,39 series). They can be downloaded from Sourceforge as well as the usual location. Sourceforge contains only the "official" releases, while the hpgcc3.org location contains the latest development builds that get updated more often, for now they are all in sync.
Here are the links to the hpgcc3.org ROMS for the 50g, the 39gs /39g+ and the 40gs

Regarding the newRPL core, many, many bugfixes and stability improvements, in addition to implementing the following new commands:

POS/POSREV
NPOS/NPOSREV
SREPL
SPUSH
SPOP
SDROP
BLAMEERR
RND
TRNC
LNP1
EXPM
RENAME
TVARS
TVARSE
STOF
RCLF
SETNFMT
GETNFMT
GETLOCALE
SIZE
SUB
->NFC
OBJ->
PUT/PUTI
GET/GETI
IFT
IFTE
HIDELOCALS
UNHIDELOCALS

[pier4r]

Neat! Importing/exporting objects as text is a huge bonus for my workflow. Maybe now I will be able to handle the processing list challenge (and not only) with userRPL and the list of David, on one hp50g, and newRPL on the other hp 50g (bought exactly for newRPL).

Still I lack time (new flat, bought things from Ikea, I need to build everything and I do not have much time), but I hope I can tinker with the new version soon. Also to contribute more on the wiki.

edit: Hmm, the new windows version does not run anymore on windows XP (I use the pc for the hp50g development). It means that I will need even more time until I setup my new pc together with my homelab (Bought in May 2017, never much used until now)

[The Shadow]

Nice!! The new versions of POS are very yummy! And the addition of SIZE, SUB, and OBJ-> means I can finally get down to some serious math programming!

Most of the additions are obvious, but I'm puzzled by SPUSH, SPOP, and SDROP. Can't find them in any menus as yet, either.

I have an inkling of what BLAMEERR does, but I'm curious as to the syntax. Also, no help.

Any chance of having RND do the 'nint' function instead of always rounding 0.5 up? Or perhaps a flag to cause it to work that way?

HIDELOCALS and UNHIDELOCALS seem clear enough, I just can't figure out why one would want to?

[Claudio L.]

(08-09-2017 03:57 PM)The Shadow Wrote:  Most of the additions are obvious, but I'm puzzled by SPUSH, SPOP, and SDROP. Can't find them in any menus as yet, either.

They are stack snapshot management commands (not on menus yet):
SPUSH: Takes a new snapshot of the current stack. You'll be able to use left-cursor to go back to this state after your code ends. While the UNDO feature does this automatically, but you might want to create other intermediate snapshots, perhaps for debugging an intermediate step.
SPOP: Revert the current stack to the last snapshot taken.
SDROP: Delete the last snapshot taken (without touching the current stack).

Why these commands? They help create routines that leave the stack on a predictable state on error, by trapping the error and restoring the stack before returning.
I added them in preparation for higher level commands to be written in RPL. But I want them to leave the stack untouched on error, so I will need this.

(08-09-2017 03:57 PM)The Shadow Wrote:  I have an inkling of what BLAMEERR does, but I'm curious as to the syntax. Also, no help.

Along the same lines, for proper error management on an RPL program sometimes you need to throw an error, blaming certain command for it.
It works like this:
"IDIDTHAT" "But wasn't my fault" BLAMEERR

(08-09-2017 03:57 PM)The Shadow Wrote:  Any chance of having RND do the 'nint' function instead of always rounding 0.5 up? Or perhaps a flag to cause it to work that way?

I can look into that. For now the decimal library only supports one rounding mode but I can add more and control it with a flag.

(08-09-2017 03:57 PM)The Shadow Wrote:  HIDELOCALS and UNHIDELOCALS seem clear enough, I just can't figure out why one would want to?

In newRPL, local variables are visible as globals to any subroutine:
For example:
<< 5 'X' STO >> 'MYROUTINE' STO
then if you run
<< 4 'X' LSTO MYROUTINE X >>
the result would be 5, as X would be overwritten by MYROUTINE. This is on purpose and useful to encapsulate routines that modify global variables.
If this is not what you want, then use the new commands:
<< 4 'X' LSTO HIDELOCALS MYROUTINE UNHIDELOCALS X >>

Now because MYROUTINE can't see any locals created by any caller programs, it will create the global X variable with a 5, and the main program will result in a 4, since the last X refers to the local one, despite now having a global X=5.

[The Shadow]

(08-09-2017 08:35 PM)Claudio L. Wrote:  They are stack snapshot management commands (not on menus yet)

LOL!! I assumed the 'S' was for String, as in SREPL. So I put a string on the stack and tried SPUSH. Nothing happens. SPOP. Nothing happens. SDROP. Nothing happens.

Ironically, by the time I did the third command, nothing really had happened!

I assume that you can only have 8 levels of SPUSH'd stacks? That it in fact uses the same storage as the UNDO feature? Are those stacks stored anywhere the user can get at (other than using SPUSH and SPOP, I mean!)

I can see lots of uses for these already!

Quote:I added them in preparation for higher level commands to be written in RPL. But I want them to leave the stack untouched on error, so I will need this.

What commands do you have in mind?

Quote:If this is not what you want, then use the new commands:
<< 4 'X' LSTO HIDELOCALS MYROUTINE UNHIDELOCALS X >>

Now because MYROUTINE can't see any locals created by any caller programs, it will create the global X variable with a 5, and the main program will result in a 4, since the last X refers to the local one, despite now having a global X=5.

I see. For some reason I assumed they took arguments, like HIDEVARS and UNHIDEVARS. This makes more sense.

[Claudio L.]

(08-10-2017 12:45 AM)The Shadow Wrote:  I assume that you can only have 8 levels of SPUSH'd stacks? That it in fact uses the same storage as the UNDO feature? Are those stacks stored anywhere the user can get at (other than using SPUSH and SPOP, I mean!)

I can see lots of uses for these already!

They are in fact unlimited up to available memory. The 8 limit is the stack front-end purging older snapshots when there's more than 8, but inside your own program you can create as many as needed. The idea is your program should destroy them before returning, so only the actual user interaction with the stack remains in the UNDO list (unless of course you do this on purpose for whatever reason). The UNDO feature in the left cursor does nothing but revert the stack to one of the previous snapshots (without purging it, so you can REDO), and every time you press a menu or run a program it does SPUSH internally to create one, and checks if there's more than 8 purges the oldest one.
Stack snapshots prevent objects from being garbage collected, so it's not a good idea to abuse this by creating many snapshots.

I'm thinking the internal API could be exposed further, with commands like:

n SPICK --> Overwrite the stack with the contents of snapshot 'n'. SPOP is therefore << 1 SPICK SDROP >>
n level SPICKN --> Copy the object from snapshot 'n', level 'level' into the current stack level 1
n SDEPTH --> Get the depth of a snapshot 'n'
SCOUNT --> Get total number of snapshots
n SPURGE --> Destroy the snapshot 'n'

(08-10-2017 12:45 AM)The Shadow Wrote:  What commands do you have in mind?

I was looking into porting David's new list functions library as the first newRPL external library written in RPL, but it's just an idea in the planning stages for now. First I need to implement user installable libraries.

(08-10-2017 12:45 AM)The Shadow Wrote:  I see. For some reason I assumed they took arguments, like HIDEVARS and UNHIDEVARS. This makes more sense.

They affect all locals up to the point where HIDELOCALS is included (hence no arguments needed). Any local defined after HIDELOCALS will still be visible. It's most needed when you are preparing to execute user code, like evaluating a user supplied equation from within your program. You don't want that equation to accidentally pick the value of one of your local variables, so you need to hide them, call the user code, then un-hide them.

[smartin]

(08-09-2017 03:43 AM)Claudio L. Wrote:  The next alpha demo (for PC) was released on the sourceforge project page.

Regarding the newRPL core, many, many bugfixes and stability improvements, in addition to implementing the following new commands:

POS/POSREV
NPOS/NPOSREV
SREPL
SPUSH
SPOP
SDROP
BLAMEERR
RND
TRNC
LNP1
EXPM
RENAME
TVARS
TVARSE
STOF
RCLF
SETNFMT
GETNFMT
GETLOCALE
SIZE
SUB
->NFC
OBJ->
PUT/PUTI
GET/GETI
IFT
IFTE
HIDELOCALS
UNHIDELOCALS

Thanks Claudio! Lots of fun new commands.

FYI:
The 50g ROM reports a VERSION of 0.8ALPHA-Build 849

[Claudio L.]

(08-11-2017 01:20 AM)smartin Wrote:  FYI:
The 50g ROM reports a VERSION of 0.8ALPHA-Build 849

I knew I was forgetting something when I published. I promise to update the numbers next time.

[Vtile]

Would it be good to rename the stack commands differently. As they aren't used as frequently in simple programs as the string commands might be.

SPUSH -> STPUSH or STKPUSH ???

Just a simple quality of life improvement?

[smartin]

(08-09-2017 03:43 AM)Claudio L. Wrote:  **UPDATE**
Roms for all 3 targets were updated to fix an important bug that caused erratic behavior between the debugging commands (SST, HALT, etc), the new HIDELOCALS command and the compiler optimizations on local variables.
Within a few days I will update the PC demo to 0.9a with these fixes. Stay tuned.

**** ORIGINAL POST BELOW ******

The next alpha demo (for PC) was released on the sourceforge project page.

The most notable addition to the demo is the ability to copy/cut/paste items from the calculator stack to the PC clipboard. Objects are copied in binary and decompiled form, so pasting into other applications will simply work as text.
Pasting text from other applications works as expected, allowing the use of an external editor to write RPL code, then copy/paste the text and compile on the simulator.
Also, it allows saving/loading to a file, in a format compatible with SDSTO/SDRCL, so objects can be exchanged between the demo and a real calculator using the SD card.

Also ROMs with the same version as the demo are released for all 3 targets (50g, 40,39 series). They can be downloaded from Sourceforge as well as the usual location. Sourceforge contains only the "official" releases, while the hpgcc3.org location contains the latest development builds that get updated more often, for now they are all in sync.
Here are the links to the hpgcc3.org ROMS for the 50g, the 39gs /39g+ and the 40gs

Regarding the newRPL core, many, many bugfixes and stability improvements, in addition to implementing the following new commands:

POS/POSREV
NPOS/NPOSREV
SREPL
SPUSH
SPOP
SDROP
BLAMEERR
RND
TRNC
LNP1
EXPM
RENAME
TVARS
TVARSE
STOF
RCLF
SETNFMT
GETNFMT
GETLOCALE
SIZE
SUB
->NFC
OBJ->
PUT/PUTI
GET/GETI
IFT
IFTE
HIDELOCALS
UNHIDELOCALS

Just a few comments/questions on the new commands.

POSREV- I can see this giving the reverse position for strings, but not for lists (in which POS and POSREV return the same position).

What does NPOS/NPOSREV do?

SPUSH, SPOP, SDROP - Nothing seems to happen when I try and use these. I was expecting that SPOP after doing an SPUSH would restore the previous stack contents.

Steve

[Claudio L.]

(08-14-2017 12:47 AM)smartin Wrote:  Just a few comments/questions on the new commands.

POSREV- I can see this giving the reverse position for strings, but not for lists (in which POS and POSREV return the same position).

Confirmed. Will upload an updated ROM in a couple of days, thanks for the report.

(08-14-2017 12:47 AM)smartin Wrote:  What does NPOS/NPOSREV do?

Same thing, but starting the search from given position N instead of the beginning. If POS returns position 'p', just pass 'p+1' to NPOS to find the next ocurrence.

(08-14-2017 12:47 AM)smartin Wrote:  SPUSH, SPOP, SDROP - Nothing seems to happen when I try and use these. I was expecting that SPOP after doing an SPUSH would restore the previous stack contents.

They work as intended. You need to consider that they do the same as the automatic UNDO feature. So if you run SPUSH from the menu, the only effect you'll notice when you press the left cursor to UNDO, you'll have to press it twice, as there will be 2 identical copies of the stack, one made automatically when you pressed the menu, and the second one done by SPUSH. When you run SPOP from the menu, it pops the UNDO information that's created automatically when you pressed the menu, so you'll notice if you change the stack and then press left, the previous stack won't be there.

To see the real effect, it's best to use them in a program:

Code:


<< 1 2 3 SPUSH 4 5 6 >>

You should see whatever you had on the stack, and 1 2 3 4 5 6. If you press the left cursor to UNDO, you'll see the 4 5 6 vanish, but the 1 2 3 still there (that's the snapshot taken by SPUSH), and if you UNDO again you'll be back at the stack you had when you ran the program, that's a snapshot taken automatically when you pressed either EVAL or the menus.

Code:


<< SDROP INV SPUSH INV >>

This example will first remove the automatic UNDO snapshot, invert a number, then take a snapshot and finally invert it again. If you have a 3 on the stack, you'll see the same 3 at the end of the program, but if you UNDO with left cursor, you'll have 0.3333333... instead of the 3.

The idea is you can SPUSH the original stack state, then explode a list or something like that, and if you encounter an error, you can trap it and do an SPOP before ending your code with a DOERR or BLAMEERR. It makes for a much cleaner exit on complex programs.

BTW, I added how to use SETNFMT in the "Formatting Numbers" section to the wiki, that's one of the new features that needs testing too, please test.

[Claudio L.]

(08-13-2017 02:08 PM)Vtile Wrote:  Would it be good to rename the stack commands differently. As they aren't used as frequently in simple programs as the string commands might be.

SPUSH -> STPUSH or STKPUSH ???

Just a simple quality of life improvement?

Agreed.
STKPUSH, STKPOP, STKDROP from now on, will come up in next update.

[The Shadow]

Question: Will we be getting ARCHIVE and RESTORE commands? I realize we can store programs and the like on the SD card, but a one-and-done command would be really nice.

Another nice thing would be a command that takes a keycode and returns what, if anything, you've defined for it.

[Claudio L.]

(08-15-2017 12:06 AM)The Shadow Wrote:  Question: Will we be getting ARCHIVE and RESTORE commands? I realize we can store programs and the like on the SD card, but a one-and-done command would be really nice.

Another nice thing would be a command that takes a keycode and returns what, if anything, you've defined for it.

ARCHIVE/RESTORE is implemented in the simulator as the Save/Open feature, the only issue is that it needs memory to do its trick, I need to figure our a way to do it without using any extra RAM in order to implement it on-calc. But to answer your question: yes, definitely ARCHIVE and RESTORE will be implemented, I just need to give it some more thought.

The command to get the keycode definition is a good idea and will be implemented. However, it is not as useful as in the 50g because you can have multiple definitions for the same key, the last one overrides the other ones. When you drop the top handler, the previous handler becomes active again.

I created an entry in the bug tracker for each of these ideas.

[The Shadow]

I've just found a weird bug, most likely in ->Q.

If I do:

-1 ACOS 0 +

I get a number which (unsurprisingly) differs from pi0 only in the 33rd digit. (I'm at the standard 32 digit precision.)

If I then do:

->Q ->NUM

I get a number starting with 3.704. By contrast, pi0 followed with ->Q ->NUM works just fine.

[Claudio L.]

(08-17-2017 01:56 AM)The Shadow Wrote:  I've just found a weird bug, most likely in ->Q.

If I do:

-1 ACOS 0 +

I get a number which (unsurprisingly) differs from pi0 only in the 33rd digit. (I'm at the standard 32 digit precision.)

If I then do:

->Q ->NUM

I get a number starting with 3.704. By contrast, pi0 followed with ->Q ->NUM works just fine.

I'll investigate, something not right in ->Q it seems. I tried a few other numbers , using LN, EXP, etc. and can't make it fail, but pi0 0 + fails consistently. Thanks for the report.

[The Shadow]

After some extensive playing around with numbers, I've realized that there is a much-needed command.

Call it SNFMT, which strips formatting from a number or algebraic, basically turning it into "#.A#".

Alternatively, a command ->NFMT. It takes a number or algebraic and a format string, and forces it into that format without changing the global setting. While more flexible than the previous, I think SNFMT covers by far the most common use case without the need for an additional input.

Another possibility I just thought of - instead of a command, a global flag that eliminates display formatting, much like STRIPCOMMENTS.

The issue is that a format convenient for human reading is not at all convenient for programmatic reading when turned into a string.

While there are workarounds for this issue, they're rather clunky, especially when you consider the variations that the LOCALE can introduce as well.

[Claudio L.]

(08-17-2017 02:46 PM)The Shadow Wrote:  After some extensive playing around with numbers, I've realized that there is a much-needed command.

Call it SNFMT, which strips formatting from a number or algebraic, basically turning it into "#.A#".

Alternatively, a command ->NFMT. It takes a number or algebraic and a format string, and forces it into that format without changing the global setting. While more flexible than the previous, I think SNFMT covers by far the most common use case without the need for an additional input.

Another possibility I just thought of - instead of a command, a global flag that eliminates display formatting, much like STRIPCOMMENTS.

The issue is that a format convenient for human reading is not at all convenient for programmatic reading when turned into a string.

While there are workarounds for this issue, they're rather clunky, especially when you consider the variations that the LOCALE can introduce as well.

I thought about it, but I was thinking more on the lines of ->STR. Something like ->FMTSTR which does ->STR with a temporary format override. The argument would be just as flexible as SETNFMT is now (for those unaware, you can read about it on the newRPL wiki), and it could decompile any object, not just a number.
I still need to think about a temporary LOCALE override but keeping the arguments simple. Perhaps I'll add Locale support to the format string somehow.

As it is now, it's quite easy to write a wrapper to achieve this:

Code:


«
  GETLOCALE 'tmplocale' LSTO GETNFMT 'tmpfmt' LSTO { #2Eh #2009h
  #2009h #2Ch } →UTF8 SETLOCALE { "#.A#." 0.000000000001 "#.A#.E*"
  1000000000000 "#.A#.E*" } SETNFMT 0 'err' LSTO IFERR →STR
  THEN
    1 'err' STO 
  END
  tmplocale SETLOCALE tmpfmt SETNFMT IF err THEN
    ERRN DOERR 
  END
»

PS: The code above was written on the simulator, tested then copy/paste straight into this post. It's my favorite new feature of the newRPL simulator...

[Gilles59]

Hi Claudio,

[With the PC application how to do to enter text ?
I can use the keyboard to enter numbers and use the shifted functions but i'm unable to activate the ALPHA key ].
EDIT : OK !! I miss the TAB key to toggle ALPHA mode

Neither I can use the mouse on the virtual keyboard.

EDIT 2 : woo ! I do some tests : It's great !! I will install this on a 50g tomorrow...

Gilles

[The Shadow]

I found another bug, in SETNFMT this time.

I set my number format to "#.A#", then tried to change it back to this:

{ "S#.12#S." 1E-12 "#.12#S.E*" 1E12 "#.12#S.E*" }

But when I do SETNFMT, the third item doesn't change, it remains "#.A#".

In order to change it properly, I first have to do: "#.12#S.E*" SETNFMT then the list above and SETNFMT.