Summing lists in directory structure

[brickviking]

This one's caused me to scratch my head a bit, to be honest. I wanted to total up the amount we've spent on groceries (so far), so I took each day's amounts and put them all into named lists, like this: { 234.56 12.98 3.99 } 'JUN25' STO

Each month gets its own folder, i.e. JAN FEB MAR, APR ... OCTOB NOV DECEM.

When I want to add up the individual lists, I simply recall them one at a time, hit + between each one after the second one, and use ΣLIST when I have the final big list. I created a very short program thus:

Code:

\<< + ΣLIST 'TOTAL' STO
\>>

and stored it in each month's folder (yes, I know it's inefficient to all get go). I then run that program in each folder.
I have a folder structure that looks something like this:

Code:


GROCERIES
  JAN
    TOTAL MONTOT JAN11 JAN25
  FEB
    TOTAL MONTOT FEB8 FEB22
  ...
  OCTOB
  NOV
  DECEM

Now I'm wondering how to add together all the TOTALs in each folder to give me a sum at the end? Or better still, how would I use a better program than the one I cobbled together from perusing the User's Guide's List section? I'm sure that if I could run a program in the GROCERIES folder iterating over each month, I could gather the relevant variables together, sum them all, and give myself a total (I did this manually by adding together all the TOTALs) using the program instead.

Let me know if you need any further details, as I may not have explained myself very well.

Cheers, brickviking

(Post 82)

[pier4r]

I do not have the 50g here. But one could with VARS (or TVARS) and TYPE check what is the type of a variable, then pick the subvariables (if the type is a folder) and recall them to add them.

It is mostly list processing.

Only problem. VARS/TVARS works from the directory they are called.

[pier4r]

Ok just to give you an idea. The following is a program that checks the size of the list in the current directory (that is, the directory in which the 50g is at the moment of the execution)

Code:


checkListLength
  @the more I put data in the lists, the less I can count how many objects are
  @stored. So having an automatism that counts them for me showing which list is "behind"
  @is helpful
  \<<
    {} "listGlobalVars" DROP
    "" "varName" DROP
  
    \->
    
    listGlobalVars
    varName
    \<<
      {HOME LIFEG} EVAL
        @move in the directory
        
      5 TVARS  @collect all the lists
      'listGlobalVars' STO
      
      1 listGlobalVars SIZE
      FOR index
        listGlobalVars index GET
        'varName' STO @we save the globalVar name
        
        varName EVAL SIZE
        varName \->STR "'" "" SREPL DROP
        \->TAG
      NEXT
      
      listGlobalVars SIZE
      \->LIST @I create a list
      
      @and I sort it, hopefully by size
      SORT
    \>>
  \>>

[DavidM]

Here's an additional example of one way to approach this.

As written, the following RPL program needs to be saved in the root of your HOME directory (or in a library) so that it can be accessed appropriately. It could be saved somewhere else if you make a minor change to it, though I'll leave that as an exercise for the reader.

Code:

DODIRS
\<<
  \-> prog      @ save the program given as an argument in a local variable
  \<<
    prog EVAL   @ execute the program in the current directory
    15 TVARS    @ obtain a list of any subdirectories in the current directory
    IF { } OVER SAME NOT THEN             @ if any subdirectories exist...
      1 \<< EVAL prog DODIRS \>> DOSUBS   @ execute DODIRS on all of them
    ELSE        @ else there weren't any subdirectories
      DROP      @ drop the empty list; nothing further to process
    END
  \>>
\>>

DODIRS takes another RPL program in stack level 1 as an argument, then executes it in the current directory and each "child" subdirectory to the current one.

As an example, let's say that you wanted to obtain a list of all of the directories currently defined in your directory tree. You can do this simply by setting HOME as your current directory, then passing a simple program to DODIRS which updates a result list as the directory tree is traversed:

Code:

TestDODIRS
\<<
  {} PATH \-> result cd
  \<<
    HOME
    \<<
      PATH 1 \->LIST 'result' SWAP STO+
    \>>
    DODIRS
    result
    cd EVAL
  \>>
\>>

Hopefully the combination of Pier's and these examples will spark some ideas for you.

[Gilles59]

(09-14-2017 11:17 AM)brickviking Wrote:  Now I'm wondering how to add together all the TOTALs in each folder to give me a sum at the end?
Cheers, brickviking
(Post 82)

Hi Brick

put this program in your grocery directory

Code:

TYear
«
 0.
 {'JAN' 'FEB' 'MAR' .... 'OCTOB' 'NOV' 'DECEM' }
 1. « EVAL TOTAL + UPDIR » DOSUBS
»

And you get the total.
But this suppose that all your directory structure (JAN FEB etc) is created and that the TOTAL object exits in each directory.

If the TOTAL sometimes does not exist :

Code:

«
 0.
 {'JAN' 'FEB' 'MAR'  .... }
 1. « EVAL IF TOTAL DUP TYPE 6. == THEN DROP ELSE + END UPDIR » DOSUBS
»

Quote:I'm sure that if I could run a program in the GROCERIES folder iterating over each month

To create, calculate or update automatically the TOTAL for a month, here is an idea :

Code:

'TMonth'
«
   -> Month
  «
   Month EVAL
   0. 'TOTAL' STO
   VARS S~N 1.
   « IF DUP Month S~N POS 
      THEN S~N EVAL AXL CNRM 'TOTAL' STO+ 
      ELSE DROP END »
   DOLIST
  UPDIR
 »
»

STOre this in your grocery directory.
Usage :
'JAN' TMonth

Warning : flag -86 must be set or type once 256 ATTACH


To update all automaticaly and calculate months and year total, you can put this program in your grocery directory :

Code:

<< {'Jan' 'Feb' .... 'Dec'} << TMonth >> DOSUBS TYear >>

(not tested all of this but I think it will work)

What is your MONTOT  object for ?

EDIT : I dont know how you create your RPL program, but I suggest you to use HPUserEdit with Emu48

[brickviking]

(09-15-2017 08:51 PM)Gilles59 Wrote:  Hi Brick

put this program in your grocery directory

Code:

TYear
«
 0.
 {'JAN' 'FEB' 'MAR' .... 'OCTOB' 'NOV' 'DECEM' }
 1. « EVAL TOTAL + UPDIR » DOSUBS
»

And you get the total.
But this suppose that all your directory structure (JAN FEB etc) is created and that the TOTAL object exits in each directory.

That looks like just what I wanted. I'll have to prod it and see how it works, especially DOSUBS.

(09-15-2017 08:51 PM)Gilles59 Wrote:  If the TOTAL sometimes does not exist :

Code:

«
 0.
 {'JAN' 'FEB' 'MAR'  .... }
 1. « EVAL IF TOTAL DUP TYPE 6. == THEN DROP ELSE + END UPDIR » DOSUBS
»

....
What is your MONTOT  object for ?

The MONTOT was a way to grab two lists, add them together, then push a list sum into the TOTAL file for each month, but I suspect your way is far more elegant.

(09-15-2017 08:51 PM)Gilles59 Wrote:  EDIT : I dont know how you create your RPL program, but I suggest you to use HPUserEdit with Emu48

I grabbed the latest alpha for HPUserEdit, my only problem with it is that I don't know where the current author lives, or whether he is still maintaining HPUserEdit. I did grab a English language file for the latest alpha (6.0a2). A hint to users that I worked out: to change the language in HPUserEdit, fire up RegEdit, look for HKCU\Software\HPUerEdit6\Environment\Language and change that string from Spanish to English, then save. No more having to rename the English file to Spanish.lng. I tried adding back a couple of the missing strings in the file, but I'm not entirely sure if I was successful.

(Post 83)

[pier4r]

I use notepad++ , connectivity 4 hp48/50 (windows). And directly the calculator for resting

[brickviking]

(09-16-2017 06:30 AM)pier4r Wrote:  I use notepad++ , connectivity 4 hp48/50 (windows). And directly the calculator for resting

If I'm not near my computer, then I'll work directly on the calculator, though it's a bit slow. If I need faster text input, then I normally use Conn4x, plug the calculator in, fire up Xmodem, click "Connect", then go find my file, right-click on it, and "Edit as text". Bare bones basic, but it gets me by, especially when I point to gvim as the editor <grin>. However, there's no doubt the modern (ha!) crop of editors for HP have some more functions that make things easier.

I was aware of UEdit/UCalc which are sorta-payware with the free versions having some limitations. I'd tried WinHP, but that had the fatal bug that I couldn't insert "" characters. Just wouldn't let me do it whatsoever, even if I cut-and-pasted it into the editor window. Weird.

HPUserEdit might make things far easier for me, although I've yet to figure out how to connect to a real calculator with it. Shouldn't be hard, though now I've got to go translate the Portugese (or Spanish) help file. A doddle, right?

uhm no.

I know the author's website's no longer live, but I don't know where it shifted to.

(Post 84)

[pier4r]

well if you are used to vim (hail!) then I think it is not needed, for userRPL at least, to have a dedicated editor for userRPL. Although dedicated editors made a nice job and they themselves require quite a work.

And yes you can also directly edit the file (for that I use notepad2-mod). The advantage of notepad++ (or also vim) is the auto completion so I recall the command from the AUR (or internet or memory) and then auto completion does it for me.

Actually I should be less lazy and make a language format for notepad++ for both userRPL and newRPL. In that way it would be really neat.

[Gilles59]

(09-16-2017 09:07 AM)brickviking Wrote:  HPUserEdit might make things far easier for me, although I've yet to figure out how to connect to a real calculator with it. Shouldn't be hard, though now I've got to go translate the Portugese (or Spanish) help file.

I use a SD Card. In HPUserEdit do 'FILE' 'EXPORT' hp binary file

HPUserEdit is multi language. But you can change only _after_ the installation in spanish. After the installation click the equivalent of "Option" "Language". The french translation is very fine for exemple. I use the version 5.4.0850. Not sure about a stable v6 version. I tried once but it was beta version with some problems.

HPUserEdit works very well with EMU48 (Ctrl E send the program to EMU48).

There are only 2 things I dont like:
1 / When there is a sntax error in the code, there is no help to find it
2 / HPuserEdit use specific fonts (that's fine) but it lacks of triglyphs import/export

I tried other softwares, but imho HPuserEdit is the the best for UserRpl (the help for GROB, INFORM etc are great)- No SysRPL support.

[brickviking]

(09-16-2017 11:34 AM)Gilles59 Wrote:  HPUserEdit is multi language. But you can change only _after_ the installation in spanish. After the installation click the equivalent of "Option" "Language". The french translation is very fine for exemple. I use the version 5.4.0850. Not sure about a stable v6 version. I tried once but it was beta version with some problems.

HPUserEdit6(alpha2) has a bug where it doesn't update the registry key for the chosen language, and indeed doesn't appear to have set the language—it's like the program never calls the "Choose this menu entry" for the other language file, hence why I used regedit to do it for me. Fiddly, yeah. Do I get the second language? Yeah. In addition, some of the menu entries aren't translated, it seems that language keywords haven't been completely supported for the new version yet, as I get weird things like Barras de Harramienta (toolbar) and the File-Open submenu isn't translated either. I can't send files to the calculator, and the dialog for communications settings can't find any ports, as I use a USB cable. I haven't found other bugs—yet.

(09-16-2017 11:34 AM)Gilles59 Wrote:  There are only 2 things I dont like:
1 / When there is a sntax error in the code, there is no help to find it
2 / HPuserEdit use specific fonts (that's fine) but it lacks of triglyphs import/export

I tried other softwares, but imho HPuserEdit is the the best for UserRpl (the help for GROB, INFORM etc are great)- No SysRPL support.

Hm. That could be interesting when and if I ever write a SysRPL program. Of course, debug4x has both the things you specified were missing from HPUserEdit. I don't know if it has any help for writing INPUT boxes (it does have an INFORM builder), but I can't see any direct support for importing *.hp files in debug4x (compiled RPL). It's also not aimed at UserRPL writers, but it doesn't leave it out either. HPUserEdit most certainly supports UserRPL and importing of .hp (pipes it to EMU, then slurps it into the editor).

I was able to update the old version of EMU48 bundled with HPUserEdit to 1.57+, that previously had a rather old 1.49 install.

(Post 85)

[DavidM]

(09-17-2017 04:07 AM)brickviking Wrote:  Hm. That could be interesting when and if I ever write a SysRPL program. Of course, debug4x has both the things you specified were missing from HPUserEdit. I don't know if it has any help for writing INPUT boxes (it does have an INFORM builder), but I can't see any direct support for importing *.hp files in debug4x (compiled RPL). It's also not aimed at UserRPL writers, but it doesn't leave it out either. HPUserEdit most certainly supports UserRPL and importing of .hp (pipes it to EMU, then slurps it into the editor).

Debug4x wasn't designed with UserRPL in mind, and thus only has minimal support for it (code completion and templates for UserRPL are there, but not much else). Stepping through code and compiling/decompiling objects are all relegated to the embedded Emu48 instance, which requires a lot of manual interaction. HPUserEdit is much better in comparison.

If you ever decide to branch out into SysRPL or Saturn coding, however, I would whole-heartedly recommend Debug4x. The user interface is a bit "long in the tooth" now as an IDE, but it's the best way I know of to observe what's truly going on in the calculator while running a SysRPL/Saturn program.

[brickviking]

I do have a quick question about the inbuilt debugger (PRG->RUN->DBG). How can I get it to trace into a subprogram? It seems to skip over the subprogram even if I use SST↓ and follow up with what follows the subprogram. (That's SST with a downarrow after).

The code I'm trying to debug (i.e. find out how it works) is the inner subprogram section beginning "IF DUP Month ...", but the debugger skips to DOLIST instead of entering the «…» and tracing onwards:

Code:


« →Month
  « Month EVAL  0. 'TOTAL' STO
    VARS S~N 1.
@ I can't enter this section here with the inbuilt debugger @
   «  IF DUP Month S~N POS
       THEN S~N EVAL AXL CNRM 'TOTAL' STO
       ELSE DROP END  
     » DOLIST UPDIR  @ skips ahead to here instead @
  »
»

I'll put up a post another time with a line-by-line about how I think this works, just to see if I've got it right.

(Post 86)

[brickviking]

(09-15-2017 08:51 PM)Gilles59 Wrote:  To create, calculate or update automatically the TOTAL for a month, here is an idea :

I'll try comment how I think separate commands work, but I have some questions about how it all works. I'm sorry I have to @ comment@ @every@ @keyword@, but I'm new to this... oh wait, I've said that already, several times.

If I hadn't used varnames that began with the month I was storing them in, what would have been used instead? i.e. Jan/value1, .../value2, .../value3 etc?

Code:

'TMonth'  @ name - gee, I'm bright! @
«
   -> Month  @ Create local var, though I had to get rid of the "->" and put in the single char for it: "" (assuming that's a right-pointing arrow like →) @
  «
   Month EVAL  @ change directory to what's in Month. What happens if the month doesn't exist as a dir? @
   0. 'TOTAL' STO   @ Stick zero into TOTAL, as we're going to add it all up @
   VARS                @ create list of variables in subdir @
S~N  @ turn them all into a list of strings @
1.  @ grab 1 entry from the list (part of how DOLIST works) @
   « IF 
         DUP @ create a duplicate of entry grabbed from list @
         Month S~N @ Turn Month varname into a string @
         POS  @ find its position in the previous string @
      THEN @ dump the test result, it was successful @
         S~N  @ Turn the var string back into a varname @
         EVAL @ Put it on the stack @
         AXL CNRM @ Turn it into an array and add it up @
'TOTAL' STO+  @ add this to TOTAL, removing it and 'TOTAL' from the stack @
      ELSE @ dump the 0 (test result) @
        DROP @ otherwise, ignore this string (remove it from the stack) @
      END » @ rinse, repeat. Pull another list entry until there aren't any more @
   DOLIST @ process each member of the list @
  UPDIR  @ change back up a directory @
 »
»

Quote:Warning : flag -86 must be set or type once [i]256 ATTACH

Where can I find a shorter shortcut to the devel menu aside from Apps->Up->Up->F6 ?

Quote:To update all automaticaly and calculate months and year total, you can put this program in your grocery directory :

Code:

<< {'Jan' 'Feb' .... 'Dec'} << TMonth >> DOSUBS TYear >>

(not tested all of this but I think it will work)

Yep, it certainly looks like it will.

(Post 87)

[John Keith]

(09-18-2017 10:26 AM)brickviking Wrote:  Where can I find a shorter shortcut to the devel menu aside from Apps->Up->Up->F6 ?

\<< 256. MENU \>> can be assigned to a user key or stored in CUST.

[DavidM]

(09-18-2017 10:05 AM)brickviking Wrote:  I do have a quick question about the inbuilt debugger (PRG->RUN->DBG). How can I get it to trace into a subprogram? It seems to skip over the subprogram even if I use SST↓ and follow up with what follows the subprogram....The code I'm trying to debug (i.e. find out how it works) is the inner subprogram section beginning "IF DUP Month ...", but the debugger skips to DOLIST instead of entering the «…» and tracing onwards:...

In the case of a user program which is passed to DOLIST, you can't. It is being run repeatedly within the confines of the single DOLIST step, so when you SST through that command all of the invocations have already occurred.

Normally you can insert the RPL sequence "41 MENU HALT" to force a debugging interruption anywhere you like, but HALT isn't allowed within a user program that is passed to DOLIST.

Your best bet would simply be to create a "test program" that sets up the subroutine in question with suitable stack contents and just executes it once without using DOLIST. Then you should be able to SST through the various steps to follow its progress.

[brickviking]

(09-18-2017 01:35 PM)DavidM Wrote:  

(09-18-2017 10:05 AM)brickviking Wrote:  I do have a quick question about the inbuilt debugger (PRG->RUN->DBG). How can I get it to trace into a subprogram? ...

In the case of a user program which is passed to DOLIST, you can't. It is being run repeatedly within the confines of the single DOLIST step, so when you SST through that command all of the invocations have already occurred.

Oh yay. That could be a bit of a problem if I needed to trace without having understood which commands can't be traced into.

(09-18-2017 01:35 PM)DavidM Wrote:  Your best bet would simply be to create a "test program" that sets up the subroutine in question with suitable stack contents and just executes it once without using DOLIST. Then you should be able to SST through the various steps to follow its progress.

In the end, I did it the old-fashioned way. Anyone want to guess what that uses?
(Hint: it doesn't need electricity, or really a calculator. It just needs a reference manual.)

Yeah, I used paper and pen. I wrote the instructions down, along with the stack, list of vars and directories. It only took one A4 piece of paper to get. Understanding what each instruction helped out when I was writing up the stack, and only impressed me even more about just how useful the AUR is. It also let me figure out how that program posted earlier actually works, and how he got away with the specific commands he used. Nice job, Gilles59, and thank you.

(Post 89)

[DavidM]

(09-19-2017 08:38 AM)brickviking Wrote:  Oh yay. That could be a bit of a problem if I needed to trace without having understood which commands can't be traced into.

As a general rule, the inner workings of individual RPL commands can't be traced into. SSTing them simply executes the command and then stops when they are complete. Note that when you use a command like DOLIST or DOSUBS, the "user program" is an argument that you are passing to it. It doesn't actually get executed until the command itself invokes it within the confines of its processing of the list(s). So when you are stepping through your code with the debugger, the user program is simply being added to the stack when encountered as opposed to being executed. Execution of your program happens "inside" the DOLIST/DOSUBS invocation.

In some cases (notably with EVAL), a user program passed as an argument can be stepped through. You would simply need to insert "41 MENU HALT" at the point you wish the code to break. This is important if you use what is perhaps the most common method of deploying subroutines in a self-contained UserRPL program (storing the subroutine in a local, then executing it with "<local> EVAL").

Unfortunately HALT would wreak havoc with the inner workings of DOLIST/DOSUBS, so it can't be used in that context.