victorNicollet

Isn't the ¨ (U+00A8) character equivalent to an umlaut on a space?

I suppose you used ◌̈ (U+0308).

The atmosphere is estimated to have ~830PgC worth of CO₂, and plants are estimated to photosynthesize ~120PgC worth of CO₂ every year, so a given molecule would have 14% chance to be broken down in a year. The probability to survive for 2000 years would be around 1e-60.

Of course, CO₂ contents of the atmosphere have varied over the last 2000 years, and not all CO₂ is produced into or consumed from the atmosphere (it can be dissolved in surface water, etc).

EDIT: since there's much more O₂ than CO₂ in the atmosphere, a given O₂ molecule has a 8% chance to not be broken down by respiration over 2000 years.

I have seen the similar assertion "some of the water molecules you drank today were once part of a dinosaur", which is false because water molecules do not last very long when in liquid phase (they continuously swap protons, turning into hydronium ions and back).

The O-O and N-N bonds are much stronger than H-O bonds, but there are still atmospheric processes that can break them. For instance, O2 undergoes photodissociation under ultraviolet light and recombines into O3 ozone, and N2 likely also undergoes photodissociation. And obviously, the fact that living beings breathe O2...

We are using binary formats in production, also for data visualization and analysis. We went for a simple custom format: in addition to the usual JSON types (string, number, array, boolean, object), the serialized value can contain the standard JSON types, but can also contain JavaScript typed arrays (Uint8Array, Float32Array, etc). The serialized data contains the raw data of all the typed arrays, followed by a single JSON-serialized block of the original value with the typed arrays replaced by reference objects pointing to the appropriate parts of the raw data region.

For most data visualization tasks, the dataset will be composed of 5% of JSON data and 95% of a small number of large arrays (usually Float32Array) representing data table columns. The JSON takes time to parse, but it is small, and the large arrays can be created in constant time from the ArrayBuffer of the HTTP response (on big-endian machines, this will be linear time for all except Uint8Array).

For situations where hundreds of thousands of complex objects must be transferred, we will usually pack those objects as several large arrays instead. For example, using a struct-of-arrays instead of an array-of-structs, and/or by having an Uint8Array contain the result of a binary serialization of each object, with an Uint32Array containing the bounds of each object. The objective is to have the initial parsing be nearly instantaneous, and then to extract the individual objects on demand: this minimizes the total memory usage in the browser, and in the (typical) case where only a small subset of objects is being displayed or manipulate, the parsing time is reduced to only that subset instead of the entire response.

The main difficulty is that the browser developer tools "network" tab does not properly display non-JSON values, so investigating an issue requires placing a breakpoint or console.log right after the parsing of a response...

I would say 4. grab individual code files (as opposed to entire libraries) and manually edit them, removing unnecessary features and adding new ones where needed.

Tree-shaking is able to remove code that will never be called. And it's not necessarily good at it: we can detect some situations where a function is never called, and remove that function, but it's mostly the obvious situations such as "this function is never referenced".

It cannot detect a case such as: if the string argument to this function contains a substring shaped like XYZ, then replace that substring with a value from the environment variables (the Log4j vulnerability), or from the file system (the XML Entity Extension vulnerability). From the point of view of tree-shaking, this is legitimate code that could be called. This is the kind of vulnerable bloat that comes with importing large libraries (large in the sense of "has many complex features", rather than of megabytes).

The snippet you shared is consistent with the kind of output I have also been seeing out of LLMs: it looks correct overall, but contains mistakes and code quality problems, both of which would need human intervention to fix.

For example, why is the root object's entityType being passed to the recursive mergeEntities call, instead of extracting the field type from the propSchema?

Several uses of `as` (as well as repeated `result[key] === null`) tests could be eliminated by assigning `result[key]` to a named variable.

Yes, it's amazing that LLMs have reached the level where they can produce almost-correct, almost-clean code. The question remains of whether making it correct and clean takes longer than writing it by hand.

We use the following steps:

- Each service listens on a different, fixed port (as others have recommended).

- Have a single command (incrementally) build and then run each service, completely equivalent to running it from your IDE. In our case, `dotnet run` does this out of the box.

- The above step is much easier if services load their configuration from files, as opposed to environment variables. The main configuration files are in source control; they never contain secrets, instead they contain secret identifiers that are used to load secrets from a secret store. In our case, those are `appsettings.json` files and the secret store is Azure KeyVault.

- An additional optional configuration file for each application is outside source control, in a standard location that is the same on every development machine (such as /etc/companyname/). This lets us have "personal" configuration that applies regardless of whether the service is launched from the IDE or the command-line. In particular, when services need to communicate with each other, it lets us configure whether service A should use a localhost address for service B, or a testing cluster address, or a production cluster address.

- We have a simple GUI application that lists all services. For each service it has a "Run" button that launches it with the command-line script, and a checkbox that means "other local services should expect this one to be running on localhost". This makes it very simple to, say, check three boxes, run two of them from the GUI, and run the third service from the IDE (to have debugging enabled).

Indeed. Worst week of 2023 !

But I consider myself lucky that the issue could be reproduced on a local machine (arguably, one with 8 cores and 64GiB RAM) and not only on the 32 core, 256GiB RAM server. Having to work remotely on a server would have easily added another week of investigation.

One of the hardest bugs I've investigated required the extreme version of debugging with printf: sprinkling the code with dump statements to produce about 500GiB of compressed binary trace, and writing a dedicated program to sift through it.

The main symptom was a non-deterministic crash in the middle of a 15-minute multi-threaded execution that should have been 100% deterministic. The debugger revealed that the contents of an array had been modified incorrectly, but stepping through the code prevented the crash, and it was not always the same array or the same position within that array. I suspected that the array writes were somehow dependent on a race, but placing a data breakpoint prevented the crash. So, I started dumping trace information. It was a rather silly game of adding more traces, running the 15-minute process 10 times to see if the overhead of producing the traces made the race disappear, and trying again.

The root cause was a "read, decompress and return a copy of data X from disk" method which was called with the 2023 assumption that a fresh copy would be returned every time, but was written with the 2018 optimization that if two threads asked for the same data "at the same time", the same copy could be returned to both to save on decompression time...

The trouble is, darklaga.bin will not work locally because it must be fetched over an HTTP(S) connection. So, there's a darklaga.local.html provided when running locally. The build sequence is "npm run pack" then "npm run build", after which darklaga.local.html should work.

Yes, ship offset from touch point was an intentional 2024 change. In the 2004 version, touch screens used a stylus, which were thin enough that you could see whatever you were touching, so the player's ship was centered on the stylus point of contact. With a finger, it's much harder to see...

For Safari, I ended up having to investigate a crash on iOS Safari specifically, because it did not happen on Mac Safari.

I considered itch.io but I am still undecided on the whole affair.

The square pattern enemies are a bug (well, level design mistake) back from 2004, where they would move outside the range of the laser but would still be within reach of other weapons.

I must admit, since I no longer have access to the level editor, I edit the level files with HxD :-)

On other browser/platform combinations I use fullscreen mode, which gets rid of the issue entirely. But it isn't supported on iOS Safari as far as I can tell.

Sadly I could no longer build the C++ version of the game because of some missing proprietary dependencies, but I don't expect there would have been noticeable improvements: it was already running at 60FPS on computers from the time, even in PocketPC emulation mode.

I agree ! We use the commit status instead of the PR status. A non-FF merge commit, being a commit, would have its own status separate from the status of its parents.

I suppose our development process is a bit unusual.

The meaning we give to "the commit is green" is not "this PR can be merged" but "this can be deployed to production", and it is used for the purpose of selecting a release candidate several times a week. It is a statement about the entire state of the project as of that commit, rather than just the changes introduced in that commit.

I can understand the frustration of creating a PR from a red commit on the main branch, and having that PR be red as well as a result. I can't say this has happened very often, though: red commits on the main branch are very rare, and new branches tend to be started right after a deployment, so it's overwhelmingly likely that the PR will be rooted at a green commit. When it does happen, the time it takes to push a fix (or a revert) to the main branch is usually much shorter than the time for a review of the PR, which means it is possible to rebase the PR on top of a green commit as part of the normal PR acceptance timeline.

Wouldn't CI be easier with a monorepo ? Testing integration across multiple repositories (triggered by changes in any of them) seems more complex than just adding another test suite to a single repo.

I'm not familiar with GitHub Actions, but we reverted our migration to Bitbucket Pipelines because of a nasty side-effect of conditional execution: if a commit triggers test suite T1 but not T2, and T1 is successful, Bitbucket displays that commit with a green "everything is fine" check mark, regardless of the status of T2 on any ancestors of that commit.

That is, the green check mark means "the changes in this commit did not break anything that was not already broken", as opposed to the more useful "the repository, as of this commit, passes all tests".

Avoiding SQL migrations was my #1 reason for moving to event sourcing.

This approach cuts the "database server" into an event stream (an append-only sequence of events), and a cached view (a read-only database that is kept up-to-date whenever events are added to the stream, and can be queried by the rest of the system).

Migrations are overwhelmingly cached view migrations (that don't touch the event stream), and in very rare cases they are event stream migrations (that don't touch the cached view).

A cached view migration is made trivial by the fact that multiple cached views can co-exist for a single event stream. Migrating consists in deploying the new version of the code to a subset of production machines, waiting for the new cached view to be populated and up-to-date (this can take a while, but the old version of the code, with the old cached view, is still running on most production machines at this point), and then deploying the new version to all other production machines. Rollback follows the same path in reverse (with the advantage that the old cached view is already up-to-date, so there is no need to wait).

An event stream migration requires a running process that transfers events from the old stream to the new stream as they appear (transforming them if necessary). Once the existing events have been migrated, flip a switch so that all writes point to the new stream instead of the old.

> Onion architecture etc. is a long-term strategy that mainly benefits the company/project owner, but not the individual contributor. So it basically has to be forced upon programmers, who will resist it in every way possible, because they have no real incentive to use it.

Although I was aware of it for a while now, I had never seen this misalignment (between what I called ease-of-writing and ease-of-maintenance) stated so clearly in so few words. Thank you !

I have created a DSL for supply chain optimization over the last 10 years[1], and gave a talk about it back in 2017[2] that summarizes the main reasons why we did this over the alternatives (such as using Python).

We measure success along a few indicators:

- Ease of deployment of an optimization model to production

- Training time required before a new employee (with a background in Supply Chain, but no software development experience) is proficient enough to contribute new code and edit existing code.

- Cost of running all the execution infrastructure

- Frequency of defects caused by running out of memory

- Frequency of package version upgrades that require manual intervention

- Frequency of unsuccessful attempts at auto-completion and other Language Server Protocol interactions

1: https://docs.lokad.com/ 2: https://www.youtube.com/watch?v=_gmMJwjg0Pk

I'm a maintainer for an open source .NET library that, ironically, only exists because it provides a feature that Microsoft removed from .NET during the migration to .NET Core.

Very rarely have I needed a library to solve a problem, and found that a library from Microsoft was even available at all.

AspNetCore is its own world inside the greater .NET universe. It is a web framework with a "batteries included" philosophy, and it's not unusual for users of those to want all their use cases covered by the framework itself. The original article laments AspNetCore introducing its own dependency injection system, but this is par for the course in languages that care about dependency injection (see PHP's Laravel and Symfony, or Java's Spring). As for AspNetCore developers only knowing Entity Framework, the same argument could be made about 'db' in Django or 'ActiveRecord' in Ruby on Rails.

The philosophy of "It is good that I no longer have to use a separate tool for what should have been a feature of my framework" is understandable, and it's a bit disingenuous to describe it as "It is good that I have fewer choices available to me"

And it's also a bit disingenuous to describe AspNetCore users commenting on an AspNetCore feature announcement in the AspNetCore GitHub repository as ".NET Developers".

In a situation where I'm adding a new feature to the language, with a new syntax that causes me to add a new rule to the grammar, I'm concerned that the new rule will accidentally "capture" some code that already exists in the wild, that was previously derived by another part of the grammar.

To give a very ugly example, if you have a language with function calls f(expr, expr, expr) and you want to add tuple syntax to expressions with a brand new rule:

  expr := expr COMMA expr

Then you might have accidentally turned all functions into unary functions, as the tuple rule captures the "expr, expr, expr" part and leaves you with f(expr).

The host language is the language that you are using to write the compiler/interpreter. I suppose the grandparent is asking the question in order to recommend a parser generator for your use case. From your GitHub profile, I assume it's JS or TypeScript ?

I am a bit biased (in the sense that I wrote my own SLR parser generator twice, in C# and F#!), but the benefit of LR is that you can know whether your CFG contains conflicts, which is a game changer for preserving backwards compatibility when you change the syntax later during the life of the DSL.

But if a parser combinator library may support converting the resulting combined parser into an eBNF grammar, and check whether that grammar contains conflicts.

Not having ambiguities is actually the main selling point of PEGs. If you have two rules A and B that can both match the input, then a CFG A|B has an ambiguity (two possible derivations), but a PEG A/B explicitly says that the A derivation is chosen. The good part is that unlike a CFG, the PEG doesn't require you to go and fix anything (the / operator already did that for you). This makes the initial implementation of the grammar easier.

On the other hand, if you already have code in the wild that uses the old grammar G1, and in order to add new features, you introduce a new grammar G2 that is a superset of G1. You need to know if any of the existing code has a derivation in G2 that is different from its derivation in G1 (as that would cause backwards incompatibility). With a PEG, there's no way to tell, so you have to check this by hand (and mistakes are easy). With a CFG, you know that backwards incompatibility happens if and only if G2 has conflicts, and those conflicts are precisely the cases that are not backwards compatible.

Yes, something like ANTLR for Java, or the entire list here: https://en.wikipedia.org/wiki/Comparison_of_parser_generator...

I've had good experiences with Menhir (for OCaml) and Tree-sitter, and implemented my own SLR parser generator for C# https://github.com/Lokad/Parsing

In the end, what matters is that they should be able to report conflicts and ambiguities.

I would say JSON + schema, rather than just JSON. Like S-expressions, JSON saves you from having to implement a tokenizer, and a tokenizer is one of the easier parts of a DSL. You still need to implement something like a syntax, because things that are handled by the syntax now get pushed into later stages of the DSL. However, if you can provide a JSON schema for your language, then the problem is mostly solved !

On the other hand, it's not enough to read JSON, you need a JSON parser library that provides you with the position (line:column) of every JSON value, so that you can emit user-friendly errors.

This is definitely the best idea for "drop down" DSLs (by drop down, I mean that you are working in a general-purpose language and then, for one specific situation, you drop down into the DSL because it is more productive).

I think the article is more oriented towards standalone DSLs (where the entry point is the DSL itself), as those get actual maintenance benefits from not being able to invoke arbitrary code in the host language.