@MortenZdk The "(*" and "*)" are used for multi-line comments in Maple, they and everything between them are a comment. In the Maple initialization file (see the worksheet,reference,initialization help page) I include

  interface('prompt' = "(**) "):

which assigns that string as the prompt. Because it is a comment, I can then copy it with the input and use the result directly without having to delete the prompts. I find that useful because I frequently use tty Maple rather than the GUI and the standard copy operations copy the prompts.

@sand15 That method is quite limited. It won't work if the procedures access other module members (exports or locals). The better approach is to use external text files and, if you are comfortable with them, $include statements. There are secondary advantages of going that route, for example, one can also use version control, a source code editor,and the Maple mint syntax checker. Consider running mint on the file for your Q module, it reveals a number of issues.

To get you started, I took the liberty of exporting your worksheet to a text file, Programming2.txt. I normally use the extension .mpl, however, the green arrow won't upload files with that extension.

@candy898 The issue is that all the exports and locals of a module have to be assigned in the body of the module. They cannot be assigned outside the module. Consequently, all the code for the module must be in one input region.

@Les maplesys.ini is not the Maple initialization file of interest; it is only used by the GUI for GUI settings. See the help page I referenced in my previous comment.

I do not understand what you are asking. Maybe you can give an example.

It's not possible, with the exception of the first dozen or so bytes, the rest of the file consists of NULLs.

Any idea what happened before it got corrupted?  Is there a .bak file in the same directory?

As a trivial modification, change the the assignment to orbits to

   orbits := table(); # not actually necessary
   ...
   # use this to keep unique values of orbit.
   orbits[orbit] := NULL;
   ...
   return numelems([indices(orbits,'nolist')]);

What you were doing is creating a set by continually appending to it, one element at a time, which is O(n^2) in time and memory usage. With that change alone it runs in 12 seconds.

@Traruh Synred Alas, the file you uploaded is nothing but 0 bytes, 

Using Preben's observation, one can avoid the use of forget in Carl's example by adding a dummy lexically scoped variable (here k) to the local procedure f:

Normalize:= proc(L::list)
local f:= proc() option remember; k; 0; end proc, k:= 0, x;
     for x in L do
          if f(x)=0 then
               k:= k+1;
               f(x):= k
          end if
     end do;
     f~(L)
end proc:

Because my simplification used k (in a useful way), I didn't run into the problem.

@Carl Love This simpler version works

Normalize:= proc(L :: list)
local f, k := 0;
    f := proc()
    option remember;
        k := k+1;
    end proc;
    f~(L);
end proc:

As does this, which avoids the remember table altogether

Normalize := proc(L :: list)
local k := 0,prev:=NULL,x;
    [seq(`if`(x=prev
              , k
              , `+`(assign('k'=k+1, 'prev'=x), k)
             ), x = L)];
end proc:

There is no such icon. To plot a signal, either connect a probe to it or select it from the variables pane in the simulation results window after simulating.  The easy way to connect a proble is to right-click on the signal and select "Attach Probe".

@Carl Love Agreed, they don't work. Either the OP is doing something wrong, or the apparent presence of the plus sign in the name of the file is causing a problem.  They are not downloadable.

Consider uploading the worksheet to this site. Use the green arrow.

@Carl Love As you suspect, subsop has more or less the same issues. It has some advantages in that it doesn't evaluate the result and, if called with multiple subsitutions, does them simultaneously, so that only one immutable expression is created. I should have pointed out that the orginal code was particularly inefficient in that the entire listlist is copied with each assignment. Kitonum's second solution avoided the issue by building the final list at once, in the sequence, and "modifying" (i.e. copying and modifying) just the sublists. The inefficiency of copying small lists isn't a big issue here, particularly as there are at most 64 distinct 8 bit lists.