riverdweller

You keep saying that major models have "tool calling built in". And that by giving them context about available APIs, the LLM can "use the API".

But you don't explain, in any of your comments, precisely how an LLM in practice is able to itself invoke an API function. Could you explain how?

A model is typically distributed as a set of parameters, interpreted by an inference framework (such as llama.cpp), and not as a standalone application that understands how to invoke external functions.

So I am very keen to understand how these "major models" would invoke a function in the absence of a chassis container application (like Claude Code, that tells the model, via a prompt prefix, what tokens the model should emit to trigger a function, and which on detection of those tokens invokes the function on the model's behalf - which is not at all the same thing as the model invoking the function itself).

Just a high level explanation of how you are saying it works would be most illuminating.

Rooting your LG TV allows you to install homebrew apps. If you have a device that's at least a couple of years old and has not had its firmware updated, try https://rootmy.tv/

Microsoft also last year released their own Redis-client-compatible key-value store, Garnet: https://github.com/microsoft/garnet

Human recall failure. Probably wanted "seemingly", "apparently", or even "ostensibly", but who's got time for all that when the publish button's right there.

I remember installing the TCP/IP stack from a treasured special floppy onto win 3.11 machines (giving them RIPE addresses and using NT4 as a router to expose the entire network onto the public internet - not a great idea in retrospect, but it was 1994 and everyone seemed so polite).

Meta has just released another in a series of extraordinary models that are already being abused to flood the crawlable web with regurgitated generative uncanny-valley material.

Since Google abandoned their focus on service quality, they are a prime target. The output of these models further hastens Google's decline in utility, and in turn, attractiveness to advertisers. Those ad budgets have to be spent somewhere, though; guess where?

Do you mean Danish audio description in Danish and English subtitles?

It’s not elegant, but the term is evolutionary mismatch.

Perhaps think instead of human skin as a wretched slimy substrate on which poor, determined fungi have to somehow eke an existence.

This approach was what we had to use back in the late 90s. We called it "iframe streaming", or "forever iframe" (and years later, as an industry term emerged, "comet"). It worked surprisingly well, except in cases where a client sat behind a greedily buffering proxy. We would send JavaScript statements that invoked callbacks on the client, rather than just JSON, as this avoided the need to parse data to determine which business logic to use on the client. This has the limitation of being "non-cross domain" (i.e. the web page containing the callback functions have to be served from the same domain as the infinite document).

To get around buffering proxies, we optionally allowed our clients to use a JSONP long polling approach instead, whereby the client would dynamically generate a form inside a hidden iframe, and POST a request for JSONP data (JSON delivered wrapped in a callback), and the server would return data as soon as any was available. The client would immediately repeat the process to request more data, an infinitum.

Eventually, the emergence of the XMLHTTPRequest object in IE (and subsequently in other browsers) allowed us to implement cleaner long-poll-style methods, holding the connection open until data was available (and automatically reconnecting on error). This was later enhanced with CORS for delivery of data from arbitrary domains. As support for detecting updates to an in-progress response became available (via XMLHTTPRequest's "progress" event, which for a long time was horribly buggy in IE ) our payloads became infinite streams too (of JavaScript callback invocations). Early versions of approach also required us to reload the entire page from time to time, as IE's underlying implementations of these browser objects appeared to have memory leaks (that we did not see in Firefox, for example).

When IE8 was released, we allowed clients to optionally use its XDomainRequest object to stream a response instead.

Years later, the much cleaner Server Sent Events (SSE) and WebSocket options became possible. Intermediate proxy support was initially troublesome however, and while both of these were our preferred choices from a performance and API perspective, it took several years before we could consider removing support for our earlier approaches. Even today, there are network environments where an infinite sequence of long polls is the only reliable option...

My preference today? The JavaScript fetch API for sending commands, with a simple ack as a response, and an async flow of events over a persistent SSE connection, that feed into a simple JS message bus (implemented using the browser's native event API) for delivery to vanilla JavaScript web components. Simple, clean, and consistent.

Approximately 1.11%. Certificates issued by LetsEncrypt (the CA for this certificate) are valid for 90 days. Most users automate their renewal.

If the speculation that the board want to open up everything so that it is truly open/public domain "for the benefit of humanity" turns out to be accurate, I can't see Microsoft being terribly happy about this now that they own 49% of OpenAI and want not only to recoup their investments but make ongoing profit.

An exodus of staff might provoke a very quick release of a lot of code, pipelines, and training data by the remaining board before investors' lawyers have a chance to stop it.

Wow - just tried this and struck gold on the very first amateurish-looking GPT-wrapper iOS app I tested.

Lovely stuff. Now someone please use this in a Bioshock-like adventure based in London's semi-apocalyptic west end.

Tesla unilaterally decided to push out a refactored UI to my old Model S a few months ago, changing the location of numerous functions to new sub-menu paths, and rendering years of muscle memory useless.

Not only do I have to re-learn where everything is, but older memories interfere and confuse every time I try to access an infrequently used function.

This experience has been irritating at best. It has felt extremely unsafe on more than one occasion.

Would be great to have a CDN-based JS distribution for those who want to play without the heartache of JS build systems (npm/yarn/webpack/etc).

I look forward to a next generation LLM being further trained on the entire contents of sci-hub.

A few years ago I built some tools https://github.com/tf318/tamtools to store alignments against two different reference assemblies in an efficient way (taking advantage of the fact that the majority of each alignment to different assemblies would in fact be the same, just shifted in position).

The intent was to enhance this to store alignments against multiple references as new references are published, and probably to rewrite in Rust or C rather than the initial Python version.

In retrospect I would be interested to know whether this domain-specific compression effort, with zstd to the resulting "hybrid" alignment, would be more efficient than just letting zstd do its own thing with a full set of individual alignments against the different references.

Equivalently, the energy used to train GPT-3 was the same as the energy consumed by Bitcoin in just four minutes.

Am pretty sure a better answer than any of these would be:

Randomly choose *40* more students from this year’s freshman class and email them the questionnaire.

It is odd that as late as April 1994 the info service was migrated to gopher instead of http. By that time, most of the colleges had their own websites up and running. Students themselves were rapidly authoring web content (my contribution on my college server was a choose your own adventure from my room, past my dusty empty pigeonhole, through town to my common room bar). It was already clear that the ease of contribution meant http was going to dominate going forward. I guess the gopher migration wasn't a quick project.

Reading this article in a Copenhagen street. Houses built in the 1700s, and are a rich orange. Every car parked in the street is monochrome: https://www.instagram.com/p/ChSUWOgsnoA/

Fewest is the correct word. There is no subjectivity about it.

They could have said (albeit hideously): "The routes with the least change". In this case, change is an uncountable noun.

But they didn't. They said "The routes with the least changeS", which uses the plural of the countable noun "change". So quantifier "fewest" is correct. The quantifier "least" is not.

It’s entirely unnecessary. The data is updated too infrequently to justify anything like this.

I built a one-pager vanilla JS site that polls the official Johns Hopkins aggregated data daily, and displays dynamically generated smoothed moving average charts, performs curve similarity analysis to identify similar patterns in different countries, and performs logarithmic regression to depict current doubling/halving times.

This happens entirely on the client side, with no server side component whatsoever (other than the http server to deliver the static HTML&JS that does all the work). See https://covid-19-charts.net/

Great initiative, but I must ask: is the Greek compound formed from makro and gamy entirely accidental? Because it describes the past twenty years quite accurately.

If you’ve rooted it, you can fix the CA cert issue with this: https://github.com/tf318/lg

One type of data that can beneficially be exposed under different keys is information pertaining to financial instruments (e.g. instrument reference data or market quotes). Some users may wish to look them up using an ID assigned by Bloomberg (a FIGI). Some other users may instead be familiar with an ID assigned by Reuters (a RIC). Or an ISIN, a CUSIP, or a SEDOL, and so on. In some cases it's simpler to store the data under multiple keys than to build "joins" into the client (given we don't have the luxury of RDBMS SQL logic).

Thank you for the additional recommendations.

Unspeakably irreverent but great fun (though you've probably already encountered it) is Joachim Horsley's Beethoven in Havana: https://youtu.be/mZRb0FyAa9s

> the three essential recitals of the Op.92 II Allegretto

Karajan and the Berlin Philharmonic (1963) for grave and majestic, Gardiner and the Orchestre Révolutionnaire et Romantique (1994) for bright and invigorating - but what's the third?