I disagree. newRPL is an implementation of the existing language RPL. It's not a new programming language therefore it belongs exactly where it is, as a tiny footnote at the bottom of the main RPL language page.

Wikipedia is a great place, doesn't need to be polluted just because we want some self-promotion. newRPL has its own wiki where all the differences and similarities are made visible.

I disagree. newRPL is an implementation of the existing language RPL. It's not a new programming language therefore it belongs exactly where it is, as a tiny footnote at the bottom of the main RPL language page.

I agree with you on this, Claudio, but I have been wondering about a somewhat related issue. Once newRPL is a little more stable and complete, maybe you should inquire about getting a niche for it at hpcalc.org? It's sufficiently different from the stock 50g that one can't just blindly port programs over (or at all if they're in SysRPL!), and it's more than sufficiently interesting to motivate some to switch.

(09-27-2017 01:46 PM)Claudio L. Wrote: I disagree. newRPL is an implementation of the existing language RPL. It's not a new programming language therefore it belongs exactly where it is, as a tiny footnote at the bottom of the main RPL language page.

I agree with you on this, Claudio, but I have been wondering about a somewhat related issue. Once newRPL is a little more stable and complete, maybe you should inquire about getting a niche for it at hpcalc.org? It's sufficiently different from the stock 50g that one can't just blindly port programs over (or at all if they're in SysRPL!), and it's more than sufficiently interesting to motivate some to switch.

That's not a bad idea, I can't pursue it right now simply because newRPL is not ready for the normal user yet. It's only for the few "illuminati" in this forum, at least for the time being. Once it's finished I can submit to Eric's site.

(09-29-2017 01:12 PM)compsystems Wrote: I think it's a great idea, send the NEWRPL project files to hpcalc.org, because that site has a lot of traffic and is famous, while this forum very few visit it.

Yes, just not yet. I'm providing updates very frequently in this forum, fixing bugs and adding functionality. I can't be updating hpcalc.org so frequently.
The "problem" with newRPL is that until it's finished, it can't be a permanent replacement for the stock firmware and that is what discourages most people.
This forum has few visitors, but those few are the *only* people that would be willing to try it as it is now, without completely dismissing it.

I would say 90% of people would do what our friend Neve (rightfully) did: try it for a few seconds and immediately dismiss it. If and when that 90% try it for the first time, it has to be ready, has to provide them with the best experience. For example, Neve looked for a GUI to change the flags. Very simple, but while the settings can be changed there's no GUI implemented yet. When that's done, be it flags or other (newer) ways to change the settings, everything would feel much more familiar to him.
Make no mistake, it's not Neve's problem, it's newRPL's problem, but that will be solved with project maturity, nothing else. Until then, it's only for the people in this forum, willing to put their 50g's through the works.

EDIT: Thankfully, Neve will give it a second look, but then... he's one of us in the forum! Other people won't be so understanding.

Can we transfer files between the PC and hp50-New RPL?, If so, the binary format will be stable, that is, in the future these files will be compatible.

PS:
An idea: please made the imaginary unit optional
for example XCAS-ti-mode uses as an imaginary unit the character ¡ Inverted exclamation character (Spanish ! -> ¡) there would be no problem for the simulator because that is available I believe in all PC keyboard. the objetive is releasing the vowel i as a counter variable.

The Classpad calculator allows to choose between i, j, and the vowel i is used in electrical and electronic engineering as current

(09-29-2017 05:49 PM)compsystems Wrote: the character ¡ Inverted exclamation character (Spanish ¡!) that is available I believe in all PC keyboards,

And you believe wrong!

But who knows, maybe hpcalc.org users have it on their keyboards.

Why would my site's users have it on their keyboards?

It's on Spanish keyboards and might be available on some other layouts with AltGr (like the US International layout on Windows that almost nobody in the US uses, or some other alternate keyboard layouts like a couple I made for my personal use), but I suspect most visitors to my site wouldn't have it on their keyboards.

(09-29-2017 05:49 PM)compsystems Wrote: An idea: please made the imaginary unit optional
for example XCAS-ti-mode uses as an imaginary unit the character ¡ Inverted exclamation character (Spanish ! -> ¡) there would be no problem for the simulator because that is available I believe in all PC keyboard. the objetive is releasing the vowel i as a counter variable.

There's already Unicode characters that are used as the complex unit, no need to come up with something completely non-standard.

However, we are still debating whether to use the double struck 'i' or 'j' for the complex unit or the regular letters. It will probably be more cumbersome to type with a special letter, but as you said, it will free i,j to be used as variables, and they are actually the most familiar indexes in most matrix and summation formulae.
The clear advantage would be that both 'i' and 'j' can be defined as the complex unit at the same time, and be used interchangeably. There would still be the need for a flag to prefer 'i' or 'j' on complex symbolic results.

If you have a variable with something stored in it, then do CRDIR on the same name, it will overwrite the variable. Probably should throw an error instead.

...Huh. I just noticed that oldRPL does this too. I'm not at all sure it's a good idea.

Sorry for your valuable data lost.
CRDIR is no different from STO, except the object being stored is a newly created directory.
newRPL does have directory overwrite protection in STO to prevent the user from overwriting an entire directory by accident. I just noticed this safeguard is not enabled in CRDIR, now that's something I want to fix.
Variables get overwritten all the time, either by STO or CRDIR. Adding a question "Are you sure you want to overwrite this variable?" every time you STO something would make the calculator pretty much unusable.
If you think about it, no OS will ask for confirmation when a program opens a file for writing. The user-facing application might detect the file as existing and ask the user if he wants to overwrite, not the OS.
In this case, if you are writing a program and you want to let the user know, do something like this:

Code:

«
@@ THIS IS A STO REPLACEMENT THAT DOESN'T OVERWRITE

@@ PUT 1 IF var EXISTS AND 0 IF IT DOESN'T.
IFERR DUP RCL DROP THEN 0 ELSE 1 END

@@ NOW DO SOMETHING ABOUT IT
IF THEN DUP UNQUOTEID →STR " already exists" + DOERR @@ Here UNQUOTEID is just so it looks better in the string
ELSE DROP STO @@ Here DROP is needed because the error in DUP RCL leaves an extra var
END
»

Although this is not too different from using LOCKVAR/UNLOCKVAR on certain variables.

I quite agree that one wouldn't want the OS nagging you every time you wanted to STO something. But I just can't think of any reason why anyone would deliberately create a directory with the same name as an existing program. It seems like it would only ever come up through inadvertance.

(10-08-2017 03:14 PM)The Shadow Wrote: Something else: If you put a large list on the stack (ie, several hundred numbers long) it will often be invisible. It will generally turn visible if you do any kind of list operation on it.

From what you describe, it seems it's failing to draw the object somehow and stores a blank picture on the cache. When you do an operation, you are no longer looking at the original list, but a new object containing the result. It should also appear if you create more than 32 new obejcts on the stack, to "push" that object to fall out of the cache and be redrawn.
However, this is just a theory because I can't reproduce it. I tried creating a long list:

Code:

<< { } 1 1000 FOR K K INV ADD NEXT >>

The INV is to get a lot of digits, making the list larger to display.
Then I ran the above at different precisions so the list would decompile to a longer or shorter string but couldn't see the effect at all.

(09-22-2017 10:33 PM)Eric Rechlin Wrote: Also, after I installed newRPL 0.9a on Windows 10, the only thing it added to its Start menu group was the Uninstall shortcut -- it didn't create a shortcut to run the actual newRPL program from. I don't know if this is a problem with my system or a bug in the installer, but I thought I'd point it out.

That's strange. I created the installer using the open source Excelsior installer, and tested it before uploading. It created a desktop icon, and inside the menu group there's the uninstaller and the actual program. I'm also using Windows 10 on this machine. Perhaps uninstall and try again?
If not then I'll have to perhaps start using a different installer creator software.

I struck the same issue on a Vista-Home Premium SP2 (32-bit) as Eric did, that I merely have the uninstaller in the newRPL Start directory. The behaviour seems to be the same in that it simply doesn't create the desktop icon, nor put the executable into the Start->newRPL menu group alongside the uninstaller. Thankfully the group doesn't get removed after first view, like some instances of Win10. Perhaps yet another reason to stay away from Win10.

Here are the steps I did to reproduce the problem:

Start installer. When asked, feed it with a path to install to; here, that's E:\newRPL Desktop.

When asked for program group, provide this: HP-Emulators\newRPL Desktop 0.9aAlpha.

The rest of the steps are (relatively) obvious.

For the current documentation, I'd also like to suggest a wiki link in the first post, as I missed the link until way further down the thread. The first post would be a fantastic place to have this information alongside the links you've already provided, as the wiki provides several very important pieces of information such as the revamped menu interface (which I have a bug I want to post against that, or a misunderstanding). I'll post my thoughts on that menu thing tomorrow, as it's fantastically late here where I am at the moment.

Now, onto the desktop application you've helpfully provided. It's a great way of testing it all out without blowing a running HP50G's setup away, but I got stuck by one small issue. All that got installed on my system were: libgcc_s_dw2-1.dll (no version), libstdc++-6.dll (no version), libwinpthread-1.dll (1.0.0.0), QT5Core.dll (5.8.0.0), QT5GUI.dll (5.8.0.0) and QT5Widgets.dll (5.8.0.0), newrpl-ui.exe, Uninstall.exe and platforms\qwindows.dll (5.8.0.0). When I tried executing newrpl-ui.exe, Windows barfed up and said this:

This application failed to start because it could not find or load the Qt platform plugin "windows" in "". Reinstalling the application may fix this problem.

It seemed I needed to install a version of QT, as the version you released wouldn't work on my system without me running windeployqt.exe from my QT install against the newrpl-ui.exe and letting it copy my QT's dlls into the same directory. Perhaps an extra page talking about what to do for the desktop application in the wiki.

I'm slowly getting used to newRPL, I don't feel confident enough to spring for another HP50G, but experimenting with it on the desktop feels "right" for me. Good luck, I can see this going a long way.