[newRPL] interested in RPN mode?

[compsystems]

Hello
Are there dialog boxes to change flags that facilitate configuration changes?

For those who do not have an HP50G, compile the version for PC or Android.

Thanks

[jpcuzzourt]

(11-22-2019 01:04 PM)compsystems Wrote:  For those who do not have an HP50G, compile the version for PC or Android.

Thank you

I have previously compiled version 1299 for Linux. The manual says I can enter the source directory and issue a

Code:

git pull

to get the updated source. When I do so however, it says "Already up to date", so I don't think it is pulling the latest development code, but the latest release code.
I have version 1315 on my 39GS hardware, but can someone point me to how to update the source so I can recompile v 1315 on my laptop?
Thanks,
JP

[JoJo1973]

(11-22-2019 03:13 PM)jpcuzzourt Wrote:  I have previously compiled version 1299 for Linux. The manual says I can enter the source directory and issue a

Code:

git pull

to get the updated source. When I do so however, it says "Already up to date", so I don't think it is pulling the latest development code, but the latest release code.
I have version 1315 on my 39GS hardware, but can someone point me to how to update the source so I can recompile v 1315 on my laptop?
Thanks,
JP

I think we'll just have to wait for Claudio to upload the code. When this happens, I'll be interested in your comments about the reformatted compile howto page: I cleaned it up a bit and reformatted it, but could have made some mistake with paths or filenames.

I'd like also to know if you find it clear and comprehensible!

Thanks!

[Claudio L.]

(11-22-2019 03:13 PM)jpcuzzourt Wrote:  I have previously compiled version 1299 for Linux. The manual says I can enter the source directory and issue a

Code:

git pull

to get the updated source. When I do so however, it says "Already up to date", so I don't think it is pulling the latest development code, but the latest release code.
I have version 1315 on my 39GS hardware, but can someone point me to how to update the source so I can recompile v 1315 on my laptop?
Thanks,
JP

Usually these "unofficial" builds are not pushed to the Sourceforge repository until I'm sure of the stability and they undergo some more testing.
However, since you need it, I just did a push to sf for you. Go ahead and pull again.
Hopefully there's not too many bugs.

[jpcuzzourt]

(11-22-2019 10:11 PM)JoJo1973 Wrote:  I think we'll just have to wait for Claudio to upload the code. When this happens, I'll be interested in your comments about the reformatted compile howto page: I cleaned it up a bit and reformatted it, but could have made some mistake with paths or filenames.

I'd like also to know if you find it clear and comprehensible!

Thanks!

(11-22-2019 10:41 PM)Claudio L. Wrote:  Usually these "unofficial" builds are not pushed to the Sourceforge repository until I'm sure of the stability and they undergo some more testing.
However, since you need it, I just did a push to sf for you. Go ahead and pull again.
Hopefully there's not too many bugs.

Thanks Claudio. It built a fresh new 1315 desktop version for me.
And JoJo, I think these are the same instructions I followed for the first time about a week or two ago, and I found them clear and helpful.

JP

EDIT: One thing that seems still-broken for me is the USB interface between the 39GS and newRPL-ui (64-bit Linux). Under version 1315, my 39GS does not appear in the USB device list.
I have followed the instructions for setting up udev rules and the "usbdevices" group. And I see the 39GS in lsusb output. Any tips or ideas that I can try at this point to troubleshoot?

[Claudio L.]

(11-22-2019 11:19 PM)jpcuzzourt Wrote:  

(11-22-2019 10:11 PM)JoJo1973 Wrote:  I think we'll just have to wait for Claudio to upload the code. When this happens, I'll be interested in your comments about the reformatted compile howto page: I cleaned it up a bit and reformatted it, but could have made some mistake with paths or filenames.

I'd like also to know if you find it clear and comprehensible!

Thanks!

(11-22-2019 10:41 PM)Claudio L. Wrote:  Usually these "unofficial" builds are not pushed to the Sourceforge repository until I'm sure of the stability and they undergo some more testing.
However, since you need it, I just did a push to sf for you. Go ahead and pull again.
Hopefully there's not too many bugs.

Thanks Claudio. It built a fresh new 1315 desktop version for me.
And JoJo, I think these are the same instructions I followed for the first time about a week or two ago, and I found them clear and helpful.

JP

EDIT: One thing that seems still-broken for me is the USB interface between the 39GS and newRPL-ui (64-bit Linux). Under version 1315, my 39GS does not appear in the USB device list.
I have followed the instructions for setting up udev rules and the "usbdevices" group. And I see the 39GS in lsusb output. Any tips or ideas that I can try at this point to troubleshoot?

Did you follow the wiki on USB permissions for Linux? newRPL Desktop will not see the USB device unless the user it runs under has permission to read/write the USB device. If you did, make sure you spelled the group name consistently, on one of my machines I had created the group usbdevices, then added my user to usbdevice (no s). Took me a while to figure it out.
EDIT: Maybe it helps to note I'm using KUbuntu 19.04 on my main dev systems, 2 different setups and both work well, so if there's one build that's well tested is Linux 64-bit.

[jpcuzzourt]

(11-23-2019 06:09 PM)Claudio L. Wrote:  Did you follow the wiki on USB permissions for Linux? newRPL Desktop will not see the USB device unless the user it runs under has permission to read/write the USB device. If you did, make sure you spelled the group name consistently, on one of my machines I had created the group usbdevices, then added my user to usbdevice (no s). Took me a while to figure it out.
EDIT: Maybe it helps to note I'm using KUbuntu 19.04 on my main dev systems, 2 different setups and both work well, so if there's one build that's well tested is Linux 64-bit.

Code:

jpcuzzourt@mx:~
$ groups jpcuzzourt
jpcuzzourt : jpcuzzourt tty lp uucp dialout cdrom floppy sudo audio dip video plugdev users netdev lpadmin scanner vboxsf vboxusers usbdevices
jpcuzzourt@mx:~
$ cat /etc/udev/rules.d/50-HIDDevices.rules
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="usbdevices"
SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="03", MODE="0664", GROUP="usbdevices"
jpcuzzourt@mx:~
$ lsusb
Bus 004 Device 004: ID 03f0:231d HP, Inc Broadcom 2070 Bluetooth Combo
Bus 004 Device 003: ID 04f2:b230 Chicony Electronics Co., Ltd Integrated HP HD Webcam
Bus 004 Device 005: ID 03f0:0121 HP, Inc HP 39g+ [F2224A], 39gs [F2223A], 40gs [F2225A], 48gII [F2226A], 49g+ [F2228A], 50g [F2229A, NW240AA]
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 138a:003c Validity Sensors, Inc. VFS471 Fingerprint Reader
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ uname -a
Linux mx 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

I don't see anything wrong with my configuration, but I include it for you to verify in case I am missing something.
I believe this was working under v1299, that is, I could see and select select the device although I still got errors whenever I tried to do I/O. I should try reverting back and verifying this.*
Thanks.
JP

FINAL EDIT: You can skip all the edits below. It's just me figuring out how to go back to 1299 and confirm that it also did not see the USB devices.
I'll continue trying to figure out why.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
EDIT: *Can you tell me which commit corresponds to V1299? Sorry to be a bother, but I'm a git AND QT noob. I don't know where the VERSION number comes from. Is it autogenerated somehow in QT creator, or is it in one of the source files? I'm assuming I can use git to checkout the source corresponding to a particular commit and rebuild v1299 to see if there's a difference in USB behavior on my system. (The reason I'm uncertain where I saw this behavior previously, is that before compiling for linux, I had also used it under Windows 10 both natively and in Virtualbox, as well as under wine. And now my recollections are all jumbled, lol. Now that I can compile a 64-bit linux version, that is how I'd much prefer to use it.)
EDIT: OK, I see that it comes from "git rev-list --count HEAD", so piping it to |head -17 shows me that 17408 is the commit I want. I'll give it a go and see what happens.

EDIT: Results. It made no difference. I must've been mistaken about ever seeing my linux version recognize the USB device. I did verify that the v1315 firmware I compiled for the 39GS will talk to the Windows version of newRPL-UI (Win7 running on Virtualbox linux host). I should note that under that scenario, newRPL-ui reports a USB communications error right after it completes a USB archive restore to my 39GS. But the restore seems to work correctly. This could be a quirk of using VirtualBox. My virtual Win7 OS repeatably crashes when I use the same newRPL-UI to do a firmware update. The firmware update completes, and then crashes Windows 7. I am able to use conn3X on that same Win7 instance to download firmware without issue. The entire reason for that win7 virtual machine was to run conn3x because I couldn't get it to work on Win10 to initially install the firmware to my 39GS. The SDcard method, of course, is not available to me yet - I still need to find the right sdcard holder to install.)

So, while I have a usable enough system right now, ideally I need to figure out why my linux version of newRPL-ui does not see the USB hardware. I'll see what else I can figure out, unless you spot something wrong in my group/permissions setup in the code window above.

[jpcuzzourt]

Claudio:
TLDR: please see my question in bold below. (Sorry, I get wordy.)
So, I've been digging a little in my system, and it seems that another rule is taking precedence over the settings in /etc/udev/rules.d/50-HIDDevices.rules.
(It gets grabbed by a rule in 90-extraacl.rules that handles KERNEL=="ttyUSB[0-9]*" and changes the owner to me. I don't remember setting this up, but I think it may be related to my Arduino IDE setup.)
The result is that my GS39 connects as /dev/ttyUSB0, and I am the owner, but the group is "dialout" (Without that rule, the owner is root.)
My account is a member of group "dialout", so I think this should all be OK.
And newRPL-ui runs under my account. As far as I can tell, it should have RW access to /dev/ttyUSB0.

If all the above is true, there isn't really any need for the 50-HIDDevices.rules, correct?
note that I also tried changing the group on /dev/ttyUSB0 manually to "usbdevices" and it made no difference.

If I understand correctly, all that should matter is that newRPL-ui runs under an account ("jpcuzzourt") which has rw access to /dev/ttyUSB0.
Since jpcuzzourt is the owner of the device and rw access, my issue should not be permissions, correct?
(note that I've also run newRPL-ui as root to try to rule permissions out, and I get the same result.)
One more idea - is the problem that it gets attached as /dev/ttyUSB, i.e. maybe it isn't seen as hidraw?

Code:

$ cat /etc/udev/rules.d/90-extraacl.rules 

# Setting serial port rules

KERNEL=="ttyUSB[0-9]*", TAG+="udev-acl", TAG+="uaccess", OWNER="jpcuzzourt"
KERNEL=="ttyACM[0-9]*", TAG+="udev-acl", TAG+="uaccess", OWNER="jpcuzzourt"
$ ls -la /dev/ttyU*
crw-rw----+ 1 jpcuzzourt dialout 188, 0 Nov 23 18:05 /dev/ttyUSB0

$ groups jpcuzzourt
jpcuzzourt : jpcuzzourt tty lp uucp dialout cdrom floppy sudo audio dip video plugdev users netdev lpadmin scanner vboxsf vboxusers usbdevices

Here is dmesg for the device:

Code:

[15218.511361] usb 4-1.2: new full-speed USB device number 20 using ehci-pci
[15218.629105] usb 4-1.2: New USB device found, idVendor=03f0, idProduct=0121, bcdDevice= 1.00
[15218.629113] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[15218.629117] usb 4-1.2: Product: newRPL Calc
[15218.629120] usb 4-1.2: Manufacturer: newRPL Team
[15218.629123] usb 4-1.2: SerialNumber: CNA0300410
[15218.629794] usb_serial_simple 4-1.2:1.0: hp4x converter detected
[15218.629974] usb 4-1.2: hp4x converter now attached to ttyUSB0

[Claudio L.]

(11-23-2019 07:51 PM)jpcuzzourt Wrote:  So, while I have a usable enough system right now, ideally I need to figure out why my linux version of newRPL-ui does not see the USB hardware. I'll see what else I can figure out, unless you spot something wrong in my group/permissions setup in the code window above.

Do you see hidraw devices in /dev? Do they have the right permissions? Check just in case udev is not working for any reason, or perhaps it's not assigning the hidraw driver to the device. Are you using Ubuntu? in other distros the udev rules might go into different folders. Also other distros may not come with hidraw drivers by default.
Another thing: once you used a device with Virtual box, it assigns a virtual box driver to the device. It should still assign others but in other device of mine it made it stop working on the host forever, even after reboot, while vbox wasnt running at all. Use dmesg to see which drivers were assigned to the calc.

Yet another thing you can try is installing the libusb package. Normally it's not needed, the hidraw driver is used but if that fails newRPL desktop will try to use libusb.

[Claudio L.]

(11-23-2019 11:47 PM)jpcuzzourt Wrote:  Here is dmesg for the device:

Code:

[15218.511361] usb 4-1.2: new full-speed USB device number 20 using ehci-pci
[15218.629105] usb 4-1.2: New USB device found, idVendor=03f0, idProduct=0121, bcdDevice= 1.00
[15218.629113] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[15218.629117] usb 4-1.2: Product: newRPL Calc
[15218.629120] usb 4-1.2: Manufacturer: newRPL Team
[15218.629123] usb 4-1.2: SerialNumber: CNA0300410
[15218.629794] usb_serial_simple 4-1.2:1.0: hp4x converter detected
[15218.629974] usb 4-1.2: hp4x converter now attached to ttyUSB0

Aha... it's assigning the usb_serial_simple driver instead of hidraw. There must be a rule somewhere that tells udev to use this device as a serial. This is an HID device!
I don't know what hp4x converter is, perhaps you had installed some connectivity library for Linux?
Somehow you need to find where in your system there's a rule for HP calcs to load that serial driver. Simply comment that rule out and let the system try yo identify the device, it should see it as hid and load the standard hid driver plus hidraw.

[Claudio L.]

A little more google and hp4x Linux driver is the culprit. I don't know why it's being loaded on your system automatically, perhaps some old rule or other package installed a rule. You can try rmmod ho4x to unload it, then unplug and plug the calc. Use dmesg again to see if now it loaded the right driver.

[jpcuzzourt]

(11-24-2019 12:12 AM)Claudio L. Wrote:  A little more google and hp4x Linux driver is the culprit. I don't know why it's being loaded on your system automatically, perhaps some old rule or other package installed a rule. You can try rmmod ho4x to unload it, then unplug and plug the calc. Use dmesg again to see if now it loaded the right driver.

Thanks. Yes, I'm on this same path now. rmmod hp4x doesn't find it, but I'll keep digging. I had finally caught up enough to realize the problem is that it is getting assigned a serial driver somewhere. It's probably from some ftdi or other usb->serial converter driver that I've installed in the past.
It's more of a learning adventure than I wanted tonight, but I'll figure it out. Thank you so much for looking. At least I can quit chasing permissions.
JP

EDIT: rmmod usb_serial_simple does it. Now it works. I just have to find out how to blacklist it for this device I guess.
Edit: Even after a reboot, the usb_serial_simple driver no longer attaches and newRPL-ui works fine*. I did not expect the fix to survive a reboot, but somehow it did. lsmod still shows the kernel module as being installed. but the calculator now attaches as /dev/hidraw0 as expected. In any case, thank you for the help Claudio. I'm pretty sure this module, usb_serial_simple, was compiled into the kernel for this linux, rather than being anything I installed intentionally. It supports a long list of USB devices, including the so-called HP 4x calculators. I'm running the latest mx Linux, which is derived from Debian.
*I do still get a "USB Communication Error" popup after restoring an archive over USB, though the restore seems to work. Is there an error log file generated anywhere? I did a cursory search for one and didn't find any.

[ijabbott]

(11-24-2019 12:12 AM)Claudio L. Wrote:  A little more google and hp4x Linux driver is the culprit. I don't know why it's being loaded on your system automatically, perhaps some old rule or other package installed a rule. You can try rmmod ho4x to unload it, then unplug and plug the calc. Use dmesg again to see if now it loaded the right driver.

The hp4x USB serial driver has been part of the Linux kernel sources since the 2.6.12 kernel (released 2005-06-17), initially as its own module, but got merged into the usb_serial_simple module in the 3.12 kernel (released 2013-11-03). The device tables in the respective modules match the USB VID and PID of the HP calculator, so the module will be loaded automatically when a matching device is detected if the module is installed as part of the distro's kernel packages. It's the usb_serial_simple module in this case.

If you rmmod the usb_serial_simple module, it will get loaded again automatically when you plug the device in. You could blacklist the usb_serial_simple module (see modprobe.d(5) for details), but that would also prevent the module being loaded for some other simple USB serial devices. It is the easiest fix though.

UDEV rules could be added to run a commands "unbind" the device from the hp4x driver and "bind" it to the desired driver (hid-generic, I think?).

It's way past my bedtime, and this is completely untested, but try adding a UDEV rule along the lines of this:

Code:


ACTION=="bind", SUBSYSTEMS=="usb", DRIVER=="hp4x", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="0121", \
RUN+="/bin/bash -c 'echo $kernel > /sys/bus/usb-serial/drivers/hp4x/unbind'", \
RUN+="/bin/bash -c 'echo $kernel > /sys/bus/hid/drivers/hid-generic/bind'"

You may need to play around with it a bit. It assumes the hid-generic module is already loaded. Note the serial driver is still registered as "hp4x" for this device, even though it is now handled by the "usb_serial_simple" module.

[JoJo1973]

I've expanded and cleaned up the wiki article on Assembly-like instructions and also added a couple of example programs to show some of the possibilities of the instruction set.

Disclaimer: info on the page is based on the code publicly released by Claudio: there could be mistakes about my understanding of it, and more over the code is still in a flux.

YMMV!

[The Shadow]

Nicely done, JoJo! There was one example you gave that made me sit up and take notice, even as a diehard RPL user - GET'ting an element from a composite far up the stack. Handy!

[Claudio L.]

(11-28-2019 12:43 AM)JoJo1973 Wrote:  I've expanded and cleaned up the wiki article on Assembly-like instructions and also added a couple of example programs to show some of the possibilities of the instruction set.

Disclaimer: info on the page is based on the code publicly released by Claudio: there could be mistakes about my understanding of it, and more over the code is still in a flux.

YMMV!

Thanks! This is way better than what I wrote. I like the formatting, it makes everything more readable. I did notice a couple of minor things in the examples that don't work that way, but I'll correct them as soon as I have a few minutes. I like your examples with deeply intertwined RPL and assembly, it shows how everything works together.
Nice to see somebody with actual writing skills helping with the documentation!

[JoJo1973]

Thanks! I would have liked to add a third example about :LOOP but didn't come with an idea: I want to avoid usual factorial and Fibonacci examples...

[John Keith]

(11-28-2019 10:46 AM)JoJo1973 Wrote:  Thanks! I would have liked to add a third example about :LOOP but didn't come with an idea: I want to avoid usual factorial and Fibonacci examples...

Nothing wrong with common examples, makes it easy to compare with other programming languages and techniques.

[compsystems]

Something related
With the Reverse Polish Notation RPN engine, is it easy to create a third PN (postfix notation) mode?