newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(01-02-2018 06:36 AM)BarryMead Wrote:  Claudio: I was curious how/where you installed your qt-project.org download file.
My guess is that in your case you installed it as root user and selected the nonstandard
install locations of /usr/local/Qt/ rather than /opt/Qt/... which is the default location if installed in root mode. I installed my copy in non-root (user) mode so it put the files under $HOME/Qt/...

From the directions you mentioned regarding the GDB debugger location it did not match my system. There was no executable gdb file installed by the qt-project run file. The only executable gdb on my system is /usr/bin/gdb

The installer installed NOTHING in /usr/local/bin . I only mention this because GDB instructions on the wiki still confuse me. Thanks again for all of your patience and help. You were right I was looking for any excuse to NOT GIVE UP. I want to apologize to the forum members if I sounded too negative. After scratching my head for 40+ hours I was a bit frustrated and didn't know where else to turn for help/answers. Thanks for bearing with me through that!

Forget what I said, you are right of course. It installs in /opt, I got confused with my freeBSD test, that one goes to /usr/local
In any case, I was 100% sure it wasn't going to wreck your system.
Regarding gdb, there's normally one preinstalled (I might've confused the folders with BSD again) but doesn't support the python extensions that QtCreator needs, so debugging doesn't quite work until you install a better version. But as long as you don't try to step inside newRPL code you don't need it.

Now all that's left is for you to plug that calc and report any problems you find with the remote control, feature requests, etc.

[Claudio L.]

(01-02-2018 10:46 AM)TheKaneB Wrote:  Good job BarryMead! That's what I call persistence

@Claudio: do you think it's feasible to make some sort of automatic environment setup? I was thinking about some Vagrant script, or maybe just a plain preconfigured VM or some sort of package with all the configuration scripts and required libraries to be installed in one shot?

I'm not asking you to do so, just asking if you see any major obstacle, and maybe provide a bit of help to anyone who's willing to make such package.

Cheers!

It's perfectly doable, but every 6 months a new distro gets released and you'll have to play catch up forever. It becomes another project to maintain.

[TheKaneB]

well, it depends on your needs about the VM. When I worked on videogames (the toolchains are practically identical to those of the embedded platforms) I used to lock myself into a specific set of libraries and tools and I wouldn't upgrade anything unless it was specifically needed for a toolchain update (which would mean once every 2-3 years).

I have a similar approach now, even if I've switched to web/mobile, but of course I use LTS distros and I only install security patches, so all my VMs last at least 2 years.

If you treat your VM just as a build machine, you won't need to upgrade as often as your main workstation.

[Gilles59]

Hello.

I noticed that (ver 1001) the SORT command dont work with Alpha

Ex {"a" "b" "r" "e" } SORT

[pier4r]

(01-02-2018 02:07 PM)TheKaneB Wrote:  If you treat your VM just as a build machine, you won't need to upgrade as often as your main workstation.

It depends on what the user has though. Sometimes the distro just decides to change stuff around.

So for example you may develop for service (init.d) scripts, and then you get the distro that goes for systemd and your scripts are mostly misplaced.

Or ifconfig/route vs iproute2 and so on.

I guess it can be done but with a banner like "done with OS Y, if your want to port it to the next OS, be welcome to try and contribute".

[TheKaneB]

(01-02-2018 04:54 PM)pier4r Wrote:  

(01-02-2018 02:07 PM)TheKaneB Wrote:  If you treat your VM just as a build machine, you won't need to upgrade as often as your main workstation.

It depends on what the user has though. Sometimes the distro just decides to change stuff around.

So for example you may develop for service (init.d) scripts, and then you get the distro that goes for systemd and your scripts are mostly misplaced.

Or ifconfig/route vs iproute2 and so on.

I guess it can be done but with a banner like "done with OS Y, if your want to port it to the next OS, be welcome to try and contribute".

True, that's why I prefer to stick to Windows for my main development machine, since it has a much longer support and less chaos for those kind of things. Now that I develop web stuff it doesn't matter too much, but back in my ASM / C / C++ days it was a pain to migrate from one machine to another, adding to the pain you already described with Linux distros changing major stuff and breaking software.

[pier4r]

(01-02-2018 06:35 PM)TheKaneB Wrote:  True, that's why I prefer to stick to Windows for my main development machine, since it has a much longer support and less chaos for those kind of things. Now that I develop web stuff it doesn't matter too much, but back in my ASM / C / C++ days it was a pain to migrate from one machine to another, adding to the pain you already described with Linux distros changing major stuff and breaking software.

Yes that is the good/bad side of Linux distros, they are open so they may change little but crucial bits that may disrupt the work of the others, because they just can. If the user is complaining around: "dear user, do your Linux".

Of course other people have recognized this as well and indeed there are distributions that are more enterprise oriented, like REHL (and Centos as byproduct).

Now that I think about, I imagine that when they install a supercomputer (see top500.org) with a custom linux, they likely will hire someone to keep bugfixing the OS without major updates. So the cost of a supercomputer is likely not only the megawatts of electricity and the sysadmin team to keep things configured. I never considered that until now.

[Claudio L.]

(01-02-2018 03:48 PM)Gilles59 Wrote:  Hello.

I noticed that (ver 1001) the SORT command dont work with Alpha

Ex {"a" "b" "r" "e" } SORT

True. Comparison is not defined for strings (yet?), mainly because I'm not sure there's any meaning in the unicode character number anymore, so what's a proper text comparison? I'm not saying it can't be done properly, in fact almost every OS has to sort files with weird characters, it's just I never researched the topic enough to implement it, and other things took priority in the calculator.

Now that's no excuse for the dirty stack after the error, you have the right to a tidy stack on error. I'm fixing that right now.

PS: Here's a link for the curious http://unicode.org/reports/tr10

[TheKaneB]

(01-02-2018 06:58 PM)pier4r Wrote:  

(01-02-2018 06:35 PM)TheKaneB Wrote:  True, that's why I prefer to stick to Windows for my main development machine, since it has a much longer support and less chaos for those kind of things. Now that I develop web stuff it doesn't matter too much, but back in my ASM / C / C++ days it was a pain to migrate from one machine to another, adding to the pain you already described with Linux distros changing major stuff and breaking software.

Yes that is the good/bad side of Linux distros, they are open so they may change little but crucial bits that may disrupt the work of the others, because they just can. If the user is complaining around: "dear user, do your Linux".

Of course other people have recognized this as well and indeed there are distributions that are more enterprise oriented, like REHL (and Centos as byproduct).

Now that I think about, I imagine that when they install a supercomputer (see top500.org) with a custom linux, they likely will hire someone to keep bugfixing the OS without major updates. So the cost of a supercomputer is likely not only the megawatts of electricity and the sysadmin team to keep things configured. I never considered that until now.

I don't know about others, but if I had the responsibility of running a top500 superbeast, I would probably throw a couple hundred thousands dollars at Red Hat to "buy" a few of their engineers full time to take care of the thing

[Claudio L.]

(01-02-2018 02:07 PM)TheKaneB Wrote:  well, it depends on your needs about the VM. When I worked on videogames (the toolchains are practically identical to those of the embedded platforms) I used to lock myself into a specific set of libraries and tools and I wouldn't upgrade anything unless it was specifically needed for a toolchain update (which would mean once every 2-3 years).

I have a similar approach now, even if I've switched to web/mobile, but of course I use LTS distros and I only install security patches, so all my VMs last at least 2 years.

If you treat your VM just as a build machine, you won't need to upgrade as often as your main workstation.

That's ideal and I do that myself for development too. I actually moved my main development to Linux LTS because of Windows 10 forced updates. That works for development but not so much for distribution, it forces you to ship every dependency with your final product. On a videogame, it doesn't matter since it's a large size product anyway, but on a small package it's a lot of bloating.
I started researching some package managers to do just that, but it's quite cumbersome and pulls a lot of dependencies. Maintaining a package (deb , rpm, etc.) would force to rebuild against whatever versions are going to be included on every distro out there. It's fine if the distribution takes care of pulling, updating and building your package, but in the meanwhile, I'd be building packages for every distro, which is way too much effort.

So the only real solution I found is to have people build from source in the easiest possible way, on as many systems as possible, but it's far from ideal.

[TheKaneB]

Yep, I understand your point. It's not only your project that suffers this kind of situation, I've seen so many small projects with the same troubles. The devops aspect start becoming a big factor when you take into account every major distro out there.

It would be much easier to support only one specific OS and that's it (ie: let's say the latest Ubuntu LTS). That way if you want a quick setup just follow the supported path, otherwise build from source and good luck. Food for thought

[BarryMead]

Anyone: I was experimenting with SDSTO and SDRCL on the calculator with an sdcard installed. I was also experimenting with saving and loading of SaveAs and Open on the emulator. The emulator saves files in an .nrpb format, which is not compatible with the SDRCL of the calculator. If you put one of these .nrpb files onto an sdcard
and try to read it with SDRCL it does not work. I was wondering if there is any way
to EMULATE an sdcard on the emulator so that SDSTO and SDRCL will save and restore files to the emulator that were SDSTOed by the calculator or visa versa. On the emulator if you try to use SDSTO or SDRCL it just says "No SDCARD installed". With a giant hard disk out there just waiting to be used by the emulator this error seems unnecessary. I know that whatever you have on one
either the emulator or calculator you can transfer to the other with USBARCHIVE and USBRESTORE, and I have already used these with great success. Also I was able to grab text programs, put them on an sdcard and open them in the calculator using this program:
«
SDOPENRD
DUP
DUP
SDFILESIZE
SWAP
SDREADTEXT
STR→
SWAP
SDCLOSE
» 'TREAD' STO
Then just put the name of the text file in double quotes on the stack and execute TREAD

I was also able to use the clipboard to cut/paste text into the stack then use STR→ to convert it to a proper program on the emulator. But I was thinking that if the emulator used the current working directory to simulate the sdcard that would make many of the other SD operations more useful. Right now all SD operations just error out with "No SD card installed" on the emulator. This seems a shame since there is plenty of hard drive space available to act like the sdcard. Alterntively, a menu option could allow the user to pick any directory on the computer to act as the SDCARD.
Any thoughts, comments or better ideas are welcome.

[Claudio L.]

(01-03-2018 12:31 AM)BarryMead Wrote:  Anyone: I was experimenting with SDSTO and SDRCL on the calculator with an sdcard installed. I was also experimenting with saving and loading of SaveAs and Open on the emulator. The emulator saves files in an .nrpb format, which is not compatible with the SDRCL of the calculator. If you put one of these .nrpb files onto an sdcard
and try to read it with SDRCL it does not work.

There's 2 file formats: .nrpl is for RPL objects, and .nrpb is for backup files. Backup files are more than objects, they have the entire directory structure, settings, flags, and are generated by xxARCHIVE/xxRESTORE (here xx=either SD or USB). The New/Open/Save options in the File menu work on entire calculators and use backup files, 100% compatible with xxARCHIVE. For individual objects the menu Stack can "Open file to level 1" and "Save level 1 as..." which uses files .nrpl fully compatible with SDSTO/SDRCL.

(01-03-2018 12:31 AM)BarryMead Wrote:  I was wondering if there is any way
to EMULATE an sdcard on the emulator so that SDSTO and SDRCL will save and restore files to the emulator that were SDSTOed by the calculator or visa versa. On the emulator if you try to use SDSTO or SDRCL it just says "No SDCARD installed". With a giant hard disk out there just waiting to be used by the emulator this error seems unnecessary.

The menu Hardware has the option to insert an SD card image. The image is exactly that: the image of a FAT formatted filesystem. You can easily get one from a real SD card, using the 'dd' command (on Linux that is, just clarifying for other people).

Code:

dd if=/dev/sdX of=~/myfile.img bs=1MB status=progress

where /dev/sdX has to be replaced with the device of your real SD card.

The image file has to be inserted/ejected from the simulator just like an SD card in the real calculator.

(01-03-2018 12:31 AM)BarryMead Wrote:  I know that whatever you have on one
either the emulator or calculator you can transfer to the other with USBARCHIVE and USBRESTORE, and I have already used these with great success. Also I was able to grab text images of programs, put them on an sdcard and open them in the calculator using this program:

«
SDOPENRD
DUP
DUP
SDFILESIZE
SWAP
SDREADTEXT
STR→
SWAP
SDCLOSE
» 'TREAD' STO
Then just put the name of the text file in double quotes on the stack and execute TREAD

I was also able to use the clipboard to cut/paste text into the stack then use STR→ to convert it to a proper program on the emulator. But I was thinking that if the emulator used the current working directory to simulate the sdcard that would make many of the other SD operations more useful. Right now all SD operations just error out with "No SD card installed" on the emulator. This seems a shame since there is plenty of hard drive space available to act like the sdcard. Alterntively, a menu option could allow the user to pick any directory on the computer to act as the SDCARD.
Any thoughts, comments or better ideas are welcome.

If you want to get files out of the image, just mount it in Linux and it magically becomes the directory you are requesting. On some desktops mounting an image is a couple of clicks, on others a matter of "mount -o loop ...".
[a side note for other people: on Windows I use a free program called OSFMount by Passmark to mount images]
Writing directly to a directory in the host would bypass the filesystem driver in newRPL, and defeats the purpose of debugging and testing it. This way it was more useful to me for development, and more realistic as far as the simulation. I agree from a final user perspective having to mount/unmount an image seems like an unnecessary chore.
EDIT: By the way, writing directly to a directory is exactly what those 2 options in the Stack menu do, they are actually SDSTO/SDRCL but directly to the host, in the same way that the "Remote USBARCHIVE..." and "Remote USBRESTORE..." are working directly on the host, bypassing the simulator entirely.

[mbarnes]

I was able to get newRPL working tonight using a new Ubuntu 16.04 installation running under VirtualBox.
When I followed the instructions correctly, I had no problems. A couple of observations and a question:

1. In the Wiki, in the 'Build from Source' section, under 'Building the Desktop Simulator', the first line
references 'newrpl-comp.pro' and it should be 'newrpl-ui.pro'.
2. When compiling the firmware, I ran into the classic 'sys/cdefs.h' not found problem. Installing
'libc6-dev-i386' solved this. You might add that to the Ubuntu dependencies. It is not needed unless building
firmware.

Question: I am using an HP 39gs as my newRPL platform. Under windows 10 I was eventually able to load the
firmware onto the calc. How do I now update it? The usual trick of 'reset button/+ - keys/3 seconds' doesn't work
and the Windows Calculator Connectivity Kit doesn't recognize the calculator with the new firmware.
What is the recommended method of updating 39gs firmware with a newer one? Thanks!

Mike

[BarryMead]

Claudio: Thanks for the info. I confirmed that everything I wanted to do works.
I fully understand why you wanted to emulate a fat16 sd image in the emulator.

I did notice some unexpected inconsistencies in the file suffix rules for various file operations.
Both SDSTO and SDRCL save files in nrpl format but do not append the .nrpl file suffix.

Both the "Stack->Open File to Level 1..." and "Stack->Save Level 1 as.." emulator menu actions save files to .nrpl format and add the .nrpl suffix

I was wondering why the "Calculator" omits the .nrpl suffix, while the emulator's equivalent direct to file operations add the .nrpl suffix?
When moving files from a simulated sdcard to a direct hard drive file you have to manually add the .nrpl suffix to be able to read them in the emulator.

To mount the 2gig.img file so I could directly read the image file created by the dd command, I used
sudo kpartx -a 2gig.img

Then after adding moving or exchanging files, I unmounted the directory and used:
sudo kpartx -d 2gig.img
to close out the loop device so future kpartx commands will be able to work.

[Claudio L.]

(01-03-2018 09:01 AM)BarryMead Wrote:  Claudio: Thanks for the info. I confirmed that everything I wanted to do works.
I fully understand why you wanted to emulate a fat16 sd image in the emulator.

I did notice some unexpected inconsistencies in the file suffix rules for various file operations.
Both SDSTO and SDRCL save files in nrpl format but do not append the .nrpl file suffix.

Both the "Stack->Open File to Level 1..." and "Stack->Save Level 1 as.." emulator menu actions save files to .nrpl format and add the .nrpl suffix

I was wondering why the "Calculator" omits the .nrpl suffix, while the emulator's equivalent direct to file operations add the .nrpl suffix?
When moving files from a simulated sdcard to a direct hard drive file you have to manually add the .nrpl suffix to be able to read them in the emulator.

There's no good reason for it, on a PC it is customary to add an extension to know what file type you are dealing with, in the calculator there's no need, and actually simplifies things to have the file name be exactly the same as the variable name you stored in your calculator.
For backup files, though, it is nice to distinguish them from normal objects, so you don't go crazy trying to SDRCL a backup file.

I'll add the (*.*) mask to the dialog boxes, and make the .nrpl suffix optional. Thanks for the feedback!

[Claudio L.]

Heads up! I updated the unofficial roms to build 1016 for all 3 targets (see first post).

I also added a section to the wiki to update your source tree and rebuild, for people building their own simulator/firmware.

I recommend updating to the latest ROM, since it has some bugfixes that should improve stability.

I also removed the requirement of the '.nrpl' and '.nrpb' extensions. I recommend the use at least for backup objects, but it's now entirely optional.

[BarryMead]

Claudio: Thanks for the quick update. I am so angry at myself. I plugged the USB cable into my 50G without first touching ground to remove the static from my body, and blew out the USB port on my 50G. I tried removing the batteries to force a cold start, and re-flashed the calculator from the newRPL flash card. I tried rebooting my Desktop computer, and also confirmed that the USB cable/port is still good by attaching my DM-15L.

I truly have a DEAD USB PORT on my 50G. I was having so much fun experimenting with newRPL and the link to the emulator.

I can still have fun with the emulator, and the calculator still works, but it just does
not link to the emulator anymore. (unless I find a good deal on another 50G).

[Claudio L.]

(01-03-2018 06:27 PM)BarryMead Wrote:  Claudio: Thanks for the quick update. I am so angry at myself. I plugged the USB cable into my 50G without first touching ground to remove the static from my body, and blew out the USB port on my 50G. I tried removing the batteries to force a cold start, and re-flashed the calculator from the newRPL flash card. I tried rebooting my Desktop computer, and also confirmed that the USB cable/port is still good by attaching my DM-15L.

I truly have a DEAD USB PORT on my 50G. I was having so much fun experimenting with newRPL and the link to the emulator.

I can still have fun with the emulator, and the calculator still works, but it just does
not link to the emulator anymore. (unless I find a good deal on another 50G).

Could it be dirt inside the socket shorting pins? One last desperate thing to try is to blow the socket with a duster just in case.

I feel your pain: I had a powered USB hub connected to a development board, the power supply of the hub failed and released 12V, which the hub promptly distributed into all my devices, fried most of them including my board.

An alternative for you would be to buy a 40gs and do a keyboard face transplant, you could even do an SD card socket transplant per a recent post.

[BarryMead]

(01-03-2018 07:22 PM)Claudio L. Wrote:  Could it be dirt inside the socket shorting pins? One last desperate thing to try is to blow the socket with a duster just in case.

I feel your pain: I had a powered USB hub connected to a development board, the power supply of the hub failed and released 12V, which the hub promptly distributed into all my devices, fried most of them including my board.

An alternative for you would be to buy a 40gs and do a keyboard face transplant, you could even do an SD card socket transplant per a recent post.

Claudio: I blew out the dust, and recompiled the new 1006 version for the emulator, and put the latest 1006 version of newrplfw.bin on the 2g flash card and reloaded the calculator too with the latest 1006 version. Then surprisingly the USB PORT on the 50G started working again. YEA!!!