> What is the main plus you have over other similar projects or tools like JSLinux?
Good question! I had to do some research. Here's my understanding:
JSLinux is emulates a complete machine architecture. JSLinux runs in the browser's Wasm runtime, and JSLinux programs run on JSLinux. Both Kandelo's kernel and processes run directly in the browser's Wasm runtime, with the kernel fielding syscalls from processes. Kandelo does not emulate CPUs.
Pre-existing software can run on JSLinux, but software must be rebuilt to run on Kandelo.
Given the lack of CPU emulation, I would expect Kandelo to be more efficient than JSLinux, but for completeness, it's hard to beat JSLinux's actual system emulation.
> Which preprocessor directives can I expect to have if I need to write custom code when my executable is compiled for Kandelo?
In general, we intend user software to be buildable by using standard C/POSIX macros with the Kandelo SDK. Does that answer your question?
> What is the reason for choosing GPL instead of MIT or similar?
We have a mix of GPL and MIT licenses in this project. For software that is not linked with with user programs, we choose the GPL so that folks may build upon our work but cannot make it closed source. Software that links with user programs is intentionally MIT-licensed to avoid forcing user software into the GPL.
I tried my personal blog that has this kind of sitemap https://zaerl.com/sitemap.xml, like all other blogs found on wordpress.com. Do this tool support sitemapindex nodes?
Yes, it supports any website. I manually tried yours, and as I understand, you don't have any articles in the blog. The system works automatically, looking for a blog, article, or something similar. Then create a list of articles, and you can sync it to Substack all at once or by a schedule.
I got something mixed up. I double-checked it again. Your blog patterns are bit different, I just didn’t think about that and didn’t support them. I’ve added support now and redeployed it try again?
> 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.
(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.
Don't take my comment as dismissive of your project.
The people using it will probably have an easier time navigating Unicode text than they would have if they had used other existing libraries or tried to roll their own.
It's more a comment on the users who need to be warned that "no, you probably don't want your C program to know if that string actually fits in the 80 column terminal".
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.
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.
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.
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?