czardoz

Exactly. OpenClaw is good, but expects the model to behave in a certain way, and I've found that the local options aren't smart enough to keep up.

That being said, my gut says that it should be possible to go quite far with a harness that assumes the model might not be quite good (and hence double-checks, retries, etc)

Really looking for a minimal assistant that works with _locally hosted models_. Are there any options?

If this stack is heavily skewed towards numerical computations, Cinder might require a lot of tuning to be effective.

It has some elements of WSGI, but has expanded into its own thing which supports asyncio (this happened before ASGI was a thing).

I'd love to see lazy imports become part of the upstream at some point.

Cinder's feature set is highly optimized for IO bound web services that run under a forked-worker model.

For example: you start a main process, warm it up with a few requests, run the JIT compiler and then fork off worker processes to handle the main chunk of traffic.

As of now, it requires hand-tuning to get the best possible performance.

In terms of use cases, Cinder does the best when faced with "business logic" code (lots of inheritance, attribute lookups, method calls, etc). It can speed up numerical computations too, but you're probably better off using a library if that's the majority of the workload.

I worked on Cinder, and on the web server. Happy to answer technical questions if any :)

I'm always surprised when patterns like this actually work. But they do!

This article captures a lot of the rationale behind why we're building Static Python within Cinder: https://github.com/facebookincubator/cinder#static-python

One minor clarification here: Cinder[1] is actually 100% compatible with C extensions (by virtue of being a fork of CPython).

[1]: https://github.com/facebookincubator/cinder

I've moved to Zoho mail. It's $1/month for a single user, which seems to be well worth it. The catch is, it's not possible to _send_ from Zoho without creating additional users (which has a cost).

Can you elaborate on what you mean by "skip" Cython compilation on dev builds? How would you then test changes to Cython code?

Unlike RPython, Static Python in cinder is not really a subset of Python, it can compile everything (although it will throw compile time errors if it sees mismatched types). If it cannot determine type information, it just assumes the type could be anything, and falls back to slower CPython behavior.

> Why is “developers might have to interact with it” some kind of non-starter, as though having a compile phase is a worse evil than a hyper-slow language?

For big monoliths (like ours at IG), the server start-up can take more than 10sec, which is already super high for a "edit -> refresh" workflow. Introducing a Cython like compilation step is really a major drawback for every single developer.

For smaller projects, Cython works extremely well (and we do use it for places where we need to interface with C/C++).

> Well, the compilation step is alredy present in current py -> pyc phase

Yes, but developers don't have to ever interact with it.

> Also, look at how cython work

Cython works by adding a separate build step. Changing a Cython module requires you to recompile it, which is avoided with a JIT.

> So much stuff just from the readme would introduce breaking changes to the Python ecosystem.

Being compatible with the rest of the Python ecosystem is the main reason why Cinder is built on top of CPython. Although yes, some features are indeed very experimental.

> in a world where we have type annotations, JITs feel like a massive step back. Stuff like mypyc could get us way further into high performance stuff

Ah, but that introduces a separate compilation step, which may not be tolerable in every situation.

Here's some good documentation about v8's JIT: https://github.com/thlorenz/v8-perf/blob/master/compiler.md

Note: Never worked on v8, just liked the information here.

Yes, Static Python especially relies heavily on strict modules, since they enable us to perform module-local analysis, which enables some cool optimizations.

There's nothing wrong with gotos in compiled code. At the end of the day, machine code is really just a bunch of gotos with other instructions in between.

The reason goto is considered bad is that it can make code hard to follow for humans. Since this is an intermediate step in compilation, that's not an issue here.

> Why do I need methods to have underscores in 2021, but classes to use camel case? Why do my lines of code need to fit on a punched card invented decades before the language was invented? Why does the idiomatic "one true way" need to be what some other engineer thinks is "the one true" way?

These problems are applicable to all languages, not just Python.

No, look up "pip"

I guess that depends on how you define "space"

> Google pays a trivial amount of tax here.

Google provides a lot of value with their free products too. Aren't you discounting that?

That's completely tangential to the discussion. No one's trying to figure out who to blame for spreading the virus.

The point I was trying to make was, restrictions on personal freedom are reasonable in this case to keep the broader society healthy.

You're talking about this as if a "calculated risk" is limited to that individual, but it's not. Someone's "calculated risk" is literally death knell for others.

In this case, the health of the society as a whole is at stake. Therefore, people need to collectively follow rules, and understand that minor inconveniences such as not being able to get a haircut will only affect them for a few weeks or months.

What's ”VA space”?

What's your point? Are you saying that TikTok having these guidelines is okay?

(I work at IG, but not on Explore)

> So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on.

That's unsubstantiated and dilutes the discussion IMO. If you read the post, the proposal outlines a bunch of good reasons to stop supporting UA strings (feature detection, etc)

I got this too.

> Apple has a 1-week (or is it 2 weeks?) unconditional return policy. It actually disservices them to announce it after since they may now get a bunch of open box returns.

Yeah, but how many people are actually going to go through the hassle of returning them?