mORMot Open Source

@mpv
Could you please include FastMM4 in your tests? It also works on Linux with FPC and might give an indication on how much it improved compared to the 'normal' version

Better let him focus on finishing mORMot2

But I'm really impressed on how fast you wrote a new memory manager.

rofl, that was the biggest trap you could fall in! Hopefully all people worked/working on/for Delphi are still paid from your Delphi 7 license. *faceplam* Just read point 3 again from johnnysynop.

It just shows the bad mentality of you guys, still using Delphi 7 (= nothing paid for 20 years) and then also demand to use the free mORMot but making money with the product build with it. Typical business mo******** - take everything for free but never give anything back.
You should give ab all the money you saved the last 20 years + 1.000.000€ because he is such a fantastic guy who is a real plus for the FPC/Delphi community.

And btw Delphi7 should fully work with FPC (that was their main target years ago...). Its also free so absolutely your thing.

Now back to FastMM5. Some more background infos are here and opinions are here.

iOS also fully functional?

2. I separated my program into "sections" so that it's a bit more sorted in the current logging mechanism I use.
output line looks like: <time> <threadid> <section> <log level> <text message>
3. Yes, I saw that there are a lot levels defined in TSynLogInfo but it's not fully clear to me what they exactly do. E.g. sllExceptionOS will log all exceptions which occur inside this function OR should it be used by me if I log an exception which was caught by a try..except block? Same for sllTrace which says "will log low-level step by step debugging information" but don't know what that exactly mean as output.
5. Yes, I meant for timing purposes only (to find bottlenecks e.g.) That's why I asked about 1. and if the code stills needs to be like that for FPC.

I think NewPascal is not deprecated, it's dead.
The guy behind it (Maciej Izak?) left the FPC/Delphi community completely or?

Some forum posts sound more like months than weeks.

I think the issue on mORMot2 project about creating only a new branch is a good advice!
I mean, you can still start from 0 on the new branch and if your finished you fork the current master branch to mormot-old and delete the master branch. After that your new mormot2 branch gets renamed to master branch.
All stars, follower etc will remain but you achieved the same result as with creating a new project

Maybe adding an EditorConfig (https://editorconfig.org/) file would also be good for people who use the web IDE to submit small patches or Lazarus/Visual Studio Code.

Maybe 'split' it into subfolders for easier use and not having 500 files in a single dir. If someone just needs the JSON part, he just takes the JSON folder. If the needs the PDF stuff, take the PDF folder. (Maybe also a core or common folder with global defines etc but should be as small as possible and not like 2mb as the SynCommons.pas now )

EDIT: I think you can also reference other projects in your github project - so you don't need to move everything into one big project. When you do 'git clone' then it gets also the latest version for SynPDF e.g. Might be easier for error reporting if it's only related to JSON and not to the fully mORMot project

Sounds good to me!

Splitting the huge units into smaller ones is a very good idea - maybe splitted into use cases (JSON, Converters, Helpers, ...). Then one could also pick only specific (small) units for other projects like your fast TDictionary implementation.
If you want to support only newer compilers (I'm happy with that - no need to support 10+ year old compilers and work-around bugs/missing features etc all the time) you could use units with dots (no idea which Delphi versions support it): SynCommons.JSON, SynCommons.Converter, etc.
Supporting newer compilers only would probably also remove a lot of code and IFDEFs :-)

I was focussing on the client-side and meant something like Indy's TIdTCPClient which uses the platform APIs so that you don't need to include 3rd party libraries.
I know that mORMot's goal in something different (ORM!) but would be a nice to have to create TCP connection with TLS support - then I can completely replace Indy with mORMot

You missed the most important thing of OpenSSL 1.1.1 - TLS v1.3

TLSv1_3_method: function: PSSL_METHOD; cdecl;

and also

TLS_method: function: PSSL_METHOD; cdecl;

Otherwise very good work!

Unfortunately mORMot doesn't have TCP/UDP sockets + HTTP support with gzip because then I could get rid of Indy -.- mORMot is well maintained compared to some other libs...

So you mean the call to

mORMot.TSQLRecord.CreateAndFillPrepare($7FF4FDD4BBF0,'SrcRec = ? AND DstRec = ? AND SectRec = ? AND FileRec = ?',(...),'ID')

should be made with PtrInt(SrcRec) instead of SrcRec.AsTSQLRecord?

Could you please explain how it finds the ID inside the DB through the address pointer of a variable?

No because its also running on Linux where static linking isn't supported but the same issue with deadlock occur.

Intel syntax shouldn't be a problem any more because GNU Assembler supports it.
"However, since version 2.10, Intel syntax can be used through use of the .intel_syntax directive."

Maybe the best thing is if you could ask on the fpc-devel mailing list? Then it could also be figured out which license is needed etc.
But to be honest, I don't see why patches for optimizing often used functions should be rejected (assume tests for these functions are already there to prove that changes don't break anything).