User:GUYTU6J/Template:OscNumbers

(Note: Some effects may only be visible at the time of writing.)

Wadufi (W): How to solve the Template:OscNumbers mystery?

Fjord (F): No idea. Well, the previous code was awfully messy and comment-less, and we could not see how it was intended to work now that there have been several LifeWiki updates.

W: Let's figure it out now. Maybe its structure is a bit clearer in some advanced text editor.

F: See, in Visual Studio Code the curly brackets are paired up. There are... five sections in series, each starting with an {{#ifexpr}} except the third one, followed by an {{#dpl}}.

W: Yeah the one in the middle is the simplest. Start from here. I can spot some usual parameters like category and replaceintitle. But what's going on with the offset?

F: It is determined by {{#expr}} calculation, which calls another {{#dpl}} and subtracts one from its returned value. This inner layer of {{#dpl}} looks similar to the outer layer.

W: Except for the resultsheader and format! What do they imply about the output format?

F: Huh, it prints a string-comparing {{#ifeq}} without evaluation. There are four instances of {{!}} for character escape of |, possibly accounting for that phenomenon.

W: Why are there three commas in the code? Ah yes, the DPL manual says that they are used to separate the list items. For Startall,Start,End,Endall, Startall and Endall define an outer frame for the whole list, and Start and End build an inner frame for each article item.

F: Technically you are referring to the DPL2 manual, whereas we are supposed to read one for DPL3 instead. I see no difference in definitions here, though.

W: Sure it is. %TITLE% is for page title, %NR% for its sequence number. Due to replaceintitle removing other parts, %TITLE% is shown here as a single number, specifically the highest period with a category.

F: What if I just discard the character escape templates?

{{#ifeq:40894:15240:2700:576:550:486:470:384:325:312:280:276:275:256:246:231:226:225:224:220:217:200:199:196:192:186:184:177:171:168:166:165:156:150:148:146:144:143:140:138:135:132:130:129:128:127:126:124:120:119:118:117:116:114:113:112:111:110:109:108:107:106:105:104:103:102:101:100:98:97:96:94:93:92:91:90:89:88:87:86:85:84:83:82:80:79:78:76:75:74:73:72:71:70:69:68:67:66:65:64:63:62:61:60:59:58:57:56:55:54:53:52:51:50:49:48:47:46:45:44:43:42:41:40:39:38:37:36:35:34:33:32:31:30:29:28:27:26:25:24:23:22:21:20:19:18:17:16:15:14:13:12:11:10:9:8:7:6:5:4:3:2

W: it behaves as if cutting out everything behind %TITLE%. Hold on — look at the order of numbers!

F: What's so surprising about the descending order?

W: If I recall correctly, it is reported that in a DPL result, the numbers are sorted in alphabetical order like 1, 10, 100, ... instead of numerical order like 1, 2, 3, ... . (Tries changing "descending" to "ascending") Look, the values are undoubtly increasing uniformly.

F: Bother, another new question...

W: Yet another curiosity. There is actually another {{#ifeq}}, but it is incomplete and there is an unexplained "a" inside.

F: I think it is some sort of "periodic boundary condition" for listed items.

W: How?

F: Suppose you have resultsheader=A and format=B,C,D,E in a {{#dpl}} call. Then the result will be displayed as ABCDCD...CDE. The partial {{#ifeq}} you mentioned is in D, making the subsequent DC unit a complete {{#ifeq}}.

W: Really? Can I see more units?

F: No effect?

W: Try again...

asdfasdfasdfasdf

F: Clever stroke. So only the first {{#ifeq}} is not evaluated but the next three are.

W: I still don't see the function of the single "a". It leads to a tail looking like }{{#ifeq:{{!}}a}} that makes no sense at all.

F: Perhaps just a deliberately impaired {{#ifeq}} termination.

W: And why even split the {{#ifeq}} instances in the first place?

{BDDDDE

F: What the... (Adds placeholder B, D and E) All the {{#ifeq}} have disappeared! But not other parts?

W: Maybe the curly brackets are at fault.

{B{{#ifeq:40894|0|1|asdf{{#ifeq:15240|0|2|asdf{{#ifeq:2700|0|3|asdf{{#ifeq:576|0|4|asdf,D,E

}}

F: The lack of right brackets calls for yet another character escape template. ... Okay, I have made {{)}} for this.

{BasdfDasdfDasdfDasdfDE

W: It works. So what was the context?

F: Context? (Reviews earlier discussion) Mmm, this is supposed to return a single number for {{#expr}} calculation.

W: So the extra things like asdf and BDE are to be thrown away. For testing, I will temporarily replace the variable {{{p|0}}} with a real number. How about 2700?

3

F: Yes, it is currently the third largest period with an existing category.

W: How about trying it out on the original template? The edit is ready.

F: ...And we are done? Wow!

W: Unexpectly fast, indeed!

F: Can we do more?

W: Certainly... For example, we should generalize that to other number navigation templates.

F: ...Except it is not trivial to see how.

W: Why?

F: From the beginning there is a regular expression for replaceintitle, which assumes that simple deletion of certain words in the title gives a clean number.

W: ...Yikes. How could I forget their decision for a massive category merging last year? That is bound to complicate any potential regex!

F: Sigh.

(A couple of days later)

W: Thanks to the introduction to {{#dplvar}}, I have had the page simplified a lot. And for convenience I have also marked the start of each item.

F: Neat!

(One month passed when suddenly)

W: Did someone say "Mayday"?

F: Eh what? No, you must be too carried away with Air Crash Investigation.

W: But my cutie mark my sense tells that something we did before was going wrong.

F: You must be joking. (Checks forums) What?! Sorry, ignore the last sentence.

W: New oscillator periods throw a database error? Nothing but {{#dpl}} in Template:OscNumbers could possibly do that.

F: So there it comes, a crash investigation. (Becomes serious) Where to begin?

W: Read the maintenance records. (Reviews what is exactly the dialogue made one month ago) I have a clue. (Points to the second box above)

F: Anything weird with the list of periods?

W: It jumps from 156 to 168, skipping 165. The classical behaviour of {{#dpl}} results being out of sync with updates, I would say.

F: The question is, how does that cause the error?

W: Unclear. But... (Proceeds to check the category page for periods 150, 156, 168 and 175) None of the adjacent pages in the series has that error.

F: Which pins the culprit to the third {{#dpl}}, the one for displaying the period of the page's own.

W: The one and only vulnerable part that could be subject to an outdated {{#dpl}} result is the offset parameter. It contains a {{#expr}} that involves a {{#dplvar}} defined with {{#dpl}}.

F: True. What is the value of the affected {{#dplvar}} here?

W: Empty, not even zero.

F: Then how does {{#expr}} treat it?

31

W: It is evaluated as if the empty {{#dplvar}} has a value of zero.

F: What happens when attempting to pass -1 to offset in an otherwise normal {{#dpl}}? (Crashes immediately with the same message)

W: Bingo! Now that we can reproduce the error, we are pretty close to a solution.

F: Are we? The root cause is an outdated {{#dpl}} result, which is usually hard refreshed by purging to clear cache, or making a null edit to the page.

W: Sure, but we cannot purge or edit the problematic page with the existence of that error. It is disturbing...