saucepan.ai not working in PM Topic is solved

[dinosaur]

Yesterday, I discovered saucepan.ai, but sadly it does not work properly with Pale Moon, and (from a blank profile) I get this error in the console:

Code: Select all

Timestamp: 27/07/2026 09:45:50
Error: TypeError: this['#e'].includes is not a function
Source File: https://saucepan.ai/assets/vendor-query-k-8MECoV.js
Line: 1

Here is what it looks like (no bot listed, and chats do not work at all either):

saucepan-ai.png

[adoxa]

The problem is that private members (the #e bit) aren't private enough (it's using the main class's value, not the extended's). Here's a Modify HTTP Response filter to work around it (at least, it shows companions, I didn't go any further than that).

Code: Select all

[["saucepan.ai",["/vendor-query/",["vt=class{#e;destroy(){this.clearGcTimeout()}scheduleGc(){this.clearGcTimeout(),G(this.gcTime)&&(this.#e=setTimeout(()=>{this.optionalRemove()},this.gcTime))}updateGcTime(t){this.gcTime=Math.max(this.gcTime||0,t??(M?1/0:300*1e3))}clearGcTimeout(){this.#e&&(clearTimeout(this.#e),this.#e","vt=class{#ee;destroy(){this.clearGcTimeout()}scheduleGc(){this.clearGcTimeout(),G(this.gcTime)&&(this.#ee=setTimeout(()=>{this.optionalRemove()},this.gcTime))}updateGcTime(t){this.gcTime=Math.max(this.gcTime||0,t??(M?1/0:300*1e3))}clearGcTimeout(){this.#ee&&(clearTimeout(this.#ee),this.#ee"]]]]

Since it's quite specific, it may break on a site update.

[dinosaur]

Yup, that works, with chats as well.

Thanks a bunch !

Yet, from your explanation, it looks like a class inheritance bug in PM's script engine...

[Moonchild]

Yet, from your explanation, it looks like a class inheritance bug in PM's script engine...

It's a known limitation of the way we have JS classes implemented. Private member syntax is accepted, but those members aren't fully private; if there is a name conflict with an extended class, then it may not work.
JS classes are a mess (classes are pretty foreign to JS's language paradigms -- it's a c-ism shoehorned into it), and our implementation has taken some shortcuts to get something working out there on short notice. It works for most cases.

[dinosaur]

It's a known limitation of the way we have JS classes implemented. Private member syntax is accepted, but those members aren't fully private; if there is a name conflict with an extended class, then it may not work.
JS classes are a mess (classes are pretty foreign to JS's language paradigms -- it's a c-ism shoehorned into it), and our implementation has taken some shortcuts to get something working out there on short notice. It works for most cases.

Hmm... What about "on-the-fly" private class members renaming (should be possible at JS tokenization time, if your engine does use tokenization/semi-compilation), like "member" becomes "__member" when private ?