Threaded Mode | Linear Mode

The Shadow · 02-23-2017, 06:28 AM

Neat update! I look forward to playing with it.

In other news, I'm going to be pretty scarce for the next couple months due to personal stuff. I haven't lost interest in newRPL!

Francois Lanciault · 02-23-2017, 06:35 PM

(02-21-2017 11:18 PM)Claudio L. Wrote: Another update!

In this build:

* User flags are back! 128 user flags. The status area has 6 dots for flags 1 thru 6 (try setting/clearing flags and you'll see what I mean).

Thank you Claudio,

I like the way User flags are displayed in the status area. Even thought they are displayed as dots, you can figure out imediatly what flag is set or not because of the grey / black display and the fact they are aranged in two rows of three dots. Very clever!

Are the flags updated on the display as the program is running ? It was a nice feature of the 48G. I can't see them change with my program but probably newRPL is too fast; they are only 'ON' a fraction of a second and I can't see them. The refresh rate of the display might also be too slow!

BTW the typos in the prog/flags menu are still there for SF? and CF? (should be FS? and FC?)

François

Eric Rechlin · 02-23-2017, 09:07 PM

I'm trying to build the simulator, and I'm getting a bunch of errors about constants being undefined, such as CMD_ENDOFCODE and CMD_QSEMI and a number of others. Is it possible a header file is missing from the source on SourceForge?

Also, right now I'm trying to build using Qt Creator running on Windows. I see you have instructions for building under Linux/BSD with the use of Qt Creator; is there a way to build it on a command line only Linux/BSD system, without a GUI?

Claudio L. · (This post was last modified: 02-24-2017 03:22 AM by Claudio L..)

(02-23-2017 09:07 PM)Eric Rechlin Wrote: I'm trying to build the simulator, and I'm getting a bunch of errors about constants being undefined, such as CMD_ENDOFCODE and CMD_QSEMI and a number of others. Is it possible a header file is missing from the source on SourceForge?

Also, right now I'm trying to build using Qt Creator running on Windows. I see you have instructions for building under Linux/BSD with the use of Qt Creator; is there a way to build it on a command line only Linux/BSD system, without a GUI?

It's very strange, it should build without any problems. Perhaps something is wrong with your setup.
The build system uses some headers that are quite complex to perform 2 passes:
* First pass: All libraries are compiled with a constant called COMMANDS_ONLY_PASS defined. When this happens, libraries don't generate any code, simply extract and define those constants CMD_XXX from the command lists that are defined in the library.
* Second pass: When that constant COMMANDS_ONLY_PASS is not defined, the library actually compiles its code, includes RPL object references, etc.

This 2-pass system is automatically happening in the background when you include cmd-codes.h, which is included from newrpl.h, I don't know why it's not being included, or the macros are not working in your build setup. I tested with Mingw32 in Windows that comes bundled with Qt Creator and works flawlessly. Also with gcc in Ubuntu and tested with clang on FreeBSD.
If you can capture the entire build output to a file and email me perhaps I can identify the problem by comparing with mine (especially compiler flags).

Regarding building with command line only: Yes, it should be possible (I haven't really tried). All you have to do is run qmake (bundled with Qt) to generate the makefiles, then run make (in theory that should be all). For the tools you need to run 'make install' as well. After all, Qt Creator is just a front-end.

Claudio L. · 02-24-2017, 03:36 AM

(02-23-2017 06:35 PM)Francois Lanciault Wrote: Are the flags updated on the display as the program is running ? It was a nice feature of the 48G. I can't see them change with my program but probably newRPL is too fast; they are only 'ON' a fraction of a second and I can't see them. The refresh rate of the display might also be too slow!

(02-23-2017 06:35 PM)Francois Lanciault Wrote: No, screen is not updated during a program unless the program enters a keyboard loop for any reason (with 0 WAIT for example).

BTW the typos in the prog/flags menu are still there for SF? and CF? (should be FS? and FC?)

François

It seems I fixed those menus it in one repository and was never pushed to my other system (which I used to build the ROM), I'll have to rebuild and upload the ROM again.
Thanks for re-reporting it.

yoeljacobsen · 02-24-2017, 09:57 AM

In my calc 'DET' raises 'Invalid Opcode' for every matrix. Is it a bug or a problem in my setup?

Claudio L. · 02-24-2017, 02:22 PM

(02-24-2017 09:57 AM)yoeljacobsen Wrote: In my calc 'DET' raises 'Invalid Opcode' for every matrix. Is it a bug or a problem in my setup?

Not a problem at all, it's just it wasn't implemented yet.
You can find a list of implemented commands here.

yoeljacobsen · 02-24-2017, 03:02 PM

Thank you.

The error message could be more accurate.

for future enhancement..

Francois Lanciault · 02-27-2017, 03:56 AM

(02-24-2017 03:36 AM)Claudio L. Wrote: No, screen is not updated during a program unless the program enters a keyboard loop for any reason (with 0 WAIT for example).

It's ok for flag indicators. But will it be the same for graphics ? In standard RPL you can see your graphics primitive (lines, circles, etc) appear on screen as the program runs.

Also, speaking of "WAIT" can you explain the behaviour under newRPL (or point me to some documentation) . It seems to return a string containing the last key pressed. I don't recall it did that in standard RPL.

François

TheKaneB · 02-27-2017, 10:11 AM

Hi Claudio,

thank you for your help. I'll start fiddling around with the code as soon as I have some spare time Smile

Cheers!
Antonio

Claudio L. · 02-27-2017, 04:17 PM

(02-27-2017 03:56 AM)Francois Lanciault Wrote: It's ok for flag indicators. But will it be the same for graphics ? In standard RPL you can see your graphics primitive (lines, circles, etc) appear on screen as the program runs.

I'm still working out the details of how a newRPL program will interface with humans. You won't be able to draw to screen just like that. You'll draw to a PLOT object, which then you can render to various targets: PICT, a GROB, SVG file on SD card, etc.
In order to interact, there will be some sort of forms, probably defined by a main text file with tags that include objects in variables (we discussed this in another thread). For example, you could have the main text being just the tag of a variable containing a PLOT object. When the user activates the form, the PLOT will be displayed (with all bells and whistles, scroll, zoom, etc). A program can dynamically update that PLOT, when the program ends the form will update the display.
Instead of a program drawings to the screen and using FREEZE or similar commands, you'll create an application that creates graphics to be displayed in a form with which the user will interact. Since it will be event-driven, you'll have separate routines to react to the user input, updating graphics, etc.
I'm still putting together the concepts, as soon as it's implemented you'll see. I'm not planning to create anything complex, the idea is that it should be very simple for an application to to get input from the user, do calculations and issue a report containing text mixed with graphics.
The report will ideally be able to be exported in HTML format with all the graphics, so you can put it on an SD card and open it in a browser, or copy/paste into your favorite rich document editor.
And if you still decide to go the traditional way of just drawing, you'll draw to a PLOT file, and call a PLOT viewer at the end of your program.

(02-27-2017 03:56 AM)Francois Lanciault Wrote: Also, speaking of "WAIT" can you explain the behaviour under newRPL (or point me to some documentation) . It seems to return a string containing the last key pressed. I don't recall it did that in standard RPL.
François

It used to return a key code, very hard to remember. Now the key code is a string, which is much easier to visualize.
The string is identical in format as the ASNKEY command (discussed not long ago in this thread):
Format:
"KEY.SHIFT.MODIFIER"
KEY = "A thru Z, 0 thru 9, * - + . or UP/DN/LF/RT, BK for backspace, EN for enter
SHIFT = L, LH,R, RH,A, AH,OH,ALH,ARH (L=left shift, LH=left shift hold, A=Alpha, OH=On-hold). Notice that On can only be defined with a hold plane.
MODIFIER = D,U,P,R,L,T (D=key down, U=key released, P=pressed, R=repeat, L=long press, T=long repeat, no modifier means the standard P (pressed) event)

Examples:
"7.L" = Left-shift 7
"7.LH" = Left-shift-hold 7
"7..D" = Action executed on key-down event for unshifted key number 7
"7..U" = Action executed on key-up event

Han · (This post was last modified: 02-27-2017 04:37 PM by Han.)

Claudio L. Wrote:It used to return a key code, very hard to remember. Now the key code is a string, which is much easier to visualize.

This would break backward compatibility, and it seems it would also make it more difficult to use in a program. I agree the string makes it easier to visualize the keycodes, but it seems that in doing so we may have added an extra layer of complexity to parsing the keycodes from a programming standpoint. Having the string be of standard width would help, though (e.g. "7..D" should probably be "7. .D" or something similar so that users can always assume that the keycodes are always some fixed position within the string)

Francois Lanciault · 02-27-2017, 07:45 PM

(02-27-2017 04:17 PM)Claudio L. Wrote: I'm still working out the details of how a newRPL program will interface with humans. You won't be able to draw to screen just like that. You'll draw to a PLOT object, which then you can render to various targets: PICT, a GROB, SVG file on SD card, etc.

...

I'm still putting together the concepts, as soon as it's implemented you'll see. I'm not planning to create anything complex, the idea is that it should be very simple for an application to to get input from the user, do calculations and issue a report containing text mixed with graphics.
The report will ideally be able to be exported in HTML format with all the graphics, so you can put it on an SD card and open it in a browser, or copy/paste into your favorite rich document editor.
And if you still decide to go the traditional way of just drawing, you'll draw to a PLOT file, and call a PLOT viewer at the end of your program.

Sound interesting. I will wait for the first iteration before commenting further.

(02-27-2017 04:17 PM)Claudio L. Wrote: It used to return a key code, very hard to remember. Now the key code is a string, which is much easier to visualize.
The string is identical in format as the ASNKEY command (discussed not long ago in this thread):
Format:
"KEY.SHIFT.MODIFIER"
KEY = "A thru Z, 0 thru 9, * - + . or UP/DN/LF/RT, BK for backspace, EN for enter
SHIFT = L, LH,R, RH,A, AH,OH,ALH,ARH (L=left shift, LH=left shift hold, A=Alpha, OH=On-hold). Notice that On can only be defined with a hold plane.
MODIFIER = D,U,P,R,L,T (D=key down, U=key released, P=pressed, R=repeat, L=long press, T=long repeat, no modifier means the standard P (pressed) event)

Examples:
"7.L" = Left-shift 7
"7.LH" = Left-shift-hold 7
"7..D" = Action executed on key-down event for unshifted key number 7
"7..U" = Action executed on key-up event

Ok now it's a string instead of a keycode. I'm fine with that. However, I think now WAIT returns the string even if the argument was not 0 (like old RPL). I don't have my HP-50 with me so I can't verify. If it does always return a string, then it means the programmer has to discard the result when WAIT was used just to induce a delay in the program as before. Please confirm.

François

Claudio L. · 02-28-2017, 07:55 PM

(02-27-2017 04:37 PM)Han Wrote: This would break backward compatibility, and it seems it would also make it more difficult to use in a program. I agree the string makes it easier to visualize the keycodes, but it seems that in doing so we may have added an extra layer of complexity to parsing the keycodes from a programming standpoint. Having the string be of standard width would help, though (e.g. "7..D" should probably be "7. .D" or something similar so that users can always assume that the keycodes are always some fixed position within the string)

Did you ever need to parse the keycodes in numeric format before? I never had to, and especially considering keyboard will mostly be handled by the forms engine. As far as I can think of, all you'll need is to compare the string with another string to see if the key pressed is the key you expected, something like:

Code:

0 WAIT

CASE

DUP "3" SAME THEN ... END

DUP "7..D" SAME THEN ... END

...

Claudio L. · 02-28-2017, 08:17 PM

(02-27-2017 07:45 PM)Francois Lanciault Wrote: Ok now it's a string instead of a keycode. I'm fine with that. However, I think now WAIT returns the string even if the argument was not 0 (like old RPL). I don't have my HP-50 with me so I can't verify. If it does always return a string, then it means the programmer has to discard the result when WAIT was used just to induce a delay in the program as before. Please confirm.

François

... and that's not supposed to happen! A bad case of misplaced brackets allowed a bogus key string to be pushed. Thanks for reporting the bug, I'll push an update with this and the FC? menu fixes soon.

Han · 02-28-2017, 08:46 PM

(02-28-2017 07:55 PM)Claudio L. Wrote:
(02-27-2017 04:37 PM)Han Wrote: This would break backward compatibility, and it seems it would also make it more difficult to use in a program. I agree the string makes it easier to visualize the keycodes, but it seems that in doing so we may have added an extra layer of complexity to parsing the keycodes from a programming standpoint. Having the string be of standard width would help, though (e.g. "7..D" should probably be "7. .D" or something similar so that users can always assume that the keycodes are always some fixed position within the string)

Did you ever need to parse the keycodes in numeric format before? I never had to, and especially considering keyboard will mostly be handled by the forms engine. As far as I can think of, all you'll need is to compare the string with another string to see if the key pressed is the key you expected, something like:

Code:

0 WAIT CASE DUP "3" SAME THEN ... END DUP "7..D" SAME THEN ... END ...

That would work perfectly fine for a routine that checks each individual combination (lots of unnecessary tests in a general case). It was fairly common in the HP48 series to break up the testing based on the shift planes (and then the actual key). I vaguely recall that many parameterized outer loops had key handlers that broke up the cases based on the shifts. Testing by shift planes reduces the number of tests in the general-case and worst-case scenarios. It also helps organize the key definitions (by shift planes) better than a simple list that may or may not be organized.

Whatever your choice, I still think a fixed format where every character (or every two) represents some bit of information. Then users can choose to a single CASE block, or break it up into shift planes by using the fact that the keycodes are in a fixed format. My recommendation for codes (slight alteration of yours):

"XYYZ"

X = KEY = A-Z, 0-9, *, -, +, ., u (up), d (down), l (left), r (right), b (backspace), e (enter), s (space), o (on) -- please note upper vs lower case
YY = SHIFT = two characters; first is shift combination, second is hold or not hold (a = alpha, l = left shift, L = alpha left shift, r = right shift, R = alpha right shift, H = hold)
Z = MODS = keep as you already described

On-hold would be: "o H "
Right shift B would be: "Br "
Alpha B would be: "Ba "
Right shift (hold) B would be: "BrH "
Alpha right shift B would be: "BR "
Alpha right shift (hold) B released would be: "BRHU"

You can even reduce YY into a single character if you opt to have A for alpha hold, and then use \( \alpha \) and \( \beta \) for alpha left hold and alpha right hold respectively, and use O for on-hold --> "oO "

Lastly, I don't recommend using "." for both the key and for the separation of the codes even though it is not possible to confuse the two.

Vtile · (This post was last modified: 02-28-2017 10:55 PM by Vtile.)

One major or minor issue with the string based keycodes are the harware compatibility if someone at some point in the future is willing to port the newRPL to different HW, the named keys might not be there. It still will brake the UI of ported nRPL programs, but the row&column coding makes more sense (atleast as I see it now, but hmm..) in that regard.

Just thought I spoke out what did pop to my head.

**rprosperi** · 03-01-2017, 01:05 AM

Regarding the keycodes, I have 2 comments:

a. VTile's comment is a good one. Platform independence would certainly be easier using keyboard mapping by position, rather than what is printed on the labels.

b. In many cases, newRPL has deviated from compatibility with RPL, but in every case I recall, there was some real benefit from the deviation, which justifies doing so (at least IMHO, there are no doubt folks here that want it 100% compatible, but then what's the point?).

Maybe I'm not following the discussion properly and don't have the right context, but it seems to me that the rc.p key code system that has been used in RPL forever should be retained, as the proposed string-based scheme is new, different, has no advantages, and is not compatible. Keep in mind too, that even if a couple folks here have not ever needed to use the numeric standard in the past it does not mean that no one uses it.

Claudio - you stated that the old-style key codes are hard to remember; I have to disagree as the point is you don't have to remember them at all, they are self-documenting by declaring their location in the key code itself. And while which plane is 1, 2, 3, etc. is not always memorized, it's no harder than the alphabet soup proposed, which in any case is mnemonic for English only.

Change for some benefit makes sense, but with none (that I see), it seems compatibility should be favored.

Claudio L. · 03-01-2017, 04:05 AM

(02-28-2017 08:46 PM)Han Wrote: That would work perfectly fine for a routine that checks each individual combination (lots of unnecessary tests in a general case). It was fairly common in the HP48 series to break up the testing based on the shift planes (and then the actual key). I vaguely recall that many parameterized outer loops had key handlers that broke up the cases based on the shifts. Testing by shift planes reduces the number of tests in the general-case and worst-case scenarios. It also helps organize the key definitions (by shift planes) better than a simple list that may or may not be organized.

Whatever your choice, I still think a fixed format where every character (or every two) represents some bit of information. Then users can choose to a single CASE block, or break it up into shift planes by using the fact that the keycodes are in a fixed format. My recommendation for codes (slight alteration of yours):

"XYYZ"

X = KEY = A-Z, 0-9, *, -, +, ., u (up), d (down), l (left), r (right), b (backspace), e (enter), s (space), o (on) -- please note upper vs lower case
YY = SHIFT = two characters; first is shift combination, second is hold or not hold (a = alpha, l = left shift, L = alpha left shift, r = right shift, R = alpha right shift, H = hold)
Z = MODS = keep as you already described

On-hold would be: "o H "
Right shift B would be: "Br "
Alpha B would be: "Ba "
Right shift (hold) B would be: "BrH "
Alpha right shift B would be: "BR "
Alpha right shift (hold) B released would be: "BRHU"

You can even reduce YY into a single character if you opt to have A for alpha hold, and then use \( \alpha \) and \( \beta \) for alpha left hold and alpha right hold respectively, and use O for on-hold --> "oO "

Lastly, I don't recommend using "." for both the key and for the separation of the codes even though it is not possible to confuse the two.

This makes perfect sense if you want to break it up, to access characters in a fixed position you'd have to use SUB, and if you get a real number you have to use FP. My proposal uses the separator for a reason: works well with the new NTHTOKEN command:
Doing:
"." 1 NTHTOKEN --> Isolate the key
"." 2 NTHTOKEN --> Isolate the shift plane

I think it's simpler than using SUB to get the key value and plane. Not simpler than IP/FP though (hard to beat that).

(02-28-2017 10:54 PM)Vtile Wrote: One major or minor issue with the string based keycodes are the harware compatibility if someone at some point in the future is willing to port the newRPL to different HW, the named keys might not be there. It still will brake the UI of ported nRPL programs, but the row&column coding makes more sense (atleast as I see it now, but hmm..) in that regard.

Just thought I spoke out what did pop to my head.

Let's think of the not-so-distant future when newRPL is ported to the Prime, for example. Let's look for example at the ENTER key. On the 50g it's at row 10, column 5, while the Prime has it at row 6, column 5.
So you write your program that WAITs for the Enter key... then you'll have to release a Prime version and a 50g version just because of the keyboard mapping.
However, with the string designation "EN" is Enter on both machines, regardless of where the key is physically located. Calculator keyboards will change in layout, but they all have numbers, operators, shifts, Enter, Backspace. Which alternative is more portable?

It's true that some keys might vanish from one platform to another (right shift), some become the same key (like 7 and Q on the Prime) and some are completely new (Esc, View) but in general, it will be much easier to port an RPL program based on the string description of the key than on the row/column.

(03-01-2017 01:05 AM)rprosperi Wrote: Regarding the keycodes, I have 2 comments:

a. VTile's comment is a good one. Platform independence would certainly be easier using keyboard mapping by position, rather than what is printed on the labels.

Platform independence will never be achieved on a command like WAIT that deals with the hardware. The idea is to make it easier to port from one platform to the other one.
Independence can only be achieved if you map the keys on all new hardware to the same code that key had on the 50g keyboard. But then it won't mean row/column anymore so on the Prime you couldn't tell what's the Enter code unless you have a table printed in a book.

(03-01-2017 01:05 AM)rprosperi Wrote: b. In many cases, newRPL has deviated from compatibility with RPL, but in every case I recall, there was some real benefit from the deviation, which justifies doing so (at least IMHO, there are no doubt folks here that want it 100% compatible, but then what's the point?).

Maybe I'm not following the discussion properly and don't have the right context, but it seems to me that the rc.p key code system that has been used in RPL forever should be retained, as the proposed string-based scheme is new, different, has no advantages, and is not compatible. Keep in mind too, that even if a couple folks here have not ever needed to use the numeric standard in the past it does not mean that no one uses it.

You don't see any benefit, hence your conclusion is correct. It would also be my conclusion if I didn't see any benefit, but I do:
Let's say a typical routine that reads an integer number directly from the keyboard using WAIT. You'll be dealing with the numbers, Enter, Backspace, and perhaps cursors left and right.
Such a routine would've needed changes even porting from a 48 to a 50g due to different keyboard layout. However, all those keys can be found on almost any calculator, so that newRPL program would run unmodified on practically any hardware. With row/column it would need a different version for each keyboard.

(03-01-2017 01:05 AM)rprosperi Wrote: Claudio - you stated that the old-style key codes are hard to remember; I have to disagree as the point is you don't have to remember them at all, they are self-documenting by declaring their location in the key code itself. And while which plane is 1, 2, 3, etc. is not always memorized, it's no harder than the alphabet soup proposed, which in any case is mnemonic for English only.

Change for some benefit makes sense, but with none (that I see), it seems compatibility should be favored.

Do you still see no benefit?

Han · 03-01-2017, 04:14 AM

(03-01-2017 04:05 AM)Claudio L. Wrote: This makes perfect sense if you want to break it up, to access characters in a fixed position you'd have to use SUB, and if you get a real number you have to use FP. My proposal uses the separator for a reason: works well with the new NTHTOKEN command:
Doing:
"." 1 NTHTOKEN --> Isolate the key
"." 2 NTHTOKEN --> Isolate the shift plane

I think it's simpler than using SUB to get the key value and plane. Not simpler than IP/FP though (hard to beat that).

I wonder if perhaps we might benefit from an NTHCHAR command (assuming the three, single-character format I proposed). 1 NTHCHAR for the key, 2 NTHCHAR for the shift, and 3 NTHCHAR for the modifier. I think it would be fairly simple to code and (negligibly?) faster than NTHTOKEN and it keeps the return string to exactly 3 characters.