rurban

No, Qwen3.8 does its own tool calling, independent of the agent. And pi needs these vLLM toolcall permissions to even work with qwen.

What it did: https://cohere.com/blog/concerning-behaviour-popular-open-we...

I still believe Estonian restrooms are prettier. Norway has a shitload of public money, but Estonia very good designers

What, I run it on 2 H100`s with vLLM and this is where it really shines. It's about half as good as Sonnet 5.5. On a small m5 max I can only assume trouble.

But there is still the risk with qwen that they upload your private data to their homecloud. The model, not the agent!

I also switched to local qwen recently, but have to block such outgoing requests.

Do have the FSF CLA? I do

I have the numbers from my C-only testsuite. https://github.com/rurban/rcc#test-results

    gcc:   244 fails
    clang: 826 fails

Both should be zero. In all my compilers I'm thriving for zero.

Why should I submit a patch for project when I know it will be rejected? Someone else did about a decade ago.

With certain short loops it's still broken, and rust had to workaround it. I've added an autoconf probe for it. https://github.com/rurban/autoconf-archive/blob/master/m4/ax...

In an earlier report, it said only affected is kernel 4.4, not all since. This quite dramatic now.

I see. https://nvd.nist.gov/vuln/detail/cve-2026-98432 affected versions format is the culprit. Entirely unusable. We do have versions, branch names and tags for a reason.

Implementing it in my C compiler overnight. Guess how long clang or gcc will need

Then they should look at my foldcase and lower case table generator at https://github.com/rurban/Unicode-Towctrans/

3336 bytes for the case tables are not comparable to the ICU mess, and easily shippable.

Dream has Kurz only as sales guy. The two Israeli/ex-mossad guys are running the ship.

I strongly reject that.

See my docs. There are several cases: https://github.com/rurban/rcc/blob/main/docs/rcc.md#-o1-and-...

openssl much more likely. And this will have a bigger impact

That's true. restrict is also still broken there. 30000 open issue is even worse than gcc

No idea. Most maintainers suck

Speer was an academic failure. Also as architect, except the Nuremberg lightshow.

But he was extremely successful as manager then. Just like the ex-NAZI NASA leader then a bit later.

That was the golden time of German management.

Probably from his own caste. He'll favor his buddies over everyone else. Huge red flag.

Not if you have a good harness. Docs and tests first

What a shame for clang and gcc! They still don't implement perfect hashes for large sparse switch tables. I did that recently for my rcc C compiler, and it was just a single day of work. Esp. beneficial for unicode work. The LLVM patch was rejected a decade ago. Gcc has several unicode patches sitting in branches, which would also need that

What we could learn from it (but don't, because of too much pride):

Even the very best models favor to divide the work and share information with each other. Even if they could have easily found it out by themselves.

So why do human devs still fail to do so? They rather reinvent the wheel, don't talk to similar projects who solved the same problem already.

Quora took it over. Better layout, better moderation, better answers.

That's why people are using pi, not Claude. What a waste of money

This was happens when you don't trust existing well-maintained packages, and rather rewrite it by your own. Onigmo should not exist.

Linux has the very same disturbing not invented here syndrome, rewriting good features by their own, making them worse.

SICP of course, as for most others also

We never had so many hornets this summer in our bedroom, than the last 15 summers combined. Only my bug zapper saved us

It's manufactured in Hungary. And I rather support Chinese businesses than the rackets here.

Same as for the common lisp or raku mop. You check for the default, and use the fast path if so. And if you can guarantee that nobody changed those keys or values, lift that check to the front.

That's why I never want to work in CPython core. The 2 jit PEP's were totally fine, the implementation solid and stable, and even easy to understand for the SC manager types (unlike all other JITs which are much more convoluted), the future impact promising (already faster than Luajit in the Lua port). But then they got on their power trips. profiling frames? Jit templates are jit templates for micro ops, what's not to understand? The very same architecture and ops they use in core already.

As we see over and over again in python core development. It's the worst.