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

[nsg]

Did anybody try newRPL on 39gs?
It lacks RPL natively, so running newRPL there would be interesting option.

There is github project at https://github.com/StopLine/NewRPL-HP-39gs, but it hasn't been updated for a year and it is not clear from project docs if it in the state where something can be uploaded to actual device.

[Claudio L.]

(04-30-2017 11:10 PM)nsg Wrote:  Did anybody try newRPL on 39gs?
It lacks RPL natively, so running newRPL there would be interesting option.

There is github project at https://github.com/StopLine/NewRPL-HP-39gs, but it hasn't been updated for a year and it is not clear from project docs if it in the state where something can be uploaded to actual device.

I wasn't aware of that porting effort.
The 39gs has only 1 MB of flash, newRPL uses 1 MB just for the tables needed to have transcendental functions working at 2000 digits, so it won't fit in 1 MB, no matter how you look at it.
I guess it could work if some other (table-less) approach was used for transcendental functions, or perhaps limiting the precision to 100 digits or so. In any case it's not a trivial effort.

[Claudio L.]

Demo updated in SourceForge!

I uploaded demo Alpha-8a, which is an intermediate release that adds mainly the option to take screenshots. The wiki team needs an easy way to get nice screenshots, so I'm publishing that update earlier than the 0.9 which is planned for June.

[stored]

(04-30-2017 11:10 PM)nsg Wrote:  Did anybody try newRPL on 39gs?
It lacks RPL natively, so running newRPL there would be interesting option.

There is github project at https://github.com/StopLine/NewRPL-HP-39gs, but it hasn't been updated for a year and it is not clear from project docs if it in the state where something can be uploaded to actual device.

Hello nsg!

Sorry for my english.

Repository https://github.com/StopLine/NewRPL-HP-39gs.git is mine.
The problem I encountered it is shrinking size of the decimal numbers subsystem and transcendent functions. Too many constant are scattered by code and dificult change tables to save system consistency.

In my experiments transcendent functions are not work properly.

I will try to continue this project if I can get help with this problem.

Minor warning about flashing ROM: after flashing NewRPL Connectivity Kit not see calculator as normal.
But flashing functional works fine, so if you want it is possible return original ROM.

Old photo on real calculator: https://drive.google.com/open?id=0B605vX...nhnQnJHWVU

[Claudio L.]

(05-02-2017 10:18 AM)stored Wrote:  Hello nsg!

Sorry for my english.

Repository https://github.com/StopLine/NewRPL-HP-39gs.git is mine.
The problem I encountered it is shrinking size of the decimal numbers subsystem and transcendent functions. Too many constant are scattered by code and dificult change tables to save system consistency.

In my experiments transcendent functions are not work properly.

I will try to continue this project if I can get help with this problem.

Minor warning about flashing ROM: after flashing NewRPL Connectivity Kit not see calculator as normal.
But flashing functional works fine, so if you want it is possible return original ROM.

Old photo on real calculator: https://drive.google.com/open?id=0B605vX...nhnQnJHWVU

The changes to the code on github don't seem enough to make newRPL run on a 39gs, do you have more changes that you didn't commit? I'd like to see them all, perhaps I can put the 39gs/40gs as a secondary target. I'd have to recompute and recompress all those tables with less precision, though, and I don't know how small I can get them to be but I could give it a shot.

[smartin]

(05-01-2017 02:40 AM)Claudio L. Wrote:  Demo updated in SourceForge!

I uploaded demo Alpha-8a, which is an intermediate release that adds mainly the option to take screenshots. The wiki team needs an easy way to get nice screenshots, so I'm publishing that update earlier than the 0.9 which is planned for June.

I'm a Mac person and don't have a Windows machine, so I'm outta luck

I guess I could give VirtualBox a try...

-Steve

[Claudio L.]

(05-03-2017 12:57 AM)smartin Wrote:  

(05-01-2017 02:40 AM)Claudio L. Wrote:  Demo updated in SourceForge!

I uploaded demo Alpha-8a, which is an intermediate release that adds mainly the option to take screenshots. The wiki team needs an easy way to get nice screenshots, so I'm publishing that update earlier than the 0.9 which is planned for June.

I'm a Mac person and don't have a Windows machine, so I'm outta luck

I guess I could give VirtualBox a try...

-Steve

Last time I tested it ran well in Wine (https://wiki.winehq.org/MacOS), but I tested it on Linux, not Mac. Should work fine regardless, there's nothing advanced, and Wine will let you save the files directly on the "real" machine, saving you precious time.

[Han]

(05-03-2017 12:57 AM)smartin Wrote:  

(05-01-2017 02:40 AM)Claudio L. Wrote:  Demo updated in SourceForge!

I uploaded demo Alpha-8a, which is an intermediate release that adds mainly the option to take screenshots. The wiki team needs an easy way to get nice screenshots, so I'm publishing that update earlier than the 0.9 which is planned for June.

I'm a Mac person and don't have a Windows machine, so I'm outta luck

I guess I could give VirtualBox a try...

-Steve

You can always just build your own demo (see the section on compiling the virtual calculator)

http://www.hpmuseum.org/forum/thread-725...pl+compile

[compsystems]

Photo album about NewRPL



https://plus.google.com/+JamelTayeb/posts/gmERBRFatdg

[smartin]

(05-06-2017 04:08 PM)compsystems Wrote:  Photo album about NewRPL



https://plus.google.com/+JamelTayeb/posts/gmERBRFatdg

Too bad you can't get the 50g for $50 anymore.

It seems they are now harder to come by, even used.

[Claudio L.]

(05-06-2017 07:44 PM)smartin Wrote:  Too bad you can't get the 50g for $50 anymore.

It seems they are now harder to come by, even used.

Most big retailers seem out of stock, the best I found online is CDW, it seems they have stock at $89 USD, not bad considering it runs over $200 in most ebay (new).

[The Shadow]

Hey guys, I'm back - more or less.

I've just noticed that HIDEVAR, UNHIDEVAR, LOCKVAR, and UNLOCKVAR don't accept lists as input, which would be quite useful.

Also, while trying to work around the above, I discovered that MAPLIST-> isn't working right - it returns results identical to MAP. My understanding from the help was that MAP is supposed to pack results into a list, while MAPLIST-> is not?

You can't get the name of a directory by pressing it, even with quotes active, it will just open. (This may be working as intended, though it's different from oldRPL.)

Finally, a real oddity that I discovered by accident: If you do ALLVARS in the HOME directory, you find that in addition to the variables you know about, and .Settings, there's an immediate program of: :: NUM-> ; in the list!

EDIT: Oh, and UBASE has some strange behavior, too. For example, 1_Pa gives <bar>_kg/m/s^2, but 1_psi gives <foo>_1/m/s^2*kg. Whereas oldRPL gives <blah>_kg/(m*s^2) for both.

EDIT: TRIM doesn't seem to be working for strings above a certain (smallish) size. RTRIM seems fine.

[pier4r]

(05-06-2017 07:44 PM)smartin Wrote:  Too bad you can't get the 50g for $50 anymore.

It seems they are now harder to come by, even used.

I wonder, especially in an era of "lol we have smartphones", how many of them are ending in the bin (I read a discussion where a clueless person, here on the forum, just threw his/her 50g in the bin) or like the 34C here: http://www.hpmuseum.org/forum/thread-8161.html

Well actually 2-3 years old working devices (smartphones, laptops, whatever) end up in the bin because people are clueless, unless they pay enough for their pocket.

[Claudio L.]

(05-06-2017 08:44 PM)The Shadow Wrote:  Hey guys, I'm back - more or less.

I've just noticed that HIDEVAR, UNHIDEVAR, LOCKVAR, and UNLOCKVAR don't accept lists as input, which would be quite useful.

You're right, it is useful so I just added it. Thanks.

(05-06-2017 08:44 PM)The Shadow Wrote:  Also, while trying to work around the above, I discovered that MAPLIST-> isn't working right - it returns results identical to MAP. My understanding from the help was that MAP is supposed to pack results into a list, while MAPLIST-> is not?

You are correct again, this command was reusing parts of the EVAL command for lists. I broke it when I changed the behavior of EVAL on lists to not explode the list. I have to fix this one. Thanks for the report.

(05-06-2017 08:44 PM)The Shadow Wrote:  You can't get the name of a directory by pressing it, even with quotes active, it will just open. (This may be working as intended, though it's different from oldRPL.)

Indeed, works as intended: in newRPL you can traverse subdirectories while in the editor, so it's easy to find variables. You can get the name simply trying to RCL the variable (Right-shift and then the menu key, or right-shift-hold and the menu key).
Now while testing it you made me find a bug: In 'A' mode, using right-shift+key was inserting 'NAME' RCL instead of just the directory name. I fixed that.

(05-06-2017 08:44 PM)The Shadow Wrote:  Finally, a real oddity that I discovered by accident: If you do ALLVARS in the HOME directory, you find that in addition to the variables you know about, and .Settings, there's an immediate program of: :: NUM-> ; in the list!

I could not reproduce this at all. It seems somehow you have a variable in HOME whose name is a program... never seen anything like that.

(05-06-2017 08:44 PM)The Shadow Wrote:  EDIT: Oh, and UBASE has some strange behavior, too. For example, 1_Pa gives <bar>_kg/m/s^2, but 1_psi gives <foo>_1/m/s^2*kg. Whereas oldRPL gives <blah>_kg/(m*s^2) for both.

Units are not sorted for display at all. I guess the definition of psi, is lbs/in^2, then the definitions of lbs and in are replaced and the units end up in a non-natural order.
Perhaps they should be sorted, units with positive exponents first.

(05-06-2017 08:44 PM)The Shadow Wrote:  EDIT: TRIM doesn't seem to be working for strings above a certain (smallish) size. RTRIM seems fine.

Can you provide an example that fails? my tests here worked OK. Thanks.

[The Shadow]

(05-07-2017 03:24 AM)Claudio L. Wrote:  

(05-06-2017 08:44 PM)The Shadow Wrote:  I've just noticed that HIDEVAR, UNHIDEVAR, LOCKVAR, and UNLOCKVAR don't accept lists as input, which would be quite useful.

You're right, it is useful so I just added it. Thanks.

QUOTEID and UNQUOTEID might be handy too.

Quote:

(05-06-2017 08:44 PM)The Shadow Wrote:  Finally, a real oddity that I discovered by accident: If you do ALLVARS in the HOME directory, you find that in addition to the variables you know about, and .Settings, there's an immediate program of: :: NUM-> ; in the list!

I could not reproduce this at all. It seems somehow you have a variable in HOME whose name is a program... never seen anything like that.

...And now I can't either. I've done a warmstart since then, so perhaps garbage collection caught it or something?

(05-06-2017 08:44 PM)The Shadow Wrote:  

Quote:EDIT: Oh, and UBASE has some strange behavior, too. For example, 1_Pa gives <bar>_kg/m/s^2, but 1_psi gives <foo>_1/m/s^2*kg. Whereas oldRPL gives <blah>_kg/(m*s^2) for both.

Units are not sorted for display at all. I guess the definition of psi, is lbs/in^2, then the definitions of lbs and in are replaced and the units end up in a non-natural order.
Perhaps they should be sorted, units with positive exponents first.

There's something similar going on with algebraics... 'X/2' EVAL's to '1/2*X', which seems odd.

Also, algebraics aren't handling 0 right: 'X*0' EVAL's to '0*X', 'X+0' and '0+X' don't change, and 'X+1+Y-1' EVAL's to 'X+0+Y'.

Quote:

(05-06-2017 08:44 PM)The Shadow Wrote:  EDIT: TRIM doesn't seem to be working for strings above a certain (smallish) size. RTRIM seems fine.

Can you provide an example that fails? my tests here worked OK. Thanks.

I've been trying to recreate FXND, because I need it for a lot of things I do. In the absence of POS and SUB, I've been using NTHTOKEN, TRIM, and RTRIM.

If you do ->Q on pi0 (other 'big' fractions work this way too), you get '1.483552189208E19/4.722293284944896863E18'

I use NTHTOKEN to split that around the "/". So far so good. I RTRIM the first piece to get rid of the "'" and it works. I TRIM the second piece of "'", and I get "4.722293284944896863E18', with the single quote still on the end but the double quote missing. This object then acts very bizarrely when I STR-> and try to do arithmetic with it - it acts sort of like an algebraic.

[The Shadow]

In other news, I've been trying to determine the locked/unlocked state of a variable programmatically using the following:

<< DUP RCL SWAP IFERR STO THEN DROP2 1 ELSE 0 END >>

This works fine on unlocked variables, returning a 0 as expected; but when I try it on a locked variable, it throws a 'STO: Bad argument count' error. Even granted there's such an error, which there shouldn't be, why isn't the IFERR handling it?

(How about a LOCK? or LVARS command? LOCK? would do what my above program does, testing a single variable; LVARS would return a list of all locked variables in the current directory. Wouldn't need both, one or the other would be sufficient.)

[Claudio L.]

(05-07-2017 04:04 AM)The Shadow Wrote:  There's something similar going on with algebraics... 'X/2' EVAL's to '1/2*X', which seems odd.

Also, algebraics aren't handling 0 right: 'X*0' EVAL's to '0*X', 'X+0' and '0+X' don't change, and 'X+1+Y-1' EVAL's to 'X+0+Y'.

Bear in mind there's no CAS yet. There's only a rudimentary numeric reduction that allows you to work with fractions, so when you EVAL, numbers tend to be grouped together before variables, much like when you write a polynomial:
a*x+b*X^2+... the coefficients go first.
and it favors displaying fractions as fractions 1/2, instead of 2^(-1)*X.

Regarding simplifications like adding 0: I didn't get to implement any of that yet, it makes sense that adding 0 (or multiplying by 1) should be eliminated during the numeric reduction.
Now multiplying by 0 is a different story: 0*X cannot be simplified unless you know what X contains. It could be Infinity, then the result would be indeterminate, not zero.

(05-07-2017 04:04 AM)The Shadow Wrote:  

Quote:Can you provide an example that fails? my tests here worked OK. Thanks.

I've been trying to recreate FXND, because I need it for a lot of things I do. In the absence of POS and SUB, I've been using NTHTOKEN, TRIM, and RTRIM.

If you do ->Q on pi0 (other 'big' fractions work this way too), you get '1.483552189208E19/4.722293284944896863E18'

I use NTHTOKEN to split that around the "/". So far so good. I RTRIM the first piece to get rid of the "'" and it works. I TRIM the second piece of "'", and I get "4.722293284944896863E18', with the single quote still on the end but the double quote missing. This object then acts very bizarrely when I STR-> and try to do arithmetic with it - it acts sort of like an algebraic.

In this case NTHTOKEN worked, RTRIM and TRIM both worked. What happens is that for whatever reason it seems my code beautifier is adding a new line at the end of that object, so TRIM is not removing the tick mark, because there's a non-separator character after that.
You need to include a newline as a separator as well (for now anyway, the code beautifier doesn't need to add a newline at the end so that's probably changing soon):
"'
" TRIM
and it will remove both characters.

As far as when you ran STR-> on that number, it seems it was compiled as a valid identifier, which is a bug (it should've been rejected as a syntax error). It behaves like any other identifier after that.

[The Shadow]

(05-07-2017 06:55 PM)Claudio L. Wrote:  In this case NTHTOKEN worked, RTRIM and TRIM both worked. What happens is that for whatever reason it seems my code beautifier is adding a new line at the end of that object, so TRIM is not removing the tick mark, because there's a non-separator character after that.

But why is the double quote vanishing from the end of the string? Surely that should never happen in response to a string operation?

Quote: You need to include a newline as a separator as well (for now anyway, the code beautifier doesn't need to add a newline at the end so that's probably changing soon):
"'
" TRIM
and it will remove both characters.

Okay, that'll work as a stopgap. Thanks for all your work!

And one more thing!

It would be nice if a menu display program could specify the decoration of the button somehow - or, alternatively, if the decoration entry could be a program. That way you could, for example, invert a button based on a change in its contents.

[Claudio L.]

(05-07-2017 06:21 AM)The Shadow Wrote:  In other news, I've been trying to determine the locked/unlocked state of a variable programmatically using the following:

<< DUP RCL SWAP IFERR STO THEN DROP2 1 ELSE 0 END >>

This works fine on unlocked variables, returning a 0 as expected; but when I try it on a locked variable, it throws a 'STO: Bad argument count' error. Even granted there's such an error, which there shouldn't be, why isn't the IFERR handling it?

A new feature in newRPL (yet to be documented properly... but at least we have a wiki now...) is that error handlers run under strict stack protection. The "Bad Argument count" is generated by DROP2, not by STO. But it's not easy to determine where an error is generated within an error handler itself (should be something like "error handler reentered" or something). But there's no easy way to generate that message and blame the right command.
This feature allows you to RESUME execution from the error handler. It's good when you setup error traps for a large program, and the error is predictable and you know you can safely ignore it (like "Infinite result" for example). For RESUME to be even possible, the stack and running environment must be preserved and the error handler should not be able to modify it.
Now back to your example, you just need to do your cleanup later.

<< DUP RCL SWAP IFERR STO THEN 1 ELSE 0 END
IF DUP THEN UNROT DROP2 END
>>

(05-07-2017 06:21 AM)The Shadow Wrote:  (How about a LOCK? or LVARS command? LOCK? would do what my above program does, testing a single variable; LVARS would return a list of all locked variables in the current directory. Wouldn't need both, one or the other would be sufficient.)

I don't see why not. I'll have to add ISLOCKEDVAR, ISHIDDENVAR or something like that.

[Claudio L.]

(05-07-2017 07:09 PM)The Shadow Wrote:  But why is the double quote vanishing from the end of the string? Surely that should never happen in response to a string operation?

It didn't vanish (it's not possible), it's on the next line (remember there's a newline at the end of string), you'll see it if you edit and press cursor down, like this:
"432543543543534543'
"

(05-07-2017 07:09 PM)The Shadow Wrote:  And one more thing!

It would be nice if a menu display program could specify the decoration of the button somehow - or, alternatively, if the decoration entry could be a program. That way you could, for example, invert a button based on a change in its contents.

I believe that's already covered but I'll have to check the source code before I can give you a final answer (can't recall if that's possible or not).

EDIT: Yes, you can do that, your program needs to return a list just like you would have included if you did it manually. You cannot put another program inside the list, though, it's not fully recursive but anything you can do "by hand" your code can do programmatically.