program

I saw an interesting article posted here on HN about Go's Swiss Tables implementation. I'm writing a small C library to use them for fun, so you can use any byte array as a key. Either a C string, a number, a bool, etc.

I really like this. I think the possibilities are multiple. I will try it to test the generic POSIX compliance of my main hobby project.

What is the main plus you have over other similar projects or tools like JSLinux?

Which preprocessor directives can I expect to have if I need to write custom code when my executable is compiled for Kandelo?

What is the reason for choosing GPL instead of MIT or similar?

I don’t use Windows, but I like it. What are the characteristics that distinguish this from the other popular solutions that already exist?

> A producer making thousands of wheels annually is therefore sitting on an enormous and steadily growing asset that generates no cash whatsoever, while facing continuous bills.

Once a company enters a steady flow, usually after the first 2-3 years, this is not a problem because it has the income of previous years. The only thing that changes is the difference in the company's turnover.

This type of loan is not new, it has existed for more than 70 years. There’s something similar for wine, prosciutto, oil and other types of cheese.

Feel free to do it. You can find the amalgamation appended to GitHub releases.

Keep in mind that I appreciated your comment. My library has a very narrow target

There is an MJB_FEATURE_CHARACTER_NAMES option you can set to zero if you don't want to have a function that returns the name of a codepoint, such as "LATIN SMALL LETTER E WITH ACUTE". This is something that probably most people do not need at all. This shrinks "Hello World" macOS ARM executable from 937KB to 663KB.

I should probably offer other runtime options so users can literally strip away everything they don't need. For example, as you suggested, measuring whether a string is less than 80 columns is something you don't do every day.

(Author here) Dealing with encodings is already a big step when you aim to handle multiple ones and multiple OSes. You can see what I am talking about in the tests/ folder.

With Mojibake, I wanted to help people handle text by providing the smallest possible C/C++ library, without requiring them to use a +20MB library just to normalize a string, handle a flag emoji, or perform similar tasks.

See the CONFORMANCE_REQUIREMENTS.md file if you are interested in what the +17 versions of the Unicode standard have introduced.

Mojibake is a C library, not Python, so comparing the two isn't ideal. You can see the performance in the GitHub workflows results. At the end of the logs, there is an "execution time" line.

Mojibake is a Japanese term, and yes, it's used there when a page displays a lot of gibberish text. I chose it for fun.

Thank you very much. I've also started writing a smaller C++ wrapper so the user can use std::string_view for this, but I'm not the best C++ guy out there.

Mojibake handle UTF-8, UTF-16, UTF-16LE, UTF-16BE, UTF-32, UTF-32LE, UTF-32BE in input and output. Can be used as a simple file and handle a wider number of algorithms, such as the "confusable" one.