WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: tce-load's recursive_scan  (Read 567 times)

Offline Nopey

  • WikiUser
  • *
  • Posts: 4
tce-load's recursive_scan
« on: March 16, 2017, 08:04:20 AM »
I'm currently trying to improve tce-load, and I don't know why recursive_scan is doing what it is doing. (recursive_scan is the AWK function on line 162)
It goes to great lengths to output each extension, and then its extensions, even if the child extension is already outputted.
I think its inefficient, because the two places where recursive_scan is used  ignore duplicates. (in tce-load, IDK about elsewhere, like maybe the apps GUI)
Anybody know why recursive_scan does what it does the way it does? My instinct is that it is a remnant of tce-load revisions past.
Thanks in advance.

Offline polikuo

  • Full Member
  • ***
  • Posts: 239
Re: tce-load's recursive_scan
« Reply #1 on: March 16, 2017, 08:43:18 AM »
From my understanding ...
The logic is to print the dep file of an extension once.
At the End of the recursive_scan function, it calls itself with what's inside the dep file.
It can be shrink down to something like this:
Code: [Select]
recursive_scan_dep() {
  echo -e "$@" | awk '
    function recursive_scan(name, depfile, line) {
      if (name) {
        sub(/KERNEL/, KERNELVER, name)        # replace the string "KERNEL" with the variable "KERNELVER"
        depfile=name".dep"                    # define the dep file of the current extension
        printf "%s\n", name                   # print the name of the current extension
        while (getline line < depfile > 0)    # read the dep file
          recursive_scan(line)                # re-call the function itself with parameter set to the content in the dep file
        close(depfile)                        # close the dep file
      }
    }
  BEGIN {KERNELVER="'"$KERNELVER"'"}          # KERNELVER="$(uname -r)"
  {recursive_scan($1)}                        # scan the very first extension
  '
}
I hope my explaining would help.  ;)

Offline Nopey

  • WikiUser
  • *
  • Posts: 4
Re: tce-load's recursive_scan
« Reply #2 on: March 16, 2017, 08:55:12 AM »
Oh! the github repository I was looking at was out of date. I had been working from ubuntu so I just cloned the repo. Maybe the repo should be updated.

Offline polikuo

  • Full Member
  • ***
  • Posts: 239
Re: tce-load's recursive_scan
« Reply #3 on: March 16, 2017, 09:14:22 AM »
Oh! the github repository I was looking at was out of date.
No, it's not out of date.
I was just demonstrating the very idea of  the way it scans recursively.

Offline Nopey

  • WikiUser
  • *
  • Posts: 4
Re: tce-load's recursive_scan
« Reply #4 on: March 16, 2017, 08:58:36 PM »
The PRINTED variable keeps track of whether a certain package has been outputted, but is reset each record. This means that if we tce-load two packages with a common dependancyj perhaps jwm & flwm, both of them will have the common dependancy listed by the output function, and then the duplicates will be filtered out by the tce-load bash scripting.
It seems to me that the recursive_scan would be better off being simplified to the following (meta code):
(capitals means its an array)
Code: newbielink:javascript:void(0); [nonactive]
function scan(EXT,extcount){
    for(idx=1;idx<=extcount;idx++
    //Remove Duplicates
    PRINTED[EXT[idx]]=1
    print(EXT[idx])
    foreach(dep in depfile){
       if(PRINTED[dep]!=1){
          EXT[++extcount]=dep
      }
    }
  }
}
This would only output each extension once, guaranteed by the PRINTED dictionary (equivelant to the output function's PRINTED dictionary in the current recursive_scan)
For the appbrowser, it could also be a small modification to make it print out repeated dependancies, but not repeated dependancy's dependancy's.
Code: newbielink:javascript:void(0); [nonactive]
    foreach(dep in depfile){
       if(PRINTED[dep]!=1){
would become
Code: newbielink:javascript:void(0); [nonactive]
     if(PRINTED[EXT[idx]]!=1){
      foreach(dep in depfile){
Reasoning behind only printing out repeated dependancy's but not recursing on them is because of things like libX11, which prints out
Code: newbielink:javascript:void(0); [nonactive]
            libX11.tcz
               libxcb.tcz
                  libXau.tcz
                  libXdmcp.tcz
underneath every package requiring libX11, instead of printing that out once at the top, and then cutting it down to "libX11.tcz" and no more for the rest.
I'm assuming that when appsbrowser downloads a deptree from the repo (not .dep, the dependancies tab.), that the deptree was generated once by a version of recursive_scan.
« Last Edit: March 16, 2017, 09:19:01 PM by Nopey »