Report site bugs here

@byte[]
The autocompleter cache appears to be just a binary-searchable linear list of tags and implications. If you switched to a (compressed) trie, you could remove all the redundant prefixes (like “artist:”) and fit far more tags in the cache, and maybe leave some space for aliases while still staying below the size budget.

Or perhaps compressing the tags using LZSS with a custom dictionary that has been optimized for this special case?

I’ve noticed that now fancy tags don’t give out tag results including prefixed tags (for example, now, to search for a artist tag to put on you have to type “artist:” first to get any result) like it used to - is this intentional?

@JP
The current encoding is optimized to avoid creating garbage on the JS heap, to prevent any lag. Switching to a compact trie representation might save space, and could be internally flipped into a binary-searchable ArrayBuffer on the client side. This would probably avoid the creation of much garbage, but then it would waste time in JS constructing the list, whereas the current compiled object is immediately ready to go as soon as it is downloaded. So, I’m not sure what’s optimal here.

@Mildgyth
Yes, this is intentional.

@byte[]
Damn, I keep forgetting how badly suited JavaScript and web browsers are for stuff like this.

Perhaps a secondary list could be created for aliases?

@byte[]
@JP
So I tried building a trie in the most space-optimal way I could write in a few minutes.

List of 65k tags in newline-delimited format (so one byte separating them): 988251 bytes
List of 65k tags in a packed trie, with unshared suffixes skipped: 723142 bytes

It’s a win for compactness only. The trie can’t be searched without at least an initial very expensive traversal.

@byte[]
IMO it is critical. It helps with tag discovery: a user may still find a tag that’s worded differently than they think if what they’re typing matched an aliased version. It helps with tag meanings: if a less-specific term has been aliased into something more self-evident, they’ll see the clearer-named tag if typing the less-clear aliased version.

Wait, seriously? Why?

Okay, I’m designing a v2 format that handles namespaced names and aliases the same way it was done previously.

@byte[]
Ah, I was just about to ask whether this system is also responsible for a change from offering tags that had more than 3 instances, but upon rereading your post I see that yes it was. Just ran into that now where I had to jump over to the tags page to see whether a tag for something existed, instead of having it pop up as I began to type. Big step down in usefulness, IMO.

By the way - maybe I’m just used to using slow connections and slow devices - but what was unsatisfactory previously, that merited the trade-offs to functionality?

Despite the lack of aliases, the new local autocomplete system is really good to use. It’s instantaneous, no need to type three letters and wait for the server to respond. It just needs some further tweaking.

Also, just noticed that the autocomplete is also case-sensitive now, even though our tags don’t differentiate between upper and lower-case.

Is Twitter fetching broken for anyone else? I seem to have trouble fetching images now.

@Background Pony #8E63
For about a week now it fails half the time, needs to hit “Fetch” multiple times.

afaict it’s due to something on Twitter’s side of things.

Also, as reported multiple times by other users, the ‘VS’ button on >>2774515 is giving out a download page (in effect, working exactly like the ‘DS’ button) instead of a image page. This doesn’t seem to be happening anywhere else.

Twitter scraper should be fully operational again.

@Mildgyth
It’s working just normal for me.

Same here; may have been resolved after an image reprocess?

>>2774515 is missing its VS image. I already reported it and the report is resolved, but it doesn’t seem to be fixed? Unless I’m mistaken somehow…

@Wiimeiser
It shows up for me.

@TheGlitchedWolf
Seems to be fixed for me now.

Some images don’t load at all (just now an image >>2773597 didn’t load until I refreshed it 3 times)

@TheGamerPainter
I see it fine in chromium and FF. What browser / version are you using? Do you see any errors in the console? Do the VS / View buttons work?

@The Smiling Pony
Google Chrome (app) version 96.0.4664.101
No but as I was typing rn, the page froze for a few seconds, but I’ll check
Update: They both work but take a second to load image.

Ok so now images on threads like the Applejack one take a while for all the images to load up.

I’m not sure if it’s only on my end, but the reverse image search doesn’t seem to be working as it should. After uploading something that ‘wasn’t found’ only to run across it later, I reverse searched for a few other images that I know have already been posted only for it to come up as not found.

@Bloatpones
Is a known issue; reverse search will be working again in 2-3 days.