newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(12-20-2017 03:56 PM)The Shadow Wrote:  Wow, you weren't kidding. I just tested the following program:

<< 1 1000 START RAND DROP END >>

At a precision of 32 digits, it runs in 0.38117 seconds. At 2000, it takes 1.74822 seconds - only 4.5 times longer. At 12 digits, it's 0.37186 seconds.

Meanwhile, on the stock 50g, it's 2.7328 seconds, though of course that was a different algorithm entirely.

Where are the seed numbers stored? They don't seem to be in .Settings.

They are internal global variables, not exposed to the user. The user can only change the seeds through the RDZ command as it's always been.
Regarding your timings, always remember that the first 300 ms it runs at 6 MHz, then jumps to 192 MHz, that's why at 2000 digits is only 4.5 times slower. When testing speed it's a good idea to plan for something that executes over 10 seconds or so, that way the influence of those first 300 ms vanishes.
If you run the 32 digit test twice in a row you'll see the second run takes next to nothing.

[The Shadow]

The undo feature appears not to be working?

[Claudio L.]

(12-20-2017 11:27 PM)The Shadow Wrote:  The undo feature appears not to be working?

Works fine here. I only had that happen once when debugging an error handler, if a program was interrupted with a breakpoint within an error handler and later killed, the stack protection stayed active and prevented the snapshots from being taken. On-A-C and Warmstart should take care of that.
Of course if you can reproduce it reliably, let me know so I can add some extra cleanups to prevent this from happening.

[BarryMead]

Claudio: I have owned an HP-50G for a couple of years now and never used it because I found that the user interface was (to me) non-intuitive and difficult to remember. I know that many people just love the 50G and will flame me for thinking this way, but it just wasn't a calculator that made me feel comfortable for everyday tasks. I finally took the intitiative of loading newRPL vers 1001 onto a 2G sdcard and gave it a try.

I must say that I already like my 50G better than I ever have. With newRPL things behave more intuitively, and discovery/experimentation seem more like fun instead of drudgery. Thanks Claudio (and to everyone else who contributed to this project) for allowing me to get more value out of my 50G investment.

[The Shadow]

(12-21-2017 02:51 PM)Claudio L. Wrote:  

(12-20-2017 11:27 PM)The Shadow Wrote:  The undo feature appears not to be working?

Works fine here. I only had that happen once when debugging an error handler, if a program was interrupted with a breakpoint within an error handler and later killed, the stack protection stayed active and prevented the snapshots from being taken. On-A-C and Warmstart should take care of that.

Warmstart did indeed fix it, but it started happening right after I booted up the ROM. It hasn't happened since, though.

[BarryMead]

I have a question about the "Desktop" windows version of newRPL. I downloaded the 1001 version and installed it on my Windows 7 partition, and it does indeed come up on the screen. I can type some numbers on the numpad and Enter, and operators like * + - /, but when I try to use the mouse to click on the graphical representation of the HP-50G keyboard next to the display window nothing happens. Is the (mouse/emulated keyboard) not implemented yet? Also if the only way to control the desktop calculator is through the keys on the pc keyboard, then is there a legend of what keys do what documented somewhere? Thanks for answering these questions. I did search through the wiki to see if I could find answers to these questions before posting. I also looked for a help button on the desktop newRPL program and found no built-in help system.
So please forgive me if this question has already been answered. I did try several methods to find the answer before asking. I also tried installing an older version of the emulator on my windows partition in case the latest
version had a new bug. Both versions of the emulator had the same problem of not responding to the mouse clicking on the graphical HP-50G buttons.

[BarryMead]

(12-21-2017 02:51 PM)Claudio L. Wrote:  Mac and Linux users have to build from sources but it's perfectly compatible.

I had no luck with the Win-32 pre-built version of newRPL-Desktop 1001, so I thought I might try to compile a version to run under Linux, since I use Linux as my default OS anyway.
So I grabbed the source with this command:
git clone https://git.code.sf.net/p/newrpl/sources newrpl-sources

I tried to follow the instructions for compiling the emulator shown here:
http://www.hpmuseum.org/forum/archive/in...-7250.html

The first part of the compile went just fine using the newrpl-comp.pro project file, but the second part using the newrpl-ui.pro produced some errors as some files related to the usbdriver were missing from the repository.
The error message that I got was:
/home/barry/newRPL/newrpl-sources/mainwindow.cpp:53: error: 'uint32_t' was not declared in this scope
This error was caused when trying to compile the following line in the mainwindow.cpp file:
extern "C" int usbreceivearchive(uint32_t *buffer,int bufsize);

My guess is that something related to the usbreceiverarchive is missing from the repository, or the instructions for compiling the usb portion of the emulator are missing from the instructions.
Since the usb stuff was just recently added it would make sense.

One could confirm/replicate the errors I got, by using git to grab a fresh copy of the repository on a Linux system, using qtcreator to compile the newrpl-comp.pro and newrpl-ui.pro projects for one's self.

[pier4r]

(12-23-2017 06:49 AM)BarryMead Wrote:  I have a question about the "Desktop" windows version of newRPL. I downloaded the 1001 version and installed it on my Windows 7 partition, and it does indeed come up on the screen. I can type some numbers on the numpad and Enter, and operators like * + - /, but when I try to use the mouse to click on the graphical representation of the HP-50G keyboard next to the display window nothing happens.

As far as I remember, they should not "click". I use the real pc keyboard (of which the mapping is not yet well documented but it is ok).

In practice you have the commands reachable by letter (for example pressing 'y' is like pressing '1/x' unless alpha is activated and then 'y' shows) Then you have the numbers that are like 1,2,3,4,5,6,7,8,9,0 on the keyboard. The dot is dot. Space is space. Enter is enter. *,-,+ should be equal on the keyboard (I do not remember correctly) while division is 'z'.

alpha, right and left shift should be shift, ctrl, tab or a combination of those.

Unfortunately the newrpl desktop version now does not run anymore on XP so I cannot test on my thinclient and I am lazy to open win10pro.

[Gilles59]

Hello,

With the simulator (w10), how to kill a program (infinite loop for exemple)? On the 50g I press the ON but on the simulator ? The ESC key dont work for this, the only way I found is to close the program.

Another question to Claudio : are you considering to expand the available memory on the simulator ? It would be fine ;D Perhaps this could be user define ?

[Claudio L.]

(12-23-2017 07:11 AM)BarryMead Wrote:  

(12-21-2017 02:51 PM)Claudio L. Wrote:  Mac and Linux users have to build from sources but it's perfectly compatible.

I had no luck with the Win-32 pre-built version of newRPL-Desktop 1001, so I thought I might try to compile a version to run under Linux, since I use Linux as my default OS anyway.
So I grabbed the source with this command:
git clone https://git.code.sf.net/p/newrpl/sources newrpl-sources

I tried to follow the instructions for compiling the emulator shown here:
http://www.hpmuseum.org/forum/archive/in...-7250.html

The first part of the compile went just fine using the newrpl-comp.pro project file, but the second part using the newrpl-ui.pro produced some errors as some files related to the usbdriver were missing from the repository.
The error message that I got was:
/home/barry/newRPL/newrpl-sources/mainwindow.cpp:53: error: 'uint32_t' was not declared in this scope
This error was caused when trying to compile the following line in the mainwindow.cpp file:
extern "C" int usbreceivearchive(uint32_t *buffer,int bufsize);

My guess is that something related to the usbreceiverarchive is missing from the repository, or the instructions for compiling the usb portion of the emulator are missing from the instructions.
Since the usb stuff was just recently added it would make sense.

One could confirm/replicate the errors I got, by using git to grab a fresh copy of the repository on a Linux system, using qtcreator to compile the newrpl-comp.pro and newrpl-ui.pro projects for one's self.

Ahhh, another thing to write on the Wiki: good build instructions!

uint32_t is defined in the standard types for each platform (stddef.h), it seems something on your platform is not ready to build, there's missing headers. Try installing the build-essentials package, on the command line:

sudo apt-get install build-essentials

If that doesn't fix it, try also installing the package libc6-dev:

sudo apt-get install libc6-dev

Also, to build elf2rom you need the package libelf-dev, and now also needs libudev-dev for USB support. Both packages must be installed to build on Linux.

The package names might differ slightly between distros (some use -devel instead of -dev), as well as the installation command, I used Ubuntu syntax on the examples just to put something.

When you get it to compile, you need to give the current user access to rawhid devices.
Take a look here. The answer marked with the green checkmark is the one I used: create a special group for rawhid devices, then just add my user to that group.

[Claudio L.]

(12-23-2017 05:06 PM)Gilles59 Wrote:  Hello,

With the simulator (w10), how to kill a program (infinite loop for exemple)? On the 50g I press the ON but on the simulator ? The ESC key dont work for this, the only way I found is to close the program.

Another question to Claudio : are you considering to expand the available memory on the simulator ? It would be fine ;D Perhaps this could be user define ?

Same as in the calc, to break out of a program you use On+A+C, on the PC you have to press ESC+A+C. Now ESC sometimes gets taken by Windows (very annoying) and stops working, so I also mapped the key Home to On, therefore Home+A+C should work.
Keep in mind the simulator doesn't respond well to single key touches while the exception handler is running (I have no clue why, everywhere else the keyboard works fine), so once you get the Cont/Exit/Warmstart/Reset options, just press and hold B (Exit) for a few seconds until it works, it should stop and show an error message "Aborting RPL engine".
The On key by itself is too dangerous, it is too easy to accidentally stop a calculation in the middle.

EDIT: Sorry, forgot your last question: If you type MEM on the simulator, you'll see more than 1.1 MB free. I defined relatively small because that way there's more GC's and it helps me debug, as it crashes a lot more!

[BarryMead]

(12-23-2017 11:26 PM)Claudio L. Wrote:  Ahhh, another thing to write on the Wiki: good build instructions!

uint32_t is defined in the standard types for each platform (stddef.h), it seems something on your platform is not ready to build, there's missing headers. Try installing the build-essentials package, on the command line:

sudo apt-get install build-essentials

If that doesn't fix it, try also installing the package libc6-dev:

sudo apt-get install libc6-dev

Also, to build elf2rom you need the package libelf-dev, and now also needs libudev-dev for USB support. Both packages must be installed to build on Linux.

The package names might differ slightly between distros (some use -devel instead of -dev), as well as the installation command, I used Ubuntu syntax on the examples just to put something.

When you get it to compile, you need to give the current user access to rawhid devices.
Take a look here. The answer marked with the green checkmark is the one I used: create a special group for rawhid devices, then just add my user to that group.

Claudio: All of the packages you mentioned are already installed on my Linux system. Can you think of any other dependencies that might have been overlooked?
Thanks for the help, Barry

[BarryMead]

Claudio: On my Ubuntu 16.04 Linux system, the header file that defines uint32_t is named "stdint.h". (On Windows systems it is called stddef.h) I tried adding #include <stdint.h> to the mainwindow.cpp file which fixed that particular bug, but a whole new batch of errors surfaced, so I assumed that adding the #include <stdint.h> was not the correct approach to solving the issue.

I realize that this project is in alpha, so I don't expect it to be polished, or bug free.
I made an earnest attempt to compile a native Linux version, but perhaps it just isn't meant to be.

Take Care, Barry

[Claudio L.]

(12-24-2017 12:43 AM)BarryMead Wrote:  Claudio: On my Ubuntu 16.04 Linux system, the header file that defines uint32_t is named "stdint.h". (On Windows systems it is called stddef.h) I tried adding #include <stdint.h> to the mainwindow.cpp file which fixed that particular bug, but a whole new batch of errors surfaced, so I assumed that adding the #include <stdint.h> was not the correct approach to solving the issue.

I realize that this project is in alpha, so I don't expect it to be polished, or bug free.
I made an earnest attempt to compile a native Linux version, but perhaps it just isn't meant to be.

Take Care, Barry

Sounds like you are giving up. Most of my work is done on Ubuntu, I build there all the time and never had that problem. Did you try installing those packages? All those types are supposed to be included already since mainwindow.cpp is a Qt C++ class and has all the standard Qt includes.
If not then add:
#include <cstdint>

instead of including stdint.h which is for plain C.

[BarryMead]

(12-24-2017 04:27 AM)Claudio L. Wrote:  

(12-24-2017 12:43 AM)BarryMead Wrote:  Claudio: On my Ubuntu 16.04 Linux system, the header file that defines uint32_t is named "stdint.h". (On Windows systems it is called stddef.h) I tried adding #include <stdint.h> to the mainwindow.cpp file which fixed that particular bug, but a whole new batch of errors surfaced, so I assumed that adding the #include <stdint.h> was not the correct approach to solving the issue.

I realize that this project is in alpha, so I don't expect it to be polished, or bug free.
I made an earnest attempt to compile a native Linux version, but perhaps it just isn't meant to be.

Take Care, Barry

Sounds like you are giving up. Most of my work is done on Ubuntu, I build there all the time and never had that problem. Did you try installing those packages? All those types are supposed to be included already since mainwindow.cpp is a Qt C++ class and has all the standard Qt includes.
If not then add:
#include <cstdint>

instead of including stdint.h which is for plain C.

I not only confirmed that all of those packages are installed using synaptic, but re-installed each of them to be sure. I also tried your #include <cstdint> suggestion
and that did not help either. There is obviously some dependency missing. I tried posting the error messages into generic google searches to see if any suggestions came up, but had no success. The errors are just too generic. I haven't exactly given up, but have simply run out of leads to follow. Unless you or someone else on the forum has some fresh ideas to try, I simply don't know to find what is missing.
Thanks for the suggestions, Merry Christmas, Barry

[BarryMead]

Claudio: When I added the #include <cstdint> line to mainwindow.cpp, the error
message changed to the following:

/usr/include/c++/5/bits/c++0x_warning.h:32: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
^

So I added "-std=c++11" to the end of the CXXFLAGS line in the Makefile and then the error message changed to:

/usr/include/qt4/QtCore/qthread.h:116: error: 'static void QThread::msleep(long unsigned int)' is protected
static void msleep(unsigned long);

I am not sure if I am getting any closer to a valid compile or just getting deeper into trouble.
^

[BarryMead]

Precompiled Linux Binary:

Claudio: Since you said that you have compiled the source to a working binary for Ubuntu, I was wondering if that binary file would work on my computer? I use 64-Bit Ubuntu 16.04. If that is the same as what you are using, then the binary file should work on my computer if I could get a copy. Just qualify the limitations of what the binary file is compiled for and add it to the sourceforge download page.

[Claudio L.]

(12-24-2017 06:16 PM)BarryMead Wrote:  Precompiled Linux Binary:

Claudio: Since you said that you have compiled the source to a working binary for Ubuntu, I was wondering if that binary file would work on my computer? I use 64-Bit Ubuntu 16.04. If that is the same as what you are using, then the binary file should work on my computer if I could get a copy. Just qualify the limitations of what the binary file is compiled for and add it to the sourceforge download page.

I actually used a 14.04 simply because I like to use the LTS versions so I don't have to erase and reinstall everything every year.
But don't despair, I'm downloading an Ubuntu 16.04, I'll setup a clean VM on VirtualBox and will put together step-by-step instructions from a clean system. I might take me a few days but it's in the best interest of the project to be easy to build. I use 3 different PCs to code: 2 are Linux and one Windows 10 where I generate the binaries to be published.
Last week I actually started looking into 'snap' packages and other similar tools to distribute newRPL on Linux as a standalone application, but that's months from becoming a reality.

Merry Christmas to you, I'll spend some time with my family now, but will be back!

[Claudio L.]

(12-24-2017 05:50 AM)BarryMead Wrote:  So I added "-std=c++11" to the end of the CXXFLAGS line in the Makefile and then the error message changed to:

Makefiles are auto-generated by qmake (part of the Qt build system), so you shouldn't have to touch anything. In both my Linux systems, that option is added by default, always included without me touching a thing.

Anyway: Bear with me, I'll fix anything that needs fixing and post step-by-step instructions.

[BarryMead]

(12-24-2017 07:25 PM)Claudio L. Wrote:  I actually used a 14.04 simply because I like to use the LTS versions so I don't have to erase and reinstall everything every year.
But don't despair, I'm downloading an Ubuntu 16.04, I'll setup a clean VM on VirtualBox and will put together step-by-step instructions from a clean system. I might take me a few days but it's in the best interest of the project to be easy to build. I use 3 different PCs to code: 2 are Linux and one Windows 10 where I generate the binaries to be published.
Last week I actually started looking into 'snap' packages and other similar tools to distribute newRPL on Linux as a standalone application, but that's months from becoming a reality.

Merry Christmas to you, I'll spend some time with my family now, but will be back!

Claudio: Enjoy a Merry Christmas with your family. I have a second computer with Ubutntu 14.04 installed on it, so I tried the compile instructions on that computer and it worked perfectly. I can confirm that the issue is related to the changes made to Ubuntu for the 16.04 LTS release. Thanks for the tip, Barry