That's... not a bad idea. The downside is the bot would be doing a lot of these and false-positives would be... embarrassing (like a real investor outreach).
I've also seen the reverse. Some people who treat me poorly have a terrible voice in their own head where they trashtalk themselves. It's like they see it as fair to do to others as long as they're not hypocritical about it.
Do you talk to yourself the way you talk to me? If so then you need to stop both.
When I was younger I was partly guilty of this and still occasionally catch it. But we are always more sensitive to vices in others that we police in ourselves.
Using llama.cpp and the 9b q4 xl model, it is on Thinking mode by default and runs without stopping. The only way to force it to stop is to set the thinking budget to -1. (Which is weird as the docs say 0 should be valid)
Did you figure out how to fix Thinking mode? I had to turn it off completely as it went on forever, and I tried to fix it with different parameters without success.
Thinking has definitely become a bit more convuluted in this model - I gave the prompt of "hey" and it thought for about two minutes straight before giving a bog-standard "hello, how can i help" reply etc
did you try with the recommended settings? the ones for thinking mode, general tasks, really worked for me. Especially the repetition_penalty. At first it wasn't working very well, and it was because I was using OpenWebUI's "Repeat Penalty" field, and that didn't work. I needed to set a custom field with the exact name
What's the best way to handle having multiple frontend components respond to events from a single SSE connection from some parent node data provider? Ideally we do not what many SSE connections within a page for each component.. right? Then what's the best practice to handle that single SSE handler on the server and frontend? If that makes sense...
That's exactly what patch mode is designed for. You open a single SSE connection on a parent element with `mu-mode="patch"` and `mu-method="sse"`, and the server sends HTML fragments with `mu-patch-target` attributes pointing to whichever components need updating. One connection, multiple targets. The server decides which components to update on each event.
I love this- I'll give it a spin. I'd really want web developers to start making websites again that can run without javascript, but it can feel like a SPA if JS is available. This has always been 'possible' but, in practice, it's a massive pain. uJS and HtmX could help to be the polyfill solution to make this possible.
That said, I worry about Form elements being controlled by uJS to use a different REST method (like DELETE), and this would cause JS-free browsers to break.
Glad it clicks! On the progressive enhancement point, µJS is designed exactly with that philosophy in mind: standard links and forms work without JS, µJS just enhances them.
Your concern about `mu-method="delete"` is valid. Without JS, the browser will fall back to the form's native method (usually GET or POST). The classic solution is the `_method` hidden field pattern: the form submits POST with a `_method=DELETE` field, and the server reads that field to route the request correctly. µJS doesn't need to implement anything special for this, it's a server-side convention
reply