Threaded Mode | Linear Mode

**rprosperi** · 05-21-2014, 03:38 AM

In a thread in another area of the forums earlier today there was brief discussion about ontaining HP Programming Pad pages for an HP-65. The upshot there, to me, was that several (many?) people still use program pad sheets to develop and document RPN code. (brief parenthetical note: this was a bit of a relief as I was fairly sure I was the only one that stll used these...)

Anyhow, has anyone created a custom programming pad layout for writing RPL programs, and if so, could you share a copy?

Building non-trivial RPL programs always takes lots of stack juggling, and a structured format would help the design, debug and documentation efforts.

I've made prototypes of simple pad layouts in the past using Excel, which basically are just matrices with lots of columns for the items on the stack, but I'd really like to see other folks ideas of how to do this.

HP67 · 05-21-2014, 09:44 AM

I have been using stack diagrams and a text editor to do anything complicated (for me) in RPL. I cannot imagine a form would be very helpful. I don't know a good answer for this but I have been thinking somebody with the skills should be able to cook up an Emacs RPL mode that would at least help with formatting the code nicely. I believe there are several Windows-based tools that do that already. For me how the code looks helps or hinders understanding it. Maybe there is a way but the device seems to reformat the code more or less how it wants, and the useful newlines that I inserted to break up the logical statements disappear. For me this is one of the hardest parts of writing RPL and maintaining it on the device. So for stuff with a lot of stack-dancing I have been doing all the maintenance in a text editor and keying the diffs on the device manually.

I used to use forms a lot in the keypunch days but have not used any since. I can see where they would be useful in gathering thoughts, etc. when writing any significant code that has to be keyed in on a calculator keypad though.

**rprosperi** · 05-21-2014, 12:34 PM

(05-21-2014 09:44 AM)HP67 Wrote: I have been using stack diagrams and a text editor to do anything complicated (for me) in RPL. I cannot imagine a form would be very helpful. I don't know a good answer for this but I have been thinking somebody with the skills should be able to cook up an Emacs RPL mode that would at least help with formatting the code nicely. I believe there are several Windows-based tools that do that already. For me how the code looks helps or hinders understanding it. Maybe there is a way but the device seems to reformat the code more or less how it wants, and the useful newlines that I inserted to break up the logical statements disappear. For me this is one of the hardest parts of writing RPL and maintaining it on the device. So for stuff with a lot of stack-dancing I have been doing all the maintenance in a text editor and keying the diffs on the device manually.

I used to use forms a lot in the keypunch days but have not used any since. I can see where they would be useful in gathering thoughts, etc. when writing any significant code that has to be keyed in on a calculator keypad though.

There is an entire Emacs environment that actually runs on the 48GX (and later brethren). Have not used it myself as I fear I may be forced to drink the Kool-aid by the Emacs religious zealots. I still prefer TECO (which is what Emacs was written in, waaay back then). And yes, Windows versions do exist (which is truly amazing).

I share your frustration with the on-device editors re-arranging according to it's own ideas of structure, but I guess it's fair given the environment it's running in.

The pros suggest simply to "use the command line tools from HP to build, then test in the emulator" so that your source with comments/structure/etc are preserved (you see Ray, I do listen). But that seems too much like I'm at my job...

All the code on 48/49/50, etc. I do is really only for me, so I prefer to dabble on the machine itself with Jazz, MASD, etc. as it's much more fun. But as I delve deeper into SysRPL, it gets more frustrating so I may set up the on-PC dev environment to give it a try.

HP67 · 05-21-2014, 12:54 PM

(05-21-2014 12:34 PM)rprosperi Wrote: There is an entire Emacs environment that actually runs on the 48GX (and later brethren). Have not used it myself as I fear I may be forced to drink the Kool-aid by the Emacs religious zealots.

From the very little I read on it (no direct experience) I got the impression it just shared the name. There is no way I want to be using a real copy of Emacs on a device with no Alt or Ctrl keys.

(05-21-2014 12:34 PM)rprosperi Wrote: I still prefer TECO (which is what Emacs was written in, waaay back then).

As somebody who used Teco on a PDP-7 and a PDP-11 for a couple of weeks back in the day, I respectfully suggest- nay, I daresay demand! you stop pulling our leg Wink

There is nobody alive today who could prefer Teco even to Vi!

(05-21-2014 12:34 PM)rprosperi Wrote: And yes, Windows versions do exist (which is truly amazing).

Of Emacs or Teco? The former I'm aware of, the latter would border on insanity (and don't forget the disclaimer of liability, etc.)

(05-21-2014 12:34 PM)rprosperi Wrote: I share your frustration with the on-device editors re-arranging according to it's own ideas of structure, but I guess it's fair given the environment it's running in.

Agreed, but I haven't been able to figure out the heuristics the 48 or 50 use. I could accept it more if it just stripped all extra spaces and linefeeds. But it seems to have some weird way it decides to chop lines.

(05-21-2014 12:34 PM)rprosperi Wrote: The pros suggest simply to "use the command line tools from HP to build, then test in the emulator" so that your source with comments/structure/etc are preserved (you see Ray, I do listen).

I did get the alternate "HP Tools" working on a little UNIX box that is now my repo of HP code so that would be ok. But it still doesn't give us the editor the Windows tools have and it doesn't seem work with User RPL. Maybe the real "HP Tools" do.

I'm roughing it. I have x48 and tried it briefly and it's neat, but I haven't taken the time to learn it and see if it can do what I want, so I don't use it.

(05-21-2014 12:34 PM)rprosperi Wrote: But that seems too much like I'm at my job...

A full blown IDE for a calculator might have seemed out of place before the smartphone revolution but now I guess everybody's doing it.

(05-21-2014 12:34 PM)rprosperi Wrote: All the code on 48/49/50, etc. I do is really only for me, so I prefer to dabble on the machine itself with Jazz, MASD, etc. as it's much more fun. But as I delve deeper into SysRPL, it gets more frustrating so I may set up the on-PC dev environment to give it a try.

You're way ahead of me. I'm still trying to make sure I learn User RPL real well and then decide what to do next. You're right, working on the device is great. It is very nice not to be chained to a PC and to "code on the road." For developing big projects the command line tools on a PC with a good editor are certainly a lot easier. For fixing up stuff it's nice to know you can do anything you need to on the device.

But going back and forth between the 48 and 50 is a killer. It's so annoying to have to deal with all the keyboard and menu differences.

John R · 05-21-2014, 01:19 PM

To continue a tangent: emacs actually has a built-in calculator (M-x calc, or C-x * *) that is "very roughly based on the HP-28/48 series of calculators," according to the manual:

http://www.gnu.org/software/emacs/manual.../calc.html

I haven't ever really used it, but it's nice to know it's there. (And also nice to know that RPN is the default entry mode.)

Don Shepherd · 05-21-2014, 02:43 PM

Speaking of ancient editors, does anyone remember SED on the DEC-20? Ah, the good old days.

HP67 · 05-21-2014, 02:46 PM

I don't remember using it, but SED and AWK are still part of POSIX AFAIK and are included in all UNIX-like OS.

I used Emacs on a DEC 20 and made a few bucks formatting peoples' term papers.

**Katie Wasserman** · 05-21-2014, 03:28 PM

(05-21-2014 02:46 PM)HP67 Wrote: I don't remember using it, but SED and AWK are still part of POSIX AFAIK and are included in all UNIX-like OS.

I used Emacs on a DEC 20 and made a few bucks formatting peoples' term papers.

I started using Emacs on a DEC 20 in grad school in 1979, AWK too. Incredibly, I still use an Emacs clone (Epsilon in Windows) and AWK (GAWK, actually) every day, professionally. These are my primary tools to support the financial accounting system that I specialize in.

**Katie Wasserman** · 05-21-2014, 04:23 PM

Back to topic.....

Quote:Anyhow, has anyone created a custom programming pad layout for writing RPL programs, and if so, could you share a copy?

Building non-trivial RPL programs always takes lots of stack juggling, and a structured format would help the design, debug and documentation efforts.

I'd start with a FORTH-like stack diagram and description of each (hopefully) small RPL routine. Here's a good example.

Thomas Klemm · 05-21-2014, 05:23 PM

In an article I used this SYSRPL code with stack-diagrams:

Code:

::                     ; z

  C%>%%                ; x y

  2DUP                 ; x y x y

  DUP                  ; x y x y y

  %%*SWAP              ; x y y^2 x

  %%ABS                ; x y y^2 |x|

  DUP                  ; x y y^2 |x| |x|

  %%1+                 ; x y y^2 |x| |x|+1

  DUPDUP               ; x y y^2 |x| |x|+1 |x|+1 |x|+1

  %%*                  ; x y y^2 |x| |x|+1 (|x|+1)^2

  4PICK                ; x y y^2 |x| |x|+1 (|x|+1)^2 y^2

  %%+                  ; x y y^2 |x| |x|+1 (|x|+1)^2+y^2

  %%SQRT               ; x y y^2 |x| |x|+1 √((|x|+1)^2+y^2)

  %%+                  ; x y y^2 |x| √((|x|+1)^2+y^2)+(|x|+1)

  3PICKSWAP            ; x y y^2 |x| y^2 √((|x|+1)^2+y^2)+(|x|+1)

  %%/                  ; x y y^2 |x| Q

  OVER                 ; x y y^2 |x| Q |x|

  %%1                  ; x y y^2 |x| Q |x| 1

(…)

At least it helps me to understand the program.

Cheers
Thomas

HP67 · (This post was last modified: 05-21-2014 05:36 PM by HP67.)

Yes, that's more or less what I do in a text editor. I separate stuff with commas so I don't get into a doubt about whether a stream of characters is a formula, expression etc. And I generally have a phrase on a line rather than one operation. But that's the idea.

Like Katie said, it might be helpful to know what FORTH people do, only I don't think there is much heavy-duty math being done in FORTH and the main guy who did use it for that passed away a few years ago and they are still trying to get permission to publish his books.

Thinking about it a little more, I only ever used coding forms for languages that had to have stuff in various columns. Since RPL is free-form it mostly doesn't seem to benefit from a form, although writing it down and thinking about it often beats keying up a big piece of code that doesn't work and can't be made to work without going back to the drawing board.

Thomas Klemm · 05-21-2014, 05:37 PM

(05-21-2014 12:54 PM)HP67 Wrote: Agreed, but I haven't been able to figure out the heuristics the 48 or 50 use.

The program is saved in compiled form when you exit the editor. Thus all formatting is lost. When you open the program in the editor it gets de-compiled. From my understanding corresponding keywords are aligned.

Example:
\<< IF THEN FOR i NEXT ELSE END \>> will be displayed as:

Code:

\<<

  IF

  THEN

    FOR i

    NEXT

  ELSE

  END

\>>

Otherwise there are no line breaks.

Cheers
Thomas

HP67 · (This post was last modified: 05-21-2014 05:50 PM by HP67.)

I think you are right with respect to loop commands that have an implied structure. But if you have a bunch of computations and stack manipulations etc. then the lines get broken up in unhelpful ways. Exactly how that is done I can't tell. I do know my linefeeds are often not respected and lines that I code are broken up in strange ways.

Thomas Klemm · 05-21-2014, 06:49 PM

Could it be that there is a fixed length of 19 characters and lines are broken to not exceed that?
But in this case previous levels of indentations aren't respected. Thus we get what you call "broken up in unhelpful ways":

Code:

\<<

  IF + + +

  THEN + + + + + +

+ + + + + + + +

  ELSE + + + + + +

  END + + + + + + +

+ + + + + + + + +

+ + + + + + +

\>>

Otherwise your listing would be much longer. I guess it's kind of trade-off: the listing is still structured based on keywords but as short as possible.

HP67 · 05-21-2014, 06:58 PM

I'll have to look and see if there's a pattern based on the length in the 48 and 50. At first glance I have many lines that are longer than 19 chars. I think it may break up the first thing it can after it gets to 19 chars, though.

My gripe is not so much with the indentation since I never got caught up with the new-fangled structured programming stuff but just that meaningful phrases get chopped up and no longer make sense. I tend to put a logical thought on one line (and had ASSumed everyone else did likewise). When I save the program and look at it later it's not very recognizable.

Raymond Del Tondo · 05-21-2014, 09:03 PM

(05-21-2014 03:38 AM)rprosperi Wrote: In a thread in another area of the forums earlier today there was brief discussion about ontaining HP Programming Pad pages for an HP-65. The upshot there, to me, was that several (many?) people still use program pad sheets to develop and document RPN code. (brief parenthetical note: this was a bit of a relief as I was fairly sure I was the only one that stll used these...)

Anyhow, has anyone created a custom programming pad layout for writing RPL programs, and if so, could you share a copy?

Building non-trivial RPL programs always takes lots of stack juggling, and a structured format would help the design, debug and documentation efforts.

I've made prototypes of simple pad layouts in the past using Excel, which basically are just matrices with lots of columns for the items on the stack, but I'd really like to see other folks ideas of how to do this.

Hi,

may I add my ideas related to programming aids?

All you need for structured RPL programming on a PC is a text editor which supports monospaced fonts, the HP RPL cmd line tools, Emu48, and some keyboard shortcuts;-)

There are several ways to "structure" a source text. I usually use tabs, or certain amounts of spaces for certain structures.

In this thread there are listings, partly with comments and stack diagrams.

You can see from the listings that multispaced fonts are not very suitable for text source listings.
In post #19 is a link to the ifft source in a zipped text file. This can be viewed best with monopaced fonts. Recommended editors are (in increasing flexibility): NotePad(++), UltraEdit, or my favourite: TSE Pro 32.

There are some IDEs which also help creating structured RPL code. Debug2x/Dbugx come to mind. 2x: Outdated and buggy as hell, but a step. One of the disadvantages of Debug2x was that the editor control they used always changed and reformatted my (the user's) source text without asking, which is a no-go.
I don't know if Debug4x (the extremely improved Debug2x, by Bill Graves) still has this issue,
but this was one of the reasons why I even made my few 49g projects using some custom scripts and the cmd line tools.

DavidM · 05-21-2014, 10:29 PM

(05-21-2014 09:03 PM)Raymond Del Tondo Wrote: ...One of the disadvantages of Debug2x was that the editor control they used always changed and reformatted my (the user's) source text without asking, which is a no-go.
I don't know if Debug4x (the extremely improved Debug2x, by Bill Graves) still has this issue, but this was one of the reasons why I even made my few 49g projects using some custom scripts and the cmd line tools.

Debug4x does no re-formatting of source code. What it does do, and I find extremely helpful, is to highlight reserved words automatically. But your indentation, spacing, etc. are all left exactly as you type them.

Perhaps as a result of it originally being developed in Delphi (which I also use), there are some nice Delphi-like features as well. Things like ctrl-space activating auto-complete, ctrl-/ toggles commented lines, and ctrl-click (sometimes) jumping to symbol definitions are handy features that are familiar from that environment.

Combined with the excellent integration with EMU48 (a special version made for Debug4x), it's a difficult environment to beat for SysRPL/Saturn development. And though it's not quite as complete a solution for UserRPL, you can still use if for that purpose as well.

**rprosperi** · (This post was last modified: 05-21-2014 11:34 PM by rprosperi.)

(05-21-2014 12:54 PM)HP67 Wrote: As somebody who used Teco on a PDP-7 and a PDP-11 for a couple of weeks back in the day, I respectfully suggest- nay, I daresay demand! you stop pulling our leg There is nobody alive today who could prefer Teco even to Vi!

TECO was (is?) an incredibly powerful text 'editor' (not in the current sense of the word) and much that it offered still has not been bettered to this day. I learned it on PDP-11s working at the computer center in college, where I got to play with (ahem, archive) the DECUS tapes. The real forerunner of the Goodies disks, swap disks, etc.

But TECO was incredibly arcane and tedious. So no, I no longer use it, except for the occasional trip into the past; and yes there are windows compatible (it is command-line after all) versions. Google it; you'll be surprised how much there is. Favorite TECO game back then. Starting with some given text phrase, you had to predict what would happen if you entrered your name as a TECO command.

(05-21-2014 02:43 PM)Don Shepherd Wrote: Speaking of ancient editors, does anyone remember SED on the DEC-20? Ah, the good old days.

I think this was around on the DECUS tapes for RSTS/E (PDP-11 OS) and early Vax OS releases. Probably came from those Bell labs guys that were always doinf stuff on DEC hardware.

**rprosperi** · 05-21-2014, 11:23 PM

(05-21-2014 05:23 PM)Thomas Klemm Wrote: In an article I used this SYSRPL code with stack-diagrams:

Code:

:: ; z C%>%% ; x y 2DUP ; x y x y DUP ; x y x y y %%*SWAP ; x y y^2 x %%ABS ; x y y^2 |x| DUP ; x y y^2 |x| |x| %%1+ ; x y y^2 |x| |x|+1 DUPDUP ; x y y^2 |x| |x|+1 |x|+1 |x|+1 %%* ; x y y^2 |x| |x|+1 (|x|+1)^2 4PICK ; x y y^2 |x| |x|+1 (|x|+1)^2 y^2 %%+ ; x y y^2 |x| |x|+1 (|x|+1)^2+y^2 %%SQRT ; x y y^2 |x| |x|+1 √((|x|+1)^2+y^2) %%+ ; x y y^2 |x| √((|x|+1)^2+y^2)+(|x|+1) 3PICKSWAP ; x y y^2 |x| y^2 √((|x|+1)^2+y^2)+(|x|+1) %%/ ; x y y^2 |x| Q OVER ; x y y^2 |x| Q |x| %%1 ; x y y^2 |x| Q |x| 1 (…)
At least it helps me to understand the program.

Cheers
Thomas

Thanks Thomas, interesting style. And I'm sure you're damned happy to see such excellent comments when you come back to look at this code months (even hours!) later. I think I might have had the stack reversed (left-to-right vs. your right-to-left), so that the 'bottom' level is at the left side near the current commad, so you can always see the most immediate argument you are working with.

But I'm not critisizing, I'm just wondering out loud, and this is exactly why I asked - to get ideas from other folks tackling the same task.

**rprosperi** · (This post was last modified: 05-21-2014 11:46 PM by rprosperi.)

(05-21-2014 04:23 PM)Katie Wasserman Wrote: Back to topic.....

Quote:Anyhow, has anyone created a custom programming pad layout for writing RPL programs, and if so, could you share a copy?

Building non-trivial RPL programs always takes lots of stack juggling, and a structured format would help the design, debug and documentation efforts.

I'd start with a FORTH-like stack diagram and description of each (hopefully) small RPL routine. Here's a good example.

Thanks Katie. I had not thought of exploring what the Forth folk do. An obvious answer (now that you've answered for me...) I will have to give it a thorough read. Skimming very quickly just now revealed little news, but to be fair it needs a quiet long look to be sure.

Check Forth! Wish I had thought of that! (slaps forehead!)