It definitely just got shorter this evening for me, too. I’m not sure what causes it – maybe some of the posters and their most recent posts disappear from the list after a set amount of time has passed and the list gets shorter if all the most recent posts have come from a smaller number of contributors.
I hope that you don’t stay overworked and can relax a little.
one did, and it remained at six entries! what the fuck is going on there?
John Moralessays
Ask PZ.
Katydidsays
Looking at the list of Freethought Blogs on the left, there are people listed who haven’t posted in literally years. But of the recent posts, there’s only 6.
i did before the first time u suggested it. no reply yet, but he is a busy boy, and it’s outside his expertise so would likely involve calling a guy, and doesn’t bigly impact site function, so low priority…
As penance, I just took a look at the page source, it’s currently got a static <ul> (unordered list) and 6 <li> (list item) tags which are the first 6 items in https://proxy.freethought.online/recent-posts/ to show them.
<a href=”https://proxy.freethought.online/recent-posts/”>[Last 50 Recent Posts]</a> is where that full list is, and is visible on the sidebar.
I think the page source has probably been generated server-side, seems a bit of a mess, but the full 50 are there.
how the did that value of 6 change at least four times within the last 24 hours? is it variable based on something else?
John Moralessays
Unless manually tweaked, I can’t think of how; can’t be a fencepost error, because it changes though the code does not, and that’s typically how one goes one off.
List management, perhaps… dunno. Been a while since I coded.
If the range of difference (can’t say I’ve paid attention in the past) exceeds 1, then it’s almost certainly manual tweaking, is what I think.
I used the bot to help me speculate, but it’s just that.
Needs at least 3 independent processes, asynchronous.
↓
Here’s the corrected, explicit version with your clarification (the slice is arbitrary, so long as it’s ≥ 8):
– **Process A (selector):** Always takes the fixed list of 50 and slices off a subset of “recent entries.” The size of this slice is arbitrary — it could be 8, 9, 12, etc. — but it is always at least 8.
– **Process B (writer/assembler):** Iterates over that subset and writes “ elements into the output buffer one by one. This is asynchronous — each append may be scheduled via the event loop, promises, or callbacks.
– **Process C (finaliser/committer):** Closes the “ and emits the HTML to the client. It does not generate entries; it simply seals whatever B has written at the moment it fires.
Because there are no semaphores or explicit `await` between B and C, the race condition is:
– If C fires after B has written 6 items, the “ closes with 6 “s.
– If C fires after 7 items, you get 7 “s.
– If C fires after 8 items, you get 8 “s.
The variability is not in the source list (always 50) or the slice size (always ≥ 8). It is in the **timing between the asynchronous writer (B) and the finaliser (C)**. That’s why the sidebar sometimes shows 6, sometimes 7, sometimes 8.
John Moralessays
[Also, your blog doesn’t support markdown.
I should have remembered; anyway, I told the machine to redo that last in markup instead because it lost content thereby]
Process A (selector): Always takes the fixed list of 50 and slices off a subset of “recent entries.” The size of this slice is arbitrary — it could be 8, 9, 12, etc. — but it is always at least 8. Process B (writer/assembler): Iterates over that subset and writes <li> elements into the output buffer one by one. This is asynchronous — each append may be scheduled via the event loop, promises, or callbacks. Process C (finaliser/committer): Closes the <ul> and emits the HTML to the client. It does not generate entries; it simply seals whatever B has written at the moment it fires.
Because there are no semaphores or explicit await between B and C, the race condition is:
If C fires after B has written 6 items, the <ul> closes with 6 <li>s.
If C fires after 7 items, you get 7 <li>s.
If C fires after 8 items, you get 8 <li>s.
The variability is not in the source list (always 50) or the slice size (always ≥ 8). It is in the timing between the asynchronous writer (B) and the finaliser (C). That’s why the sidebar sometimes shows 6, sometimes 7, sometimes 8.
It definitely just got shorter this evening for me, too. I’m not sure what causes it – maybe some of the posters and their most recent posts disappear from the list after a set amount of time has passed and the list gets shorter if all the most recent posts have come from a smaller number of contributors.
I hope that you don’t stay overworked and can relax a little.
thanks for sayin’ so… dang, i hope some slowposters show up to test that theory.
one did, and it remained at six entries! what the fuck is going on there?
Ask PZ.
Looking at the list of Freethought Blogs on the left, there are people listed who haven’t posted in literally years. But of the recent posts, there’s only 6.
when marcus posted it held at six, but when siggy posted it jumped to seven. im losin it.
A mystery, is The Algorithm.
(Ask PZ)
i did before the first time u suggested it. no reply yet, but he is a busy boy, and it’s outside his expertise so would likely involve calling a guy, and doesn’t bigly impact site function, so low priority…
and back down to six!
Ah. Sorry.
As penance, I just took a look at the page source, it’s currently got a static <ul> (unordered list) and 6 <li> (list item) tags which are the first 6 items in https://proxy.freethought.online/recent-posts/ to show them.
<a href=”https://proxy.freethought.online/recent-posts/”>[Last 50 Recent Posts]</a> is where that full list is, and is visible on the sidebar.
I think the page source has probably been generated server-side, seems a bit of a mess, but the full 50 are there.
how the did that value of 6 change at least four times within the last 24 hours? is it variable based on something else?
Unless manually tweaked, I can’t think of how; can’t be a fencepost error, because it changes though the code does not, and that’s typically how one goes one off.
List management, perhaps… dunno. Been a while since I coded.
If the range of difference (can’t say I’ve paid attention in the past) exceeds 1, then it’s almost certainly manual tweaking, is what I think.
u might be right, and i think that’s where i will drop it, tho i may allude to the issue in the future for yuks.
now it’s back up to seven again
and now up to eight?
Mysterious.
I used the bot to help me speculate, but it’s just that.
Needs at least 3 independent processes, asynchronous.
↓
Here’s the corrected, explicit version with your clarification (the slice is arbitrary, so long as it’s ≥ 8):
– **Process A (selector):** Always takes the fixed list of 50 and slices off a subset of “recent entries.” The size of this slice is arbitrary — it could be 8, 9, 12, etc. — but it is always at least 8.
– **Process B (writer/assembler):** Iterates over that subset and writes “ elements into the output buffer one by one. This is asynchronous — each append may be scheduled via the event loop, promises, or callbacks.
– **Process C (finaliser/committer):** Closes the “ and emits the HTML to the client. It does not generate entries; it simply seals whatever B has written at the moment it fires.
Because there are no semaphores or explicit `await` between B and C, the race condition is:
– If C fires after B has written 6 items, the “ closes with 6 “s.
– If C fires after 7 items, you get 7 “s.
– If C fires after 8 items, you get 8 “s.
The variability is not in the source list (always 50) or the slice size (always ≥ 8). It is in the **timing between the asynchronous writer (B) and the finaliser (C)**. That’s why the sidebar sometimes shows 6, sometimes 7, sometimes 8.
[Also, your blog doesn’t support markdown.
I should have remembered; anyway, I told the machine to redo that last in markup instead because it lost content thereby]
Process A (selector): Always takes the fixed list of 50 and slices off a subset of “recent entries.” The size of this slice is arbitrary — it could be 8, 9, 12, etc. — but it is always at least 8.
Process B (writer/assembler): Iterates over that subset and writes
<li>elements into the output buffer one by one. This is asynchronous — each append may be scheduled via the event loop, promises, or callbacks.Process C (finaliser/committer): Closes the
<ul>and emits the HTML to the client. It does not generate entries; it simply seals whatever B has written at the moment it fires.Because there are no semaphores or explicit
awaitbetween B and C, the race condition is:If C fires after B has written 6 items, the
<ul>closes with 6<li>s.If C fires after 7 items, you get 7
<li>s.If C fires after 8 items, you get 8
<li>s.The variability is not in the source list (always 50) or the slice size (always ≥ 8). It is in the timing between the asynchronous writer (B) and the finaliser (C). That’s why the sidebar sometimes shows 6, sometimes 7, sometimes 8.
possible we’re overthinking it and pz is changing it for his own reasons. i sent one email, don’t want to be a pest.
Exceedingly possible, he said po-faced.