If every project requires its own username/password just to report a bug, I may do that for the first 2 or 3, but not for every project. I'm also unlikely to create accounts on hosting platforms I don't intend on using outside of reporting the single bug.

> “No, reprobate! you are a castaway—be off, or I’ll hurt you seriously! I’ll have you all modelled in wax and clay! and the first who passes the limits I fix shall—I’ll not say what he shall be done to—but, you’ll see! Go, I’m looking at you!”

-- Wuthering Heights (1847), Chapter 2, Emily Brontë.

I wonder what the frequency of AI common words like delve and other words/phrases are in Project Gutenberg, Wikipedia, and other collections.

1. created by LLM agents -- any vibe-coded projects;

2. mainly written and maintained by LLMs -- this would cover the recent changes to the rsync project;

3. tied to the LLM ecosystem -- this covers pytorch, llama.cpp, cursor, SillyTavern, AI skills repositories, and a whole host of other projects.

I worked around it to some extent by having an organisation per category, but that doesn't work at scale. For example, you can't group Text-to-Speech projects around the different libraries (coqui-ai, Qwen3, parler, etc.), or language tooling installation scripts by programming language. -- Those have a group/subgroup/repository style structure.

The other related feature is having organisation or group-level issues and corresponding tracking features.

Gitolite doesn't impose/enforce a structure on the user. GitWeb/CGit have a free-form category (e.g. "lang/python") that the project can be assigned to. That works, but I'd like it to support multiple tags/labels for that.

1. Do you want something that works and feels like GitHub? -- Forgejo and Gitea are good for this.

2. Do you want a place to host git repositories with minimal hassle? -- GitLab, CodeBerg, and others are available.

3. Do you have your own hosting infrastructure? You could use gitolite and CGit/GitWeb on that hosting platform or local hardware.

4. Do you just want to host repositories? -- Gitolite can be used to help with SSH/auth/repository creation, and CGit or GitWeb for the frontend.

5. Do you need something like GitHub Actions? -- GitLab, Forgejo, and Gitea offer CI, or use external CI infrastructure.

6. Do you need issue tracking and management? -- GitLab, Forgejo, and Gitea provide these. There are alternatives from Jira to Kanban (including Trello) to Markdown (Obsidian and others) and more.

There are tools like promptfoo designed for this.

There's only so much you can do -- making reasonable assumptions, choosing suitable data structures, database indices, testing various workloads, etc. -- in a limited test environment.

You may spend a week optimizing a feature that only 10 people use or that never gets to the point where it becomes an issue. Or you may have something that can't easily be tested at scale, such as various counts or other dynamic data that are determined by complex queries that you may (likely) find you need to cache but don't necessarily know which values will become issues until you start using the system.

Likewise, improving performance pushes the limit at which performance regressions happen allowing more data (documents, triangles/pixels, etc.) to be processed. This allows things like more complex game graphics. That in turn makes it harder to improve performance for the next round (more advanced triangle/face culling and pre-processing).

There can also be trade-offs with things like data layout, memory usage (caching and memoization), or implementation. For example, when processing XML/HTML data you could use DOM (more memory and upfront parsing, but easier to perform complex queries across the data), SAX (less memory, but more complex to process due to tracking state), or reader API (similar to SAX but a different processing model).

There can be challenges with various features, such as type checking with higher-order generic types. Others add various levels of overhead, such as parsing a program, constructing an AST (Abstract Syntax Tree), generating an IR (Intermediate Representation), the optimization passes and final code generation.

JavaScript evaluation for example is complex. Before Chrome the approach was to use a slow interpreter. IIRC, Chrome was the first browser to introduce JIT (Just-in-Time) compilation, leading to faster JavaScript and eventually more complex applications running in that language. Modern browser JavaScript pipelines are complex in order to achieve and maintain performance:

1. start interpreting the code on the AST so it is run immediately (or only rely on (2));

2. generate a machine code equivalent of that interpreted code (for faster baseline performance);

3. run more aggressive optimizations on known types based on profiling/analysis for even faster performance, including special handling of things like asm.js.

[1] https://v8.dev/blog/ignition-interpreter

[2] https://benediktmeurer.de/2016/11/25/v8-behind-the-scenes-no...

[3] https://www.cs.cornell.edu/courses/cs6120/2020fa/blog/tracem...

[4] https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

There was an article or comment somewhere that said that when an LLM was prompted in comments/variable names about a complex algorithm or something like that in a very specific domain it was very knowledgeable. However, when given different names/terminology for the same thing it didn't understand the problem it was prompted to solve.

This is also why LLMs are good at generating code using Bootstrap, Tailwind or any other technologies as they can relate terms like `flex` and `grid` to various layout patterns. So using sensible names from the literature/specifications/etc. helps both developers and LLMs.

Or maybe -- just maybe -- using dashes isn't a sign of content being AI written, just a style it picked up from the training data.

For example:

    find . -type f | grep -P "/Math_Symbol\.js$"

The current GPUs are optimized for processing huge numbers of triangles per second. There are three things at play here:

1. the organization of the data being sent to the GPU to optimize throughput;

2. the speed at which the GPU can read that data from its VRAM;

3. how many triangles it can process in parallel by using individual compute units.

I suspect that given parallel improvements for neural networks, we'll see similar improvements:

1. optimizing the structure of the weights in the model for efficient access by the CPU/GPU/NPU/TPU;

2. efficient access of data strides (matrix rows) in the memory, e.g. being able to read multiple 2x2 matrix values in one clock cycle, or stepwise pairs of values (a(i,j), b(j,k)) needed for matrix multiplication;

3. parallel compute for matrix and tensor multiplication and other operations needed by neural networks.

1. Better hardware optimized for matrix operations and other ML/NN specific workflows (NVIDIA hardware, Apple M4/M5 chips, Intel AI Boost, other NPU/TPU chips, etc.).

2. Bigger RAM/VRAM/unified for loading models in memory -- with 3090/4090 you can run 22-24B models in VRAM; with 5090 you can run 30-32B models; with Apple hardware with 128GB unified RAM you can run 70-128B models.

3. Better quantization (smaller, better value representations/lower errors/loss, optimized CUDA/etc. kernels) will lead to larger models being able to be run on the lower VRAM hardware at (with optimized kernels) decent tokens/s.

4. Better optimizations in general taking advantage of the hardware (coupled with the hardware and driver advances) and the NN architectures (NOTE: I saw a huge performance boost a while back after upgrading my llama.cpp version).

5. Better model architectures optimized/designed for running on lower-spec hardware, like Mixture-of-Experts which make it easier to run on a single GPU or distribute the weights more efficiently across multiple GPUs (i.e. you know that specific weights will be used together so you can keep them resident on a specific GPU and not have to swap the weights in/out of the various GPUs or transfer intermediate results of a single layer, only the result from that block/expert).

5. Improved NVME or similar SSD technology which a) has a large amount of storage, and b) has access efficiency on par with RAM/VRAM, especially if/when coupled with efficient DMA access to the GPU/NPU.

I'm not sure if there are any regex libraries that support DSLs and easy composability (e.g. the email RFC regex would be easier to read/maintain if you could specify the individual parts like are defined in the RFCs).

There's a draft version of XSLT 4 that Saxon supports which adds more capabilities for working with map and array types.

There are a number of challenges that make browsers more challenging (even in memory safe languages like Swift and Rust).

1. Back references/pointers like `parentElement` to other objects in the graph that create dependency cycles (where traditional/simple reference counting will prevent the objects being deallocated).

2. Interacting with (and creating resources in) a garbage collector when running/evaluating JavaScript code.

3. Just-in-Time (JIT) compilation of JavaScript and other complicated interpretation-compilation pipelines that can allocate and transfer objects between the different stages.