Articles will now notify the members of the group if:

a) an attachment is added
b) the page is deleted
c) the user checks the "notify" checkbox when making an edit

This seems to me like a good balance that should require a minimum of fiddling.

quoting Rhetorica:

Yyyyes and no. My office workstation was suffering noticeably, though it was still a relatively small penalty—but that's because the graphics card in it is a Quadro K2000D with the proprietary drivers, and has absolutely no excuse to chug ever.

Heh. I've only ever been able to run the proprietary drivers. Mine's an Nvidia GeForce 9600 GT.

*looks up your card*

oh my gods that card is godly

HOLY FUCK THAT'S EXPENSIVE ><

*rocks back and forth for a while*

Anthologica is broken when trying to view larger tags in dictionaries. It conplains about being out of memory when you try to do so.

quoting Travis B.:

Anthologica is broken when trying to view larger tags in dictionaries. It conplains about being out of memory when you try to do so.

Which tag and how many entries does it have? This happens occasionally with Nouns on CM.net, I know. I can't recall the details of Sam's explanation but I think the gist was at the time there wasn't much doable about it.

Added "end" and "continue" links to make it less confusing when you jump into a forum thread.

I have a new idea about the way tags are processed; there's a good chance it'll have an overall speed-up effect on dictionary display. I'll take a shot at it in a little bit.

They definitely occur with the noun and verb tags under Thote Dictionary. I do not know an exact word count because my offline dictionary is not in front of me at the moment. However they cannot be larger than 683 entries, the total size of the dictionary.

It used to only happen with Proto-Søkkli's nouns category, but now that we have HTMLPurifier intercepting every WF Markup call (each word requires at least one), smaller categories have gotten problematic. My brilliant The obvious solution: only run the markup parser once, after all of the entries have returned their text.

About the continue link, on one page (I don't remember which) it sent me to a page that was empty except for the page header and the box to enter a new post (and the associated buttons). I assume this is not the intended behavior.

That behaviour was present for five or ten minutes while I was implementing it; it was sending you to a page starting right after the last post in the thread. I replaced it with the logic used by the thread list to determine the first unread post. That's well-tested code that shouldn't cause any such issue.

I've implemented the fix for dictionary tags. I can now load the Proto-Søkkli full-view page really, really fast. Enjoy.

Browsing the rant thread, I came across that:

(something went wrong; report
these numbers: qc = 33, np = -1,
pp = -1)
1 2 end

I had the same problem!

my numbers were

(something went wrong; report these numbers: qc = 32, np = -1, pp = -1)

Were you wrenching around with the site?

I also received some mystical numerals.

qc = 33, np = -1, pp = -1

Is it some kind of a lottery that who gets the highest number wins!?

Heh, no. It's a bug Cev discovered. Threads with between 21 and 39 posts (inclusive) weren't showing page navigation links at all. Fixing it shortly.

And now on a single-paged threads there are useless blunt bars with just plain non-linked "end".

Removed. Also fixed a problem where jumping to the end would cause previous/next links to retain the page offset (e.g. hitting "next" when the end was at posts_pagenum=57 would take you to posts_pagenum=37.) This was causing the page links to not indicate where you were. Changed so that previous/next always force integral page offsets.

Added caching of generated formatting for linear posts and news posts. The speed improvement was less dramatic than I expected, but there is still a bit of one.

Still on the lookout for whatever causes the exponential ramp-up in reported comment count on news posts. (Gadzooks.)