Prime second attempt

[mgmander]

(03-14-2019 08:13 AM)pier4r Wrote:  

(03-14-2019 05:03 AM)mgmander Wrote:  and actually developed an entire source code control environment for it which mimicked the calculators directory structure using a database and stored raw, commented source text files on the SD card of the 50G, allowing for "compilation" to the calculator itself. This allowed me to keep large, commented and legibly formatted source code files on the calculator (but on the SD card) and work on it in the field.

That sounds super interesting. Could you share your work? Maybe on hpcalc.org ?

Hmm... what I may do in the next little while is post a video of me taking the 50G through the source environment to my YouTube channel, to see what people think? I posted about it a very long time ago, back in the days of the old HP Museum forums, even with screenshots I believe. At the time, there didn't seem to be any interest at all.

It has been a very long time since I last worked on it (in 2006 I believe) and while it was pretty much finished, I wasn't super happy with the efficiency of the code and had actually been intending to start from scratch, rewriting the whole thing to streamline it as much as possible. Back then, my mother was suffering through metastasized bone cancer and I stopped having time to work on the project. When she passed away in 2008, I somehow never picked it up again.

One thorny issue I remember running into was that when writing an edited file back out to the SD card, if the batteries in the calculator were weak, the power could fail during the write and then you'd lose your last edit. If I remember correctly, I trapped for a low battery warning before writing to SD, and if there was one, I believe the user had the option of pressing a key to suspend and switch off the calculator. You could then switch out the batteries and when the calc was restarted, it would resume the SD card write and continue seamlessly. If you knew the batteries weren't all that weak, I believe there was also the option to force it to continue without the shutdown, with a warning that if the batteries were to give out during the write, you would lose your edits and maybe even corrupt something. I tried to make it as robust as possible.

Here is an early description of its functions that I sent to a fellow HP enthusiast, long before it was finished, when I was still using my 49g+. I believe I was levering emacs from my source control environment, which I hadn't been yet when I wrote the description and, for example, if there was a compile error, it would actually open the code again and position emacs at the offending spot. Anyway, a video will likely be much more interesting, but here is that early description...

----------------------------------
I have created a UserRPL program called SEDIT (mostly UserRPL... a couple of SYSEVAL calls though) and some support routines that now implements "source code" editing from the SD card. In other words, if you take a program name and hit SEDIT (stands for "Source Edit") in my custom menu it does the following:

1) If the name exists in the current directory, it checks to make sure it is VTYPE 8 (a program). If not, it aborts with an error. Will probably change this behavior so if the variable is not a program, it simply launches the built-in editor (EDITB) and does a normal edit.

2) It then looks up that variable name in a "database" containing directories, program names and source code text that is stored in a subdirectory on the SD card. If the name exists, it pulls up the text string and starts the built-in editor. This text string can have custom formatting, comments etc. of course. Once the edit is finished, it saves the edited text string back out to the SD card, compiles the string into a program object and stores it back on the calculator. All this is surprisingly fast and seamless on the 49g+, even in UserRPL! It does support multiple same-name programs, as long as they are stored in different directories on the calc - more or less the same as on the 49g+.

3) If the name does not exist on the SD, it asks if you want to decompile the program from the calc and store it on the SD and also gives you the option of attaching a standard (user defined and customizable) header template comment block to the beginning of the program after the decompile. It then goes and edits like above.

4) If it is a new name (not on calc or SD) it creates a new blank program and prompts for the optional header comment block and edits as above.

5) If it is the first program that is being edited/created with SEDIT in a given directory, it also gives the option to initially decompile *all* programs in a directory to the SD card. I did this since I have a lot of code already that I'd like to add comments to - especially usage info in the initial comment header block. Not sure really how necessary this is though as it is easy enough to do it one by one as needed...

Anyway, now that the keyboard is working reliably (hurray for KEYTIME!), I don't mind editing programs with the 49g+ on the fly, but I do find more complex projects are very hard to keep track of, so I decided to implement this source code system. So far, it seems to be working quite well and with the 512Mb SD card I've got, I can save a lot of commented source code! I still need to have it gracefully handle compile errors when there are problems in the source code but it is close to being finished. I still need to implement rename and purge functions as well that simultaneously work on the original source and the program in the calc. Maybe store & recall functions to copy or move a program as well. Should all be fairly easy.
--------------------------------------------

The "to do" items in the last paragraph have all been implemented, IIRC. I just fired up the 50G for the first time in a long while (been using a SwissMicros DM42 lately), and played with the software a bit. I can see I had been working on some changes and there are a few new glitches that would take me a long time to figure out now, having been away from it for over 10 years, but I'll still do the video since it still mostly works. As far as making it available publicly, right now it seems to have some issues and there is no way I'll have time to familiarize myself with its inner workings again to fix it any time soon, sorry. It might have even been an update to emacs which broke something, but I honestly cannot remember now.

Anyway, maybe that explains a bit more for now...

EDIT: Apologies for the long off-topic post. Once I get my video done, I should announce it in the General Forums and not the Prime forum...