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

[Neve]

I installed NewRPL on my HP50g. Although I seems very promising and faster than the stock FW, I can’t yet get used to the screen and keyboard layout.
Also, I can’t find all the 128 flags I’m used to.
Where are they?

[pier4r]

(09-17-2017 10:53 AM)Neve Wrote:  I can’t yet get used to the screen and keyboard layout.
Also, I can’t find all the 128 flags I’m used to.

For the flags I do not know, for the keyboard. It is not that immediate (once newRPL is stable I guess one needs stickers to relable the 50g).

The wiki (to which I should still properly contribute) helps here: https://newrpl.wiki.hpgcc3.org/doku.php?...2:keyboard

[Nigel (UK)]

Possible bug:

CONVERT (from Units menu or from keyboard) gives an "Error: Empty data stack (internal)" message when there is a list of numbers in level 2 and a list in level 1. The next four entries to the stack disappear without trace; after that, the calculator seems to work again without problems.

I'm really enjoying this latest release. I've followed your suggestion to use Font7A for the menus; it looks very nice. Helix is a talented font designer!

Nigel (UK)

[Claudio L.]

(09-18-2017 11:23 AM)Nigel (UK) Wrote:  Possible bug:

CONVERT (from Units menu or from keyboard) gives an "Error: Empty data stack (internal)" message when there is a list of numbers in level 2 and a list in level 1. The next four entries to the stack disappear without trace; after that, the calculator seems to work again without problems.

I'm really enjoying this latest release. I've followed your suggestion to use Font7A for the menus; it looks very nice. Helix is a talented font designer!

Nigel (UK)

Good catch. None of the Units commands were ready to work with lists. I fixed that, will come out in the next update. Thanks for the report.

[Helix]

(09-18-2017 11:23 AM)Nigel (UK) Wrote:  I'm really enjoying this latest release. I've followed your suggestion to use Font7A for the menus; it looks very nice. Helix is a talented font designer!

Thank you Nigel! I find too that this release is very pleasing, even if my preferences are quite different. For me, the menus look good only with Font6B. Font7A is perfect for the command line, to view large objects such as programs.

(09-15-2017 04:26 PM)Claudio L. Wrote:  Any of the names above can be used until somebody starts designing and publishing user-created font packs.

You have to tell us how to build a font pack to be used with FNTSTO…
I've realized that in Font8A and Font7A, the slash inside the zero is useless, as the zero can't be confused with the letter O, whereas it looks like an 8. My main concern about fonts is legibility.

Now, here are some quirks:

- If the font for the command line is smaller than 8, the directory path and the autocompletion area appear a bit too high. This is not a problem with a 7-pixel font, only with a 6-pixel font.

- if only the first menu is displayed, and the calculator is turned off while a program is edited, at restart the display is messed up, and the calculator can freeze if the dual menu is not quickly restored.

- when a narrow or a small font is chosen for the command line, the entire width of the screen is not used by the editor, so there is some waste of space. For example, Font8A was designed to show more text in the editor, but currently this changes nothing.

- With a 7-pixel font for the command line, and only one menu displayed, the editor shows 9 lines, so no more than the HP 50g with a 8-pixel font and no header. At the top of the screen, there is room for a tenth line.

Also on the HP50g, there are the reserved variable STARTED and EXITED, which are automatically evaluated when entering and exiting the editor. As explained in the AUR, this can be used "to set a header size of 0 when entering the command line and restore it to 2 when exiting (in order to increase the editor window size)."
I wonder if a similar feature could be implemented to allow switching automatically between two and one menu when an object is edited.

[Claudio L.]

(09-18-2017 10:29 PM)Helix Wrote:  You have to tell us how to build a font pack to be used with FNTSTO…

Same way you've always done it: a bitmap with all the letters, with an extra line of pixels that alternates to define the width of the characters, and a text file with the Code Point of each symbol in the image.
I just need to modify the conversion program a little bit so instead of producing C code as output it produces "nrpl" binary files suitable for SDRCL, that's no big deal.

(09-18-2017 10:29 PM)Helix Wrote:  I've realized that in Font8A and Font7A, the slash inside the zero is useless, as the zero can't be confused with the letter O, whereas it looks like an 8. My main concern about fonts is legibility.

Now, here are some quirks:

- If the font for the command line is smaller than 8, the directory path and the autocompletion area appear a bit too high. This is not a problem with a 7-pixel font, only with a 6-pixel font.

I think you mean when the status area font is larger than 6 pixels. I can see the glitch, autocompletion is not respecting the font height. Will fix that.

(09-18-2017 10:29 PM)Helix Wrote:  - if only the first menu is displayed, and the calculator is turned off while a program is edited, at restart the display is messed up, and the calculator can freeze if the dual menu is not quickly restored.

I can only reproduce this partially. Only when editing an object that takes more than the 9 lines available I can see the menu disappear and the stack taking more than it should. However, I can't make it freeze or crash. The menu vanishes when I move up or down with the cursor, seems to be the stack taking more than its share of screen. I'll fix it.

(09-18-2017 10:29 PM)Helix Wrote:  - when a narrow or a small font is chosen for the command line, the entire width of the screen is not used by the editor, so there is some waste of space. For example, Font8A was designed to show more text in the editor, but currently this changes nothing.

The compiler decompiles objects regardless of the font used to display them. There's a default preferred width in characters, which I'm planning to expose as a user setting, but it's not done yet. If your characters are displayed as narrow, then it may waste some screen space. As soon as I provide that setting you'll be able to make it work to your liking.

(09-18-2017 10:29 PM)Helix Wrote:  - With a 7-pixel font for the command line, and only one menu displayed, the editor shows 9 lines, so no more than the HP 50g with a 8-pixel font and no header. At the top of the screen, there is room for a tenth line.

There's a minimum of 2 pixels space required for the stack and separator line. If the few pixels left don't amount to 7 then an extra line is not drawn. In

(09-18-2017 10:29 PM)Helix Wrote:  Also on the HP50g, there are the reserved variable STARTED and EXITED, which are automatically evaluated when entering and exiting the editor. As explained in the AUR, this can be used "to set a header size of 0 when entering the command line and restore it to 2 when exiting (in order to increase the editor window size)."
I wonder if a similar feature could be implemented to allow switching automatically between two and one menu when an object is edited.

It certainly could.

[The Shadow]

(09-17-2017 10:53 AM)Neve Wrote:  I installed NewRPL on my HP50g. Although I seems very promising and faster than the stock FW, I can’t yet get used to the screen and keyboard layout.
Also, I can’t find all the 128 flags I’m used to.
Where are they?

Do you mean the user flags? They're all there. Or do you mean the settings flags? Some of them are shown in the Settings/Flags menu, but the rest are not yet documented.

[Claudio L.]

All ROMs were updated to build #911.

Changes:

* All unit commands now support proper list handling (as reported above).
* Most display glitches were corrected. Only one remains that I know of, full screen command line with hidden second menu and press-and-hold command help.
* Fixes a bug in SD card that gave an error trying to mount a card for more than 300 ms (found this happening some times when playing with a calculator switcher, more on that below).
* Fixed the font objects: the font converter had incorrect object sizes for all fonts.
* Fixes some bad behavior in SETNFMT that made it not work reliably.

Here's something interesting to play with: I found out that SDARCHIVE/SDRESTORE are quick enough to use as a calculator switcher.

On a calc with a good SD card, create a program SWITCH and keep it handy:

Code:


«
  "CALC" CALCID + ".NRPB" + SDARCHIVE
  "CALC" NEXTCALCID + ".NRPB"  + SDRESTORE 
»

Now store any number on 'CALCID', let's say 1, and another number in 'NEXTCALCID', let's say 2.
Run SWITCH, it will fail on SDRESTORE with file not found, that's OK for now.
Now set 'CALCID' to 2, and 'NEXTCALCID' to 1. and run SWITCH again.
From now on, SWITCH will alternate between these 2 calculators. From now on the 2 calcs can diverge, one for work, one for dangerous tests, etc.
To distinguish them, I used flags -15 and -16 to change the menus to white. You can also use different fonts on each calc. Of course, technically you can also look at 'CALCID'.
This way it's easy to "fork" a calculator by changing its CALCID and running SWITCH. Then you need to make sure other calcs NEXTCALCID is set properly so SWITCH can cycle through them all.

[The Shadow]

(09-19-2017 08:27 PM)Claudio L. Wrote:  Here's something interesting to play with: I found out that SDARCHIVE/SDRESTORE are quick enough to use as a calculator switcher.

I had already considered something like this! You could even make a TMENU of various named calculators.

EDIT: And store the list of calculator names on the SD card, so you only have to change it once.

What is the ".NRPB" for? To make it easier to load onto the PC emulator?

[The Shadow]

Claudio,

You forgot to mention that you also fixed all the commands that take lists for input, which discombobulated a bunch of user keys I've set up for navigation. All fixed now, though!

And! Whatever you did to SETNFMT fixed the issue I had with it earlier that you couldn't reproduce! I don't know why it would work weirdly for me but not for you, but I'll take the fix regardless.

[Claudio L.]

(09-19-2017 09:58 PM)The Shadow Wrote:  

(09-19-2017 08:27 PM)Claudio L. Wrote:  Here's something interesting to play with: I found out that SDARCHIVE/SDRESTORE are quick enough to use as a calculator switcher.

I had already considered something like this! You could even make a TMENU of various named calculators.

EDIT: And store the list of calculator names on the SD card, so you only have to change it once.

What is the ".NRPB" for? To make it easier to load onto the PC emulator?

In the PC it is customary to use a file extension, so I chose .nrpl for objects (the "Save Level 1 as..." kind), and thought to replace the "l" with the "b" for backup, for the files created with SDARCHIVE (which are not compatible, as backups are not RPL objects). But it's irrelevant, really.

[Claudio L.]

(09-19-2017 11:18 PM)The Shadow Wrote:  Claudio,

You forgot to mention that you also fixed all the commands that take lists for input, which discombobulated a bunch of user keys I've set up for navigation. All fixed now, though!

And! Whatever you did to SETNFMT fixed the issue I had with it earlier that you couldn't reproduce! I don't know why it would work weirdly for me but not for you, but I'll take the fix regardless.

It was a dumb bug, the thing is I work on a couple of different machines, and pick up newRPL whenever I have a minute to spare. Perhaps I fixed the bug on one machine but never committed, therefore couldn't reproduce the bug. But I built the firmware on another machine now and I noticed the strange behavior on my calc.
And yes, I fixed a bunch of commands that used lists, not just CONVERT (in particular the ones that weren't supposed to return anything but were returning empty lists), but I'm sure it wasn't all of them. I have to go library by library making sure every command accepts lists properly, and there's a lot of them.

[The Shadow]

(09-20-2017 02:38 AM)Claudio L. Wrote:  In the PC it is customary to use a file extension, so I chose .nrpl for objects (the "Save Level 1 as..." kind), and thought to replace the "l" with the "b" for backup, for the files created with SDARCHIVE (which are not compatible, as backups are not RPL objects). But it's irrelevant, really.

Is there any way to take a backup file saved with SDARCHIVE and load it onto the PC emulator?

[Claudio L.]

(09-20-2017 02:49 AM)The Shadow Wrote:  Is there any way to take a backup file saved with SDARCHIVE and load it onto the PC emulator?

It's a very tricky procedure so you need to follow the exact steps below (and dress like a surgeon... :-)

1. Pull the SD card from your calc
2. Put in on the PC
3. Open the file from the simulator
   

Jokes aside, since the simulator runs a build of the same exact same source code, files are binary compatible between the simulator and the calc.
There's only one potential problem: The version of the firmware should be the same (preferably, not necessarily) to avoid programs/objects that exist on one version and not the other. For example if you have on your calc a program using the SADD command, it will become an invalid opcode on the simulator, since I published it before I implemented that command. Custom fonts will not show for the same reason, etc.

[Neve]

(09-19-2017 04:26 PM)The Shadow Wrote:  

(09-17-2017 10:53 AM)Neve Wrote:  I installed NewRPL on my HP50g. Although I seems very promising and faster than the stock FW, I can’t yet get used to the screen and keyboard layout.
Also, I can’t find all the 128 flags I’m used to.
Where are they?

Do you mean the user flags? They're all there. Or do you mean the settings flags? Some of them are shown in the Settings/Flags menu, but the rest are not yet documented.

I mean all the 128 flags you would normally find under “MODE—>FLAGS” on an non modified, stock HP50g.
I can’t find those.

Cheers

[The Shadow]

(09-20-2017 03:18 AM)Neve Wrote:  

(09-19-2017 04:26 PM)The Shadow Wrote:  Do you mean the user flags? They're all there. Or do you mean the settings flags? Some of them are shown in the Settings/Flags menu, but the rest are not yet documented.

I mean all the 128 flags you would normally find under “MODE—>FLAGS” on an non modified, stock HP50g.
I can’t find those.

Some of them no longer exist, some of them aren't implemented yet, and others are available through the Settings/Flags menu. Unfortunately the ones not found there are not yet well documented.

[Neve]

(09-20-2017 05:22 AM)The Shadow Wrote:  

(09-20-2017 03:18 AM)Neve Wrote:  I mean all the 128 flags you would normally find under “MODE—>FLAGS” on an non modified, stock HP50g.
I can’t find those.

Some of them no longer exist, some of them aren't implemented yet, and others are available through the Settings/Flags menu. Unfortunately the ones not found there are not yet well documented.

Hmmm, that really sucks. I need access to many of these flags. I guess NewRPL is not for me then...
The screen is too crowed with two menu lines and you can’t even set the mini fonts? Or at least have the choice NOT to have a 2-line menu with reassigned keys (which I personally very much dislike)?
Why would anyone want to have keys not behaving the way they should and have a crowded display?
As much as I understand and welcome the new firmware, these no-essential changes Are very much non-appealing to me.

Just my 2 cts

[The Shadow]

(09-20-2017 05:42 AM)Neve Wrote:  The screen is too crowed with two menu lines and you can’t even set the mini fonts? Or at least have the choice NOT to have a 2-line menu with reassigned keys (which I personally very much dislike)?

You certainly can change to a 1-line menu, and change the fonts. To do the first, press ON-hold-J.

Changing the fonts is discussed on page 5 of this thread, it just got implemented.

You can reassign keys back to their familiar places via user keys, available through System/Keys.

Quote:Why would anyone want to have keys not behaving the way they should and have a crowded display?

I find the two menus very useful, personally. I keep one for the VAR menu and the other for everything else. Very handy for programming in particular! The reassigned STO key does take a little getting used to, I'll admit.

The newRPL wiki is here, if it helps: https://newrpl.wiki.hpgcc3.org/doku.php

[Neve]

(09-20-2017 06:05 AM)The Shadow Wrote:  Changing the fonts is discussed on page 5 of this thread, it just got implemented.

OK, we’ll see how this evolves.

Quote:You can reassign keys back to their familiar places via user keys, available through System/Keys.

I think it should be the other way around. You should be able to set the NewRPL keys by assigning them to USER keys. Not being imposed a new keys scheme to begin with.

Quote:Why would anyone want to have keys not behaving the way they should and have a crowded display?

[quoteI find the two menus very useful, personally. I keep one for the VAR menu and the other for everything else. Very handy for programming in particular! The reassigned STO key does take a little getting used to, I'll admit.
[/quote]
I get your drift. Everyone has their own habits and way of doing things. However, as with the keys, these features should be user-defined options, not imposed on you to begin with.
To me, a new system or firmware should look the same as the “original” one, but be way better under-the-hood. Faster, more options maybe, or more flexible and efficient, I should say. Although NewRPL has, I guess, mostly achieved the latter, the former is very, very much to be desired...

Quote:The newRPL wiki is here, if it helps: https://newrpl.wiki.hpgcc3.org/doku.php

I know, but thank you. I appreciate your input.

[Claudio L.]

(09-20-2017 06:39 AM)Neve Wrote:  To me, a new system or firmware should look the same as the “original” one, but be way better under-the-hood.

Therefore, modern cell phones should look like this then, but with a modern CPU, voice controlled Android OS (touchscreens are a disgrace, nothing like that old mouthpiece with a nice stretchy cord, in the end people miss it, that's why the icons still look that way).



Jokes aside, ask yourself if a relatively minor interface change on a 30-year old design is worth adapting to. I did adapt and works quite well for daily use. Having your variables *and* your most used commands available at once is really efficient. And this also allows you to insert content of variables in the editor, and even traverse directories while you are editing text. I guess you didn't even try the interactive stack yet.

By the way, the flags you desperately need are mostly gone for good. There's a few flags but newRPL removed much of the flag nightmare (exact vs approx mode, commands that switch to radians in order to work, etc).
Some of them are still there to control specific system behaviors but we eliminated flag-dependent execution as much as possible.

If you want to give up that easily, go ahead. If you dare to explore it a bit more, I'm sure you'll change your mind.