rhdunn

For llama-server (and possibly other similar applications) you can specify the number of GPU layers (e.g. `--n-gpu-layers`). By default this is set to run the entire model in VRAM, but you can set it to something like 64 or 32 to get it to use less VRAM. This trades speed as it will need to swap layers in and out of VRAM as it runs, but allows you to run a larger model, larger context, or additional models.

That search (e.g. `ford fiesta water pump`) is consistent for me as well, except for an "explore more" section in the middle of the results.

So it does seem to be specific searches where it gives up after the first 7-10 results (or decides to show you some more related results after 20-30 additional unrelated results).

I wonder if this is algorithmic. E.g. people searching for a specific "how to replace/fix ..." are not going to click on results from their recommended feed, so the algorithm could have learned to keep those results fixed. However, someone looking for a piece of entertainment (trailer, book review, etc.) may be more inclined to click on other unrelated content, so those searches are more inclined to show results from the user's recommended feed.

Examples:

- `dune book review`

- `sierpinski triangle`

- `full adder` -- better results, but includes an unrelated "previously watched" section

One of the main issues I've encountered is that when searching for something you generally see:

- 7 or so relevant results

- shorts (which I'm not interested in)

- "people also watched" / "previously watched" results -- I'm not interested in that, I just want what I'm looking for

- "channels new to you" -- can include results, so maybe okay

- "explore more" -- mostly irrelevant results to what I'm looking for

- "previously watched" -- may be fine, but mostly unrelated

After the first 7-10 results it generally becomes unusable.

XPath 1.0 is a pain to write queries for. XPath 2.0 adds features that make it easier to write queries. XPath 3.1 adds support for maps, arrays, and JSON.

And the default Python XPath support is severely limited, not even a full 1.0 implementation. You can't use the Python XPath support to do things like `element[contains(@attribute, 'value')]` so you need to include an external library to implement XPath.

XPath is used in processing XML (JATS and other publishing/standards XML files) and can be used to proces HTML content.

RDF and the related standards are still used in some areas. If the "Batteries Included" standard library ignores these then those standards will need an external library to support them.

Schema.org is used by Google and other search engines to describe content on the page such as breadcrumbs, publications, paywalled content, cinema screenings, etc. If you are generating websites then you need to produce schema.org metadata to improve the SEO.

Did you notice that a new PNG standard was released in 2025 (last year, with a working draft in 2022) adding support for APNG, HDR, and Exif metadata? Yes, it hasn't changed frequently, but it does change. So if you have PNG support in the standard library you need to update it to support those changes.

And if HTML support is optional then you will need an external library to support it. Hence a "Batteries Included" standard library being incomplete.

That's my point. You can have a large standard library like those languages I mentioned, but that isn't going to include everything nor cover every use case, so you'll have external libraries (via PyPi for Python, NuGet for .NET, and Maven for Java/JVM).

The HTML "Living Standard" is constantly updated [1-6].

The PNG spec [7] has been updated several times in 1996, 1998, 1999, and 2025.

The XPath spec [8] has multiple versions: 1.0 (1999), 2.0 (2007), 3.0 (2014), and 3.1 (2017), with 4.0 in development.

The RDF spec [9] has multiple versions: 1.0 (2004), and 1.1 (2014). Plus the related specs and their associated versions.

The schema.org metadata standard [10] is under active development and is currently on version 30.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (New)

[2] https://web.dev/baseline/2025 -- popover API, plain text content editable, etc.

[3] https://web.dev/baseline/2024 -- exclusive accordions, declarative shadow root DOM

[4] https://web.dev/baseline/2023 -- inert attribute, lazy loading iframes

[5] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (Baseline 2023)

[6] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (2020)

[7] https://en.wikipedia.org/wiki/PNG

[8] https://en.wikipedia.org/wiki/XPath

[9] https://en.wikipedia.org/wiki/Resource_Description_Framework

[10] https://schema.org/

There are several issues with "Batteries Included" ecosystems (like Python, C#/.NET, and Java):

1. They are not going to include everything. This includes things like new file formats.

2. They are going to be out of date whenever a standard changes (HTML, etc.), application changes (e.g. SQLite/PostgreSQL/etc. for SQL/ORM bindings), or API changes (DirectX, Vulcan, etc.).

3. Things like data structures, graphics APIs, etc. will have performance characteristics that may be different to your use case.

4. They can't cover all nice use cases such as the different libraries and frameworks for creating games of different genres.

For example, Python's XML DOM implementation only implements a subset of XPath and doesn't support parsing HTML.

The fact that Python, Java, and .NET have large library ecosystems proves that even if you have a "Batteries Included" approach there will always be other things to add.

The question is really about where the boundary between presentation (CSS) and interactivity (JavaScript) lies.

For static content like documents the distinction is easy to determine. When you think about applications, widgets, and other interactive elements the line starts to blur.

Before things like flex layout, positioning content with a 100% height was hard, resulting in JavaScript being used for layout and positioning.

Positioning a dropdown menu, tooltip, or other content required JavaScript. Now you can specify the anchor position of the element via CSS properties. Determining which anchor position to use also required JavaScript, but with things like if() can now be done directly in CSS.

Implementing disclosure elements had to be done with a mix of JavaScript and CSS. Now you can use the details/summary elements and CSS to style the open/close states.

Animation effects when opening an element, on hover, etc. such as easing in colour transitions can easily be done in CSS now. Plus, with the reduced motion media query you can gate those effects to that user preference in CSS.

So people who play games for a living are not adults? There are many people who create videos in Minecraft with complex builds, drawing inspiration from things like architecture, nature, etc.

And there are many adults who play video games to unwind after work.

And it's not just men who play video games. There are a lot of women who play video games including Minecraft and other games, including a huge range of more casual games.

Wine has a lot of tests that are run across platforms to check conformance -- https://test.winehq.org/data/. These are a large part of why it has good compatibility.

The idea behind a greenscreen is that you can make that green colour transparent in the frames of footage allowing you to blend that with some other background or other layered footage. This has issues like not always having a uniform colour, difficulty with things like hair, and lighting affecting some edges. These have to be manually cleaned up frame-by-frame, which takes a lot of time that is mostly busy work.

An alternative approach (such as that used by the sodium lighting on Mary Poppins) is that you create two images per frame -- the core image and a mask. The mask is a black and white image where the white pixels are the pixels to keep and the black pixels the ones to discard. Shades of gray indicate blended pixels.

For the mask approach you are filming a perfect alpha channel to apply to the footage that doesn't have the issues of greenscreen. The problem is that this requires specialist, licensed equipment and perfect filming conditions.

The new approach is to take advantage of image/video models to train a model that can produce the alpha channel mask for a given frame (and thus an entire recording) when just given greenscreen footage.

The use of CGI in the training data allows the input image and mask to be perfect without having to spend hundreds of hours creating that data. It's also easier to modify and create variations to test different cases such as reflective or soft edges.

Thus, you have the greenscreen input footage, the expected processed output and alpha channel mask. You can then apply traditional neural net training techniques on the data using the expected image/alpha channel as the target. For example, you can compute the difference on each of the alpha channel output neurons from the expected result, then apply backpropagation to compute the differences through the neural network, and then nudge the neuron weights in the computed gradient direction. Repeat that process across a distribution of the test images over multiple passes until the network no longer changes significantly between passes.

Here's the post: https://www.anthropic.com/engineering/building-c-compiler. It was written by a researcher at Anthropic.

AI assisted coding is really good as an enhanced auto-complete, often better as it picks up patterns in the code and will complete whole lines or chunks of code. There, I'll assess the results like any other auto-completed suggestions.

For other things like when asking questions I won't just blindly copy what the LLM is suggesting. I'll often rewrite it in a style that best fits the style of the codebase I'm working on, or to better fit it into what I'm trying to achieve. Also, if I've asked it for how to do a specific one-line query and it has rewritten a whole chunk of code, I'll only make use of that one line, or specific fix/change. -- This also helps me to understand the response from the LLM.

I'll then do testing to make sure that the code is working correctly, with unit tests where relevant.

I'm not in the US, but have listened to various of their tiny desk concerts that they put up on YouTube.

MathML is used a lot in standards/publishing, such as with JATS and EPUB. MathML is also natively supported in the HTML specification.

For those who don't get the joke -- https://en.wikipedia.org/wiki/Destroying_angel (destroying angel mushroom)

He looks at the religious statues in the corner and says "the last of your lot ended up destroying Angels!"

Oskar Stålberg used wave function collapse for various games, including Townscaper. He talks about it here: https://www.youtube.com/watch?v=Uxeo9c-PX-w&pp=ygUhdG93bnNjY... (SGC21- Oskar Stålberg - Beyond Townscapers).

Customizable snipping is a feature editors support (which I mentioned as they are related/similar to what the AI is doing), but is different to the AI autocomplete behaviour.

If I have a JSON structure, I can paste that into the file as a comment, e.g.:

    # {"foo": 1, "bar": "test", "baz"}
    @dataclass
    class FooBar:
        foo:

and the AI will/can autocomplete/generate that to:

    @dataclass
    class FooBar:
        foo: int
        bar: str
        baz: int

using the JSON example. Then if you type:

        def __str__(self):

the AI could then contextually generate, e.g.:

    return f'Foo(foo={self.foo}, bar={self.bar}, baz={self.baz})'

Or if you have a SQLAlchemy model:

    class Foo(Base):
        __tablename__ = 'foos'

    bar_id: Mapped[int | None] = mapped_column(ForeignKey('bars.id'), default=None)

typing `bar:` the AI can autocomplete:

    bar: Mapped[Optional['Bar']] = relationship()

picking up that you have a `Bar` class in the file. Especially if you have other similar id/object definitions in the file.

Text editors/IDEs have simple autocomplete and the ability to do some expansion, e.g. a for loop with placeholders to fill in. Those work and are still useful.

JetBrains also has local line-based LLM models for various languages.

With the LLM-based autocomplete it a) generally autocompletes more code at once, and b) will often pick up on patterns in the existing code. E.g. if you have a similar method, list of print/string buffer write statements, or other repetitive code in the file it will often use that as a model for the generated code.

I don't use AI for the sake of it, I use it where and when it is useful. For example:

1. advanced autocomplete -- if you have or paste the structure of a JSON or other format, or a class fields, it is good at autocompleting things like serialization, case statements, or other repetitive/boilerplate code;

2. questions -- it can often be difficult to find an answer on Google/etc. (esp. if you don't know exactly what you are looking for, or if Google decides to ignore a key term such as the programming language), but can be better via an AI.

Like all tools, you need to read, check, and verify its output.

XML is used a lot in standards and publishing industries -- JATS, EPUB, ODF, DOCX/XLSX/..., DocBook, etc. are all XML based/use XML.

Now move all the services and accounts you have registered to that account, along with all the friends and family who have your old email account.

Ah yes, that's what I was thinking of. It's been a while since I've worked with COM.

COM is interesting as it implements interfaces using the C++ vtable layout, which can be done in C. Dynamic COM (DCOM) is used to provide interoperability with Visual Basic.

You can also access .NET/C# objects/interfaces via COM. It has an interface to allow you to get the type metadata but that isn't necessary. This makes it possible to e.g. get the C#/.NET exception stack trace from a C/C++ application.

It's also useful to wrap/tag IDs in structured types. That makes it easier to avoid errors when there are multiple type parameters such as in the Microsoft graph API.

The text doesn't use an `f`. If you copy from e.g. the 1700 passage you get `ſ` not `f`.

I can comprehend most of the text back to 1300, if slower than Modern/Present Day English. It helps to know the old letter forms, and some of how Shakespearean (Early Modern), Middle, and Old English work. It also helps sounding it out.

Past that, I'm not familiar with Old English enough to understand and follow the text.

Simon Roper has a spoken equivalent for Northern English -- https://www.youtube.com/watch?v=90Zqn9_OQAw.