newRPL - Updated to build 1510 [official build remains at 1487]
|
07-11-2023, 06:26 AM
Post: #281
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-11-2023 02:28 AM)Claudio L. Wrote: [quote='spiff72' pid='174546' dateline='1688996706'] The calculator front in general seems to have been sized correctly, so I'd have thought the true space available for the emulated calc display could be gleaned from that result? I dunno nuthin' about Android app design, though. |
|||
07-15-2023, 02:05 PM
Post: #282
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
Btw why is there no version of newRPL for Prime G2?
I'm not really complaining, I have a G1 in dire need of a new raison d'etre.... |
|||
07-15-2023, 02:30 PM
Post: #283
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-15-2023 02:05 PM)n3mmr Wrote: Btw why is there no version of newRPL for Prime G2? I asked the same earlier in thread - I think it's because the CPU is different and compatibility issues. That was my reason to find a nice G1 on eBay...so the G2 can live in stock form! |
|||
07-15-2023, 03:11 PM
Post: #284
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-15-2023 02:30 PM)spiff72 Wrote:(07-15-2023 02:05 PM)n3mmr Wrote: Btw why is there no version of newRPL for Prime G2? If I'm not mistaken it's more because the G2 integrates a protection system against the installation of other OS than the native OS for the "exam mode". |
|||
07-15-2023, 03:20 PM
Post: #285
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-15-2023 03:11 PM)Gilles Wrote:(07-15-2023 02:30 PM)spiff72 Wrote: I asked the same earlier in thread - I think it's because the CPU is different and compatibility issues. That was my reason to find a nice G1 on eBay...so the G2 can live in stock form! I tried searching for the answer but was unsuccessful. The search capability of this forum leave a bit to be desired. |
|||
07-15-2023, 04:02 PM
Post: #286
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-15-2023 03:20 PM)spiff72 Wrote:(07-15-2023 03:11 PM)Gilles Wrote: If I'm not mistaken it's more because the G2 integrates a protection system against the installation of other OS than the native OS for the "exam mode". Here you go Greetings, Massimo -+×÷ ↔ left is right and right is wrong |
|||
07-16-2023, 10:25 AM
Post: #287
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-15-2023 04:02 PM)Massimo Gnerucci Wrote:(07-15-2023 03:20 PM)spiff72 Wrote: I tried searching for the answer but was unsuccessful. The search capability of this forum leave a bit to be desired. That is the very best kind of reason! Is there some source of reliable info on the HW design of the HP Prime calcs, g1 as well as g2? |
|||
07-16-2023, 12:34 PM
Post: #288
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-16-2023 10:25 AM)n3mmr Wrote: Is there some source of reliable info on the HW design of the HP Prime calcs, g1 as well as g2? Suggest you post a question like this in the Prime sub-forum, it will likely be seen by lots more folks that (whom?) are more focused on the Prime. RPL and Prime have very few common fans.. some do exist for sure (cough... Joe Horn... cough) but generally not too many. --Bob Prosperi |
|||
07-22-2023, 10:55 PM
(This post was last modified: 08-13-2023 12:54 PM by Gilles.)
Post: #289
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
I spent some time tonight starting a ListExt library in newRPL.
For documentation and usage, see : https://www.hpcalc.org/details/7971 by David Mutter. It's a partial implementation for now. It's very fast because newRPL is very fast especially with the processing of lists. The rest will follow soon enough when I have time next week and will be integrated into a newRPL library with menu and on line help. Code: @================================================================ USAGE EXEMPLES : returns the list of numbers from 1 to 1000 not divisible by 7 : Code: 1000 LSEQ « 7 MOD » LFILT List of the 69 numbers <1000 with sum on digits is 11 : Code: 999 LSEQ « I→NL ΣLIST 11 == » LFILT random shuffle from a list Code: 49 LSEQ LSHUF Sum of the 200 first decimals of PI (HP50g : 0.029 sec USB powered / 0.246 sec on battery) Code: GETPREC 202 SETPREC Permute letters of a string Code: { "a" "b" "c" "d" } « ΣLIST » DOPERM List of numbers with all the 1,2,3,4,7 digits witch are primes Code: { 1 2 3 4 7 } « NL→I IF DUP ISPRIME? NOT THEN DROP END » DOPERM |
|||
07-23-2023, 11:54 AM
Post: #290
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-22-2023 10:55 PM)Gilles Wrote: I spent some time tonight starting a ListExt library in newRPL. This is great! I can recommend a few things: 1) You can use CRLIB to create a user library to publish. Wiki-How to create user libraries 2) If plain text is your preferred format, you can use PACKDIR to convert and entire directory to user readable and editable text. It can be copy/pasted into the calc, compiled and stored into a variable with STO so it's a simple way to distribute an entire folder tree. 3) You can make those comments permanent with @@ so users can compile while preserving the helpful comments in the code |
|||
07-23-2023, 06:00 PM
(This post was last modified: 07-29-2023 10:34 AM by Gilles.)
Post: #291
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-23-2023 11:54 AM)Claudio L. Wrote: This is great! I can recommend a few things: Thanks, I will try this with a complete LIB, help on line with long press (great idea!) etc.. PACKDIR is nice. I changed my previous post with the correct structur for drag & drop onto the PC version & HP50 EDIT : It's progressing well ;D I'll post v1 library soon. Finally I made some infidelities to ListExt. For example, stopping DOPERM or DOCOMB is done with a BREAK command ex : Code: { 1 3 5 7 9 } 3 « NL→I IF DUP ISPRIME? THEN BREAK ELSE DROP END » DOCOMB |
|||
07-29-2023, 08:01 PM
(This post was last modified: 07-29-2023 10:02 PM by Gilles.)
Post: #292
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
Hello, I have some questions about the CRLIB command:
1/ When the name of the command is long and truncated in the menu, it is useful to display the complete name of the command with the "help long press". It works like this for internal commands. But is it possible to do it in a library? 2/ It's great that auto-completion works with add-on libraries. Cheer! 3/ Is there a build 1497 ou 1510 for Windows ? I dont find them and I would like to use the FORUP and FORDN loops to avoid some tests. |
|||
07-29-2023, 10:33 PM
(This post was last modified: 07-29-2023 10:36 PM by Claudio L..)
Post: #293
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-29-2023 08:01 PM)Gilles Wrote: Hello, I have some questions about the CRLIB command: My apologies for not having complete documentation written on the wiki for CRLIB. The good news is I don't need to apologize for not supporting what you want to do because $VISIBLE is quite advanced. All you have to do is for any item you would normally have in the list, replace it with an inner list like this: // $VISIBLE HAS THE FOLLOWING FORMAT: // { { IDENT NARGS ALLOWINSYMB HELPTEXT } { IDENT NARGS ALLOWINSYMB HELPTEXT } ... This gives the compiler a lot of extra info about your commands. 'IDENT' is the command name obviously, NARGS is the number of arguments it expects on the stack, this is needed for the compiler to issue an error when you use the command within a symbolic like MYCOMMAND(x,y,z). ALLOWINSYMB is a true/false, whether you want to make your command exist as a function (it has to return something that is valid within a symbolic object, of course or it will cause errors when evaluating the expression). And last but not least is what you were looking for: HELPTEXT is a string in the same format as the help of the standard commands (a 3-line string where the first two lines are typically a description and the third one is a stack diagram. The stack diagram follows a weird syntax I came up with (could be better but...): Code:
For example: Code:
So it takes a real number <time> and returns any object (whatever came thru the wire) and an integer representing TRUE or FALSE. As for the description, you need to break the lines thinking of the 50g screen width, it won't break the lines for you. 2/ It's great that auto-completion works with add-on libraries. Cheer! (07-29-2023 08:01 PM)Gilles Wrote: 3/ Is there a build 1497 ou 1510 for Windows ? I dont find them and I would like to use the FORUP and FORDN loops to avoid some tests. I typically only do the Windows executables for the official builds, can't promise anything but I'll see if I have time and can move the official version forward, it's probably overdue anyway. |
|||
07-30-2023, 07:53 PM
(This post was last modified: 08-01-2023 11:58 PM by Gilles.)
Post: #294
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
Hi
I wonders what the sequence :: L2 TMENULST ; means in your exemples in the Wiki for the creation of menus with sub-menus. What is the difference with « L2 TMENULST » ? EDIT: My LstX library works fine, with menus, submenus and online help ;D I'll do some testing and write a short documentation before publishing. It's really very fast :O ;D. The installation comes down to the ATTACH command. Most of the commands mimic David Mutter's ListExt, so the documentation will be minimal. |
|||
08-03-2023, 02:56 PM
(This post was last modified: 08-13-2023 09:51 AM by Gilles.)
Post: #295
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
I wrote my first library for newRPL. LstX 1.0 (update v 1.01a) is a library that adds powerful list management commands to newRPL. It is an adaptation of David Mutter's excellent ListExt library which runs on HP49-50 in standard RPL. The library uses sub-menu and help (long press on the command). You can get plenty of help from the ListExt documentation to use LstX, but beware there are a few differences (DOCOM / DOPERM/ DOCOPE ).
Version 1.01, with new commands, no use of Flag (I use LIBSTO and LIBRCL instead), and speed improvments : Library code. Must be on level 1 and ATTACH (DETACH the lib first for update) Documentation and examples It's very fast. For example calculating the frequency of the first 1000 decimals of PI takes... 0.60 sec on my HP50g (0.54 sec with USB connection and... 0 sec with the PC version) Code: « GETPREC 1002 SETPREC Nota : KSORT is not implemented yet. newRPL crashes when I tried to sort embedded list like { { 2 "A"} {1 "B" } {3 "C"} } wich is correct in stock RPL (the sort is on the first item of sublists) |
|||
08-08-2023, 03:27 AM
Post: #296
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(07-30-2023 07:53 PM)Gilles Wrote: Hi L2 is simply the level 2 menu list (the example has menus L1, L2 and L3 here we are assuming you have the list of the L2 example stored in a variable named L2. TMENULST is the same as TMENU, it displays a temporary menu. The LST suffix stands for "last" meaning it will replace whatever menu the user pressed last. For example if you have your level 1 menu displayed on menu1 (the top one) and you use TMENULST in a menu handler routine, the user obviously activated menu 1 last since your handler is running so TMENULST will open your level 2 menu in the same menu1. You may want to keep your main menu always visible and always open submenus in menu2 for example. In that case you would use TMENUOTHR which does TMENU on the "other" menu meaning the one the user did not interact with. Remember that the user can always swap menus 1 and 2 at will, so it's not a good idea to hard code your memnus to be in menu1 or menu2. It's recommended that you use TMENULST and TMENUOTHR instead. The difference between using :: ; versus << >> is that the latter will be pushed to the stack as an object and then you need to do EVAL. The former is executed immediately and in place. When used as menu handlers, there is one additional difference: << >> programs will interrupt the command line editor while :: ; routines run in "transparent" mode, allowing you to remain in the editor. |
|||
08-08-2023, 09:36 AM
(This post was last modified: 08-13-2023 09:51 AM by Gilles.)
Post: #297
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
Thanks, i will change this in the 1.1 version with other things.
Here is an example of use in v1.0f ( note that i've update above in v1.01a): Solve the cryptaritm : send+more=money Code: « 0 0 0 0 0 0 0 0 → s e n d m o r y => { { 's-9' 'e-5' 'n-6' 'd-7' 'm-1' 'o-0' 'r-8' 'y-2' } } Time newRPL PC : 32 sec The solution is unique as you can see by removing the BREAK command. If you remark that it's obvious that m=1 the solution is provided in 6,3 sec on a PC : Code: « 1 0 0 0 0 0 0 0 → m s e n d o r y But then it also obvious that s equals 9 and so: Code: « 1 9 0 0 0 0 0 0 → m s e n d o r y Time newRPL PC : 0.1 sec / HP 50g & HP39gs : 18,5 sec (Update 1.1 with no USB connection, see Claudio post below) PS : The newRPL overlays for 50g et 39gs are great ! see the topic ;D |
|||
08-11-2023, 01:30 AM
Post: #298
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(08-08-2023 09:36 AM)Gilles Wrote: Time newRPL PC : 0.187 sec / HP 50g : 26 sec / HP39gs : 18 sec (?) Possible explanation for those timings: a) The 50g had weak batteries such that half way it switched to the slow clock b) The 50g was connected to the USB port. I'd have to look at the source code but I think I recall locking the clock at an intermediate speed when connected to the USB to keep the communications flowing. I might be wrong on this one, though. c) The 50g had its large memory very dirty and had to run an exhausting garbage collection in the middle of that run. Try running MEM immediately before on both calcs to force a GC before doing benchmarks. Other than that, it's impossible for the 39gs to be almost twice as fast when it's running the same code on the same hardware. |
|||
08-11-2023, 09:15 AM
Post: #299
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(08-11-2023 01:30 AM)Claudio L. Wrote: b) The 50g was connected to the USB port. I'd have to look at the source code but I think I recall locking the clock at an intermediate speed when connected to the USB to keep the communications flowing. I might be wrong on this one, though.. Hi Claudio, I'm early in my journey with newRPL and enjoying it hugely. Thank you for your wonderful creation. My 39gs, running build 1487, draws approx 110mA on USB power with no calculation running. Maybe this power level correlates with the higher clock speed as you mentioned? This is power from a laptop albeit with data transfer locked down by my employer's policy. (I'm only seeking to save battery life when at work and the power level is not a problem.) - Geoff |
|||
08-12-2023, 01:40 PM
(This post was last modified: 08-12-2023 01:41 PM by Claudio L..)
Post: #300
|
|||
|
|||
RE: newRPL - Updated to build 1510 [official build remains at 1487]
(08-11-2023 09:15 AM)Mr_F Wrote: Hi Claudio, The calculator typically (as in when not connected to USB) puts the CPU in idle state, and only wakes it up with interrupts. On normal use, interrupts can be sporadic, like a timer to blink the cursor, or the press of a key. When connected to USB, there's a packet being sent every 2 or 3 ms (can't recall) and it needs to be acknowledged, so it will keep the CPU in wake state much more. If you need to save battery from your laptop, I guess the solution is to run your calc disconnected and only connect it when you need to send/receive something. I rarely need to connect mine, merely when I processed a long list and don't want to do the data entry again in Excel. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 8 Guest(s)