opentype-shaping-documents VS Duktape

> The tangent in (1) on how they contradict unicode could have been skipped as well

Not only because confusables already exist, but also (as I already said[1] the previous time this was posted) covering all ligatures used in all typographical styles is very much a non-goal of Unicode. The official position is that the font shaping layer[2] sits atop Unicode’s semantic representation and is free to ligate, spindle, or mutilate it for display however it prefers (at least for Latin, Greek, and Cyrillic it’s a preference; other scripts can’t be rendered at all without doing it, such as Arabic—barring the legacy presentational forms—or Burmese[3]).

The only reason Unicode even has those ligatures is that some IBM encodings (which were more presentational in nature) encoded them, and IBM employees wrote a large part of the early standard (based on the decades of i18n experience they had at that point) and wanted roundtripping.

[1] https://news.ycombinator.com/item?id=29639966

[2] https://github.com/n8willis/opentype-shaping-documents

[3] https://r12a.github.io/scripts/mymr/my.html#combiningV

Im my projects I search for single file libs.(like https://github.com/svaarala/duktape etc...)

Use lrand48(), or better, implement a high-quality RNG like PCG or splitmix64.

You can also refer to the Unicode routines of other small JS engines[1,2], those don’t use ICU either, although the implementations are mercilessly size-optimized (to put it politely) and restricted to what the target JS version requires (e.g. casemapping but no normalization).

[1] https://github.com/bellard/quickjs/blob/master/libunicode.c

[2] https://github.com/svaarala/duktape/blob/master/src-input/du...

I was expecting this to be about Duktape <https://github.com/svaarala/duktape>, but heh, for sure no. I'd bet $1 there's no way youtube-dl would switch, but I wonder if yt-dlp would?

Fast math optimizations can break code like this by breaking isNaN.

I was porting a C++ project to a certain platform - and that platform enabled a -ffast-math equivalent by default in Release (but not Debug) builds! This broke duktape, a JS engine said project embedded, in some nasty and subtle ways. Instead of storing a number/pointer/??? (8 bytes) + type tag (4? bytes) for each dynamically typed JS value, duktape can bit-pack values into a single 8 byte "double" value by storing object/string handles as NaN values - this isn't an uncommon trick for dynamically typed scripting stuff:

https://github.com/svaarala/duktape/blob/c3722054ea4a4e50f48...

Naturally, the -ffast-math equivalent broke isNaN checks, which caused random object/string handles to be mistakenly reinterpreted as "numbers" - but only in Release builds, for this one particular platform, in one rarely taken branch, so neither QA nor CI caught it, leading to hours of manufacturing a repro case, stepping through an absurd amount of code, and then finally looking at the default build rules and facepalming.

Cursing the platform vendor under my breath, I overrode the defaults to align with the defaults of every other config x platform combination we already had: no fast math. If you want those optimizations, use SSE-friendly NaN-avoiding intrinsics - or, if you must use the compiler flags, ensure you do so consistently across build configs and platforms, perhaps limited to a few TUs or modules if possible. This allows you to have a chance at using your Debug builds to debug the resulting "optimizations".

Sure. For example, DukTape is an implementation of Javascript designed to be embedded in other projects. Google's V8 Javascript engine (used in Chrome), can also be embedded, see Node.Js for example.

- Duktape (4.8k stars)