Good First Issues in Pascal

OpenCV 5 was recently released, the first major release in 8 years. The project published a migration guide here. I self-compiled the 5.0 release on my Linux PC to test if USDX is compatible with it. The configure script was able to find my self-compiled OpenCV 5.0 libraries, the C wrapper library compiled without issue, and the game seems to run fine with it. So that is good news. However, the configure.ac still needs some updates to provide proper support for OpenCV 5. The C++ compiler now needs to support the C++17 standard instead of C++11. The configure.ac needs to detect if OpenCV 4.x or 5.x is installed, and check for the correct C++ standard depending on version. It currently checks for C++11 only. The Linux AppImage will be blocked from upgrading to OpenCV 5 unless we upgrade the OS that builds it. Due to the C++17 requirement, OpenCV 5.0 needs GCC 8, but only GCC 4 is available. The pkg-config file name for 5.x is now opencv5.pc. The fallback pkg-config detection method in co

Is your feature request related to a problem? Please describe. Minimal hand strain layouts have been a long-time goal for every script. However, the exact ergonomics behind layout and handstrain are not well known and can be difficult to research. Keyman could assist here by encoding rules of key position, letter frequency, and muscle fatigue to generate optimized layout templates for keyboard designers to work with (primarily for touch layouts). A fascility like this woudl be particularly helpful for new scripts that are not encumbered by a QWERTY legacy. Describe the solution you'd like The carpalx website provides informational and programming resources on keyboard layout optimization that can be used to generate optimized templates. Under such an approach, a Keyman lexicon would be needed with word frequencies, from which letter frequencies can be calculated. These letter frequencies, combined with the layout and hand strain minimization rules of the carpalx algorithm, can then be

Hi, We’ve been using mORMot since version 1.18. We’ve successfully ported our codebase to mORMot 2 and have gradually become more proficient with the library. We initially started using mORMot for its object dispatching capabilities across different web services and standards. The “35 - Practical DDD” demo was very useful in demonstrating the value of mORMot beyond the ORM itself. However, we really wanted to use mORMot’s ORM for its own sake, because it makes implementing repositories incredibly fast. The historical issue we faced is that our database is designed without integer ID columns, and instead relies on UUIDs, for specific reasons such as easier data replication. As we became more familiar with mORMot’s internals, I discovered that we could actually use the ORM for our needs (mostly repositories and CreateJoined) with only a very minor tweak—literally a single line of code. We had always assumed that we needed to redesign our foreign keys from UUIDs to integer I