Leaderboard

Maybe one of the first things somebody could contribute, are English translations of the comments then. 😉

The MPL only requires you to provide the sources that are licensed under the MPL, unless you modify the original. In that case you must also make those modifications available. It does not require you to make the sources of your program available. It also doesn't matter whether or is linked into the executable or called as a DLL, so no need to isolate it as a DLL. (Disclaimer: I'm not a lawyer. This is how I understood the license text.)

Would be nice if you translate all your comments in English.

Did you follow the instructions in the ReadMe.txt file?

thanks for the kind answer

Yes, I have an implementation for it, and a while ago was seeking people to try it out. I haven't done anything to it for a while, however I have attached the work-in-progress to this reply. The plan is to include the final result into Kastri: https://github.com/DelphiWorlds/Kastri AppleSignin.zip

The work on https://github.com/EtheaDev/SVGIconImageList continues, many issues have been solved. Now it's possible also to use native VirtualImageList (from 10.3 or 10.4) linked to a TSVGIconImageCollection! If you have an older Delphi version you can use TSVGIconsVirtualImageList. With the help of VincentParrent and pyscripter the components and the SVG library improve day by day ... Stay tuned!

... well - if this is really what you want, you should rethink your discussion-style. For me your last post is quite offensive. It is not the first time we (have to) talk about this.

If the memory pages are swapped on disk, then indeed it will be slow to dereference the pointer. But in this case, the application is very badly designed: paging on disk should be avoided in all cases, and direct disk API calls should be made instead to flush the data. The problem is not the use of the MM. The problem is the whole memory allocation design in the application. Less memory should be allocated. This is what @David Heffernan wrote, and you didn't get his point about swapping. If the memory page is not on disk - then you may have a cache miss when the pointer is dereferenced. For big memory blocks, it won't hurt. Calling VirtualFree will take definitively much more CPU than a cache miss. So I still don't find the relevance of your argumentation. Last but not least, the article you quoted (without any benchmark and code to prove the point) is very specific to the memory use of a database engine, which claims to be the fastest on the embedded market. I doubt everytime I read such claim, and I don't see actual code. More like technical marketing arguments than real data. Raima DB features "needing 350KB of RAM" and "optimized to run on resource-constrained IoT edge devices that require real-time response". So what is the point of benchmarking handling of GB of RAM? The whole https://raima.com/sqlite-vs-rdm/ is full of FUD. The graphs are a joke. Since they don't even show the benchmark code, I guess they didn't even use a fair comparison and use SQLite in default mode - whereas with exclusive mode and in-memory journal, SQLite3 can be really fast. We have benchmark and code to show that with mORMot - https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_60 and https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITLE_140 (current numbers are even higher). You may have to find better references.