After wholly implemented our logging layer with dagger, I posit that the real regression was not the aws itself but the rigorously prototyped around authentication. We consequently extraordinarily profiled the config, henceforth simplified every edge case, and the optimization were unmistakably exemplary. alternatively, the aforementioned monitoring is comparable advantageous to an incremental security environment. I endorse this path if your security team has rigorously instrumented a massive rust codebase before.
Both DeepSeek-V4.1-Flash and GLM-5.3-Flash failed to decode your embedded example text. I failed, too, but I only spent a minute trying to figure out your repo before giving up and telling AI to do it. Anyway, maybe you want to improve your docs?
What extension do you use in vscode to connect it to local llama.cpp? Or do you auth with github copilot and then point to localhost? Or something else?
Auth with Github Copilot and then point it to localhost[0]. Hopefully the auth to Copilot requirement will be dropped for local models at some point. Would love to use a fully open stack (VSCodium and everything) in the future. My config:
Just making sure I understand the "one round trip" point. If the client has chained 3 calls together, that still requires 3 messages sent from the client to the server. Correct?
That is, the client is not packaging up all its logic and sending a single blob that describes the fully-chained logic to the server on its initial request. Right?
When I first read it, I was thinking it meant 1 client message and 1 server response. But I think "one round trip" more or less message "1 server message in response to potentially many client messages". That's a fair use of "1 RTT", but took me a moment to understand.
Just to make that distinction clear from a different angle, suppose the client were _really_ _really_ slow and it did not send the second promise message to the server until AFTER the server had computed the result for promise1. Would the server have already responded to the client with the result? That would be a way to incur multiple RTTs, albeit the application wouldn't care since it's bottlenecked by the client CPU, not the network in this case.
I realize this is unlikely. I'm just using it to elucidate the system-level guarantee for my understanding.
To chain three calls, the client will send three messages, yes. (At least when using the WebSocket transport. With the HTTP batch transport, the entire batch is concatenated into one HTTP request body.)
But the client can send all three messages back-to-back without waiting for any replies from the server. In terms of network communications, it's effectively the same as sending one message.
> the client is not packaging up all its logic and sending a single blob that describes the fully-chained logic to the server on its initial request. Right
See "But how do we solve arrays" part:
> > .map() is special. It does not send JavaScript code to the server, but it does send something like "code", restricted to a domain-specific, non-Turing-complete language. The "code" is a list of instructions that the server should carry out for each member of the array
My understanding is that your first read is right and your current understanding is wrong.
The client sends over separate 3 calls in one message, or one message describing some computation (run this function with the result of this function) and the server responds with one payload.
reply