#1 Re: mORMot 1 » Will mORMot be sponsored by Embarcadero? » 2020-05-23 15:05:30

But they are not saying how much you'll get. Seems more like you're doing advertisement for them and then you maybe get a few hundred euros which doesn't even reflect your work on your open-source project but they get several new customers due to your work and advertisement...
Would've been better if they say every project gets 5k so you'd know what to expect and if it's worth to do all the necessary steps.

#2 Re: mORMot 1 » Fast MM5 » 2020-05-12 21:56:07

mpv wrote:

FastMM4 not works under Linux with FPC x64 as expected - see https://synopse.info/forum/viewtopic.php?id=4330 (at last 1 year ago)

That could be the reason why we had issues with 32-bit FPC some time ago but those issues are gone since almost a year.
We use FastMM4 for FPC since 2017 or 2018 without problems (except the one issue which vanished after some time and compiler updates).

#3 Re: mORMot 1 » Fast MM5 » 2020-05-12 19:38:55

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 smile

#4 Re: mORMot 1 » Contributing to FPC » 2020-05-08 15:52:17

ab wrote:

Last time I checked, any attempt to provide some alternate asm to FPC x86_64 RTL (by Johannes IIRC) was a more or less rejected, for several reasons I don't remember well.
I am not even sure Intel syntax for asm is allowed... the FPC compiler tries to be compatible with external GAS IIRC, whereas mORMot doesn't.
This is why I didn't propose any change yet.

Using such critical code in mORMot first, as testing/validation, and not directly in the RTL is a safe idea anyway.

Anyone is welcome using my code and trying to push it to FPC trunk!
I could of course change the licence of this code to FPC if it helps.

If it works, then I could try to provide a lot of more tuned asm for the most used part of the RTL for x86_64, e.g. for string/array process.

Check https://bugs.freepascal.org/view.php?id=37039 for more infos smile
Seems they're open to accept patches with optimized assembly.

#5 Re: mORMot 1 » Fast MM5 » 2020-05-08 01:08:38

macfly wrote:

Any chance of integration with mORMot 1.18?

Better let him focus on finishing mORMot2 smile

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

#6 Re: mORMot 1 » Questions about using TSynLog in own code » 2020-05-08 01:04:03

ab wrote:

1. No, FPC still has a more restricted scope for interfaces: you need a local ISynLog variable.
OR you can use a

with TSynLogDB.Enter do 

Can't it be fixed by using this SmartPtr implementation?
It would just need to be used internally when doing


#7 Re: mORMot 1 » Fast MM5 » 2020-05-05 23:15:33

Vitaly wrote:

While choosing words like 'bullshit', please, don't forget that in the context you're talking about somebody's job, life business, or hobby.

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. wink

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

#8 Re: mORMot 1 » Fast MM5 » 2020-05-01 17:56:19

They developed a new memory manager (made for multithreading and other new technologies) - why the hell should they aim to support your almost 20 years old Delphi version?
Switch to a newer version with much better code optimizations and you probably get a bigger performance boost than with a new memory manager.
Sorry but your claim to support Delphi 7 is the biggest bullshit I've read here (also for mORMot2).

#10 Re: mORMot 1 » Lazarus 2.0.8 & FPC 3.0.4 » 2020-04-24 21:56:39

AFAIK FPC got a lot new optimizations which require more bytes (bigger opcode) in the binary but are faster on the CPU. It also know new extensions like AVX etc.
I doubt that fpcupdeluxe adds anything suspicious to your compiler but you still can use the makefiles and build FPC with that.

#11 Re: mORMot 1 » Questions about using TSynLog in own code » 2020-04-24 21:50:21

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.

#12 mORMot 1 » Questions about using TSynLog in own code » 2020-04-24 12:37:21

Replies: 3

I'm thinking about replacing my current logging system with the TSynLog from mORMot as it has some features I'd like to have to get better information on what is going on.
It should work on Windows/Linux (Delphi+FPC) with giving the same informations if possible (like on exceptions, serialization of Objects, etc). I'm not interested in (internal) logs from mORMot as this works quite fine smile
My questions:
1. Is this code still needed for FPC or does it work in the same way as Delphi does?

procedure TMyDB.SQLExecute(const SQL: RawUTF8);
var ILog: ISynLog;  <-- still needed for FPC or fixed meanwhile?
  ILog := TSynLogDB.Enter(self,'SQLExecute');
  // do some stuff
end; // when you leave the method, it will write the corresponding event to the log

2. Is there a way to change the logfile output? In my current log system I've separated it into sections (GUI, USER, DOWNLOAD, etc), is there a way to add them into the log as well? It also writes the thread ID to the line so that it can be better traced.

20110325 19325801  +    MyDBUnit.TMyDB(004E11F4).SQLExecute
20110325 19325801 info   SQL=SELECT * FROM Table;
20110325 19325801  -    MyDBUnit.TMyDB(004E11F4).SQLExecute 

3. If I have different kinds of log levels will it always write the entry/exit (+ and -) of a function to the log? E.g. for errors I'd also like to know when it happens and don't need any other infos collected
4. Can the log level be changed on runtime?
5. Is it a good idea to put the Enter/Leave logging into each function or will it slowdown my program too much?
6. Is there anything else I should aware of?

Kind Regards

#13 Re: Free Pascal Compiler » FPC 3.2 rc1 » 2020-04-16 22:52:05

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

#14 Re: mORMot 1 » Revision 2.x of the framework » 2020-04-16 22:48:14

Hey ab,
maybe you should consider splitting the stuff into more files because e.g. mormot.core.base.pas almost has 10k lines again. I know that there is also a lot of documentation but I mean it seems your still somewhere at the beginning of the refactoring and most stuff is still to come...

#15 Re: Free Pascal Compiler » FPC 3.2 rc1 » 2020-04-04 00:11:23

ab wrote:

(and anyone know if it would take weeks or months from the RC1?)

Some forum posts sound more like months than weeks.

#16 Re: mORMot 1 » Revision 2.x of the framework » 2020-03-29 13:30:27

Do you plan to release the results from the Survey?

#17 Re: mORMot 1 » Revision 2.x of the framework » 2020-03-14 22:59:10

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 smile

#18 Re: mORMot 1 » Revision 2.x of the framework » 2020-03-10 22:31:21

From point of use github/gitlab are more or less identical, just a different look and naming. Some things are better at Github, some at Gitlab.
But I think more people still use Github than Gitlab (more users have account on Github than Gitlab).
If the only thing is the runner, you could also mirror from Github to Gitlab and have the runner there (probably only important to the few devs anyway). I'm sure you can also use your private runner with Github if you configure everything as you'd do for Gitlab.

#19 Re: mORMot 1 » Revision 2.x of the framework » 2020-03-08 22:51:16

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.

#20 Re: mORMot 1 » Revision 2.x of the framework » 2020-03-08 22:44:53

You can also run CI on github. There are different possibilities but I'm not sure if any supports FPC. Unfortunately that's a big disadvantage in FPC/Delphi community because nobody really cares about such basic but important features.
To add FPC to Travis CI you need at least 3 volunteers (https://docs.travis-ci.com/user/languag … languages/). But you could use a Docker image for your CI.
Another option would be Github Actions (https://github.com/features/actions) or AppVeyor (https://forum.lazarus.freepascal.org/in … ic=35060.0). Example: https://forum.lazarus.freepascal.org/in … #msg190018
I think I've also seen people who trigger their own CI server via Github.

#21 Re: mORMot 1 » Revision 2.x of the framework » 2020-03-06 21:31:21

ab wrote:

@Javierus "split the project in subprojects"... in fact I was going into the opposite direction.
A lot of units will always be shared among projects.
And due to that, we have regularly a lot of problems with users having e.g. SynCommons.pas from SynPDF project and mORMot project in their path, and failing to compile.
So my idea would be to remove separate projects, and download and use mORMot as main source. If units are refactored into smaller and well-scoped units, it would be just fine to use only SynPDF or SynMustache and not the REST/ORM/SOA part.

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 tongue)

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

#22 Re: mORMot 1 » Revision 2.x of the framework » 2020-03-04 20:15:18

Greg0r wrote:

1) Forget about older Delphi compilers
Minimum supported XE4 or XE7 (personally I would go with Tokyo 10.2 as minimum)
At least if possible forget all before XE4

Waste of energy to maintain very old or very buggy/outdated Delphis
This energy could be spend on development new things/improving current instead of patching vendor bugs.

You're absolutely right and I don't see why ab should spend his time on supporting old compilers just because some company's missed to upgrade their compiler for almost 20 years! They didn't spend many for 20 years and ab gives us an awesome product for free - so where is all the money from the company going to?
And mORMot as it is now works fine without flaws. If you use an old compiler, stay with the old mORMot version....or better, spend some money to move to recent compiler or even better, FPC!

some wishes:
- full TCP client with SSL support through OpenSSL (or similar vendors)
- more feature/code up-streaming to FPC (thats what open-source is all about smile, mORMot uses FPC trunk anyway) and Delphi could use plain pascal implementation as FPC is the main target and the fast assembly optimizations also improve the program in other parts

#23 Re: mORMot 1 » Revision 2.x of the framework » 2020-03-03 20:37:56

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 :-)

#24 Re: mORMot 1 » OpenSSL 1.1 wrapper » 2020-02-24 14:08:25

ab wrote:

TLS support via OpenSSL may be a plus to get rid of the libcurl dependency on POSIX

Note that under Windows, there are 3 ways of using TLS/HTTPS in SynCrtSock.pas:
- TWinINet - deprecated
- TWinHttp - just fine
- TCrtSock with aTLS=true, using SChannel API - this last one was not quoted here, but is nice because it requires no 3rd party dependency since it is built-in in the Windows system.

So for unix there is only TCrtSocket with libcurl and without TLS?
Are there any examples on how to create a client TCP connection to a server?

#25 Re: mORMot 1 » OpenSSL 1.1 wrapper » 2020-02-23 20:36:14

mpv wrote:

Yes, Chiper/Decipher/DiffmiHelmah (building blocks of TLS) is on the roadmap.

Unfortunately mORMot doesn't have TCP/UDP sockets + HTTP support with gzip

Client (requests to other resources) also supports HTTP/HTTPS/compression out of the box (both TWinHTTP & TCurlHTTP)

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 smile

#26 Re: mORMot 1 » Contributing to FPC » 2020-02-23 20:20:32

By the way, FPC also supports Intel assembly by using



mdbs99 wrote:
ab wrote:

Last time I checked, any attempt to provide some alternate asm to FPC x86_64 RTL (by Johannes IIRC) was a more or less rejected, for several reasons I don't remember well.

I think they don't like code that may not work in all platforms which FPC cover.

That cannot be the reason, e.g. String functions for 32bit (i386), String functions for 64bit (x86_64), generic String functions (if not implemented in assembly) and String functions for 64bit ARM (AArch64). If a specific assembly version of a function is not implemented, it falls back to the generic pascal one. This links are specific for strings but in the directory are some more files with assembly versions of other functions or internal FPC intrinsics (?).

#27 Re: mORMot 1 » OpenSSL 1.1 wrapper » 2020-02-23 12:22:12

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

TLSv1_3_method: function: PSSL_METHOD; cdecl;

and also

TLS_method: function: PSSL_METHOD; cdecl;

Otherwise very good work! smile

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...

#28 Re: mORMot 1 » Compile error in SynCommon.pas » 2020-02-23 12:18:56

Now it misses a ';' for the end for the try-finally block.

#29 Re: mORMot 1 » FLOAT_OVERFLOW in TSQLRequest.Execute » 2020-02-17 17:07:04

ab wrote:

AsTSQLRecord can be quite buggy on Linux - especially if heap address randomization is enabled.
Just as TSQLRecord.ID/GetID may be too.

So using PtrInt(strRec) directly - if you know it is not an instance, but a pointer - is certainly the safest option.

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?

#30 Re: mORMot 1 » FLOAT_OVERFLOW in TSQLRequest.Execute » 2020-02-17 17:02:38

ab wrote:

Static linking works very well on Linux with FPC... Or are you using Kylix?

No, using FPC. I think I've read somewhere that static linking doesn't work with FPC.
But however, why should it make a difference?
I'm using the SQLite precompiled Binaries from https://www.sqlite.org/ on Windows and for Linux we compile them.

#31 Re: mORMot 1 » FLOAT_OVERFLOW in TSQLRequest.Execute » 2020-02-17 14:43:57

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

#33 Re: mORMot 1 » Contributing to FPC » 2020-02-15 14:48:03

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).

#34 mORMot 1 » Contributing to FPC » 2020-02-13 16:29:43

Replies: 8

Hey ab,
why don't you contribute your assembler implementations for specific functions to FPC?
For instance, your recent MoveFast x86_64 optimized assembly function. It's just one example, there are many other functions in highly optimized assembly code. smile
Then not only mORMot would profit but also FPC and all other code which uses move().


#35 mORMot 1 » FLOAT_OVERFLOW in TSQLRequest.Execute » 2020-02-13 16:12:11

Replies: 8

I've a very strange issue which appears after some days/weeks where my code was running fine but then suddenly it stops working because it creates a deadlock by LockJSON due to a thrown exception.

My TSQLFileStatRec class inherits from TSQLRecord and has the members declared as TSQLSitesRecord. The member classes inherit from TSQLRecordNoCase and only have following types: RawUTF8, Int64 and TDateTime.

Example class definition:

  TSQLSrcRec = class(TSQLRecordNoCase)
    FName: RawUTF8;
    property Name: RawUTF8 read FName write FName stored AS_UNIQUE;

Stacktrace when exception is thrown:

:0000000003B03B57 ; c:\lib\sqlite3-64.dll
:0000000003B0FF16 ; c:\lib\sqlite3-64.dll
:0000000003BFB9CF ; c:\lib\sqlite3-64.dll
:0000000003C053F8 ; c:\lib\sqlite3-64.dll
:0000000003C055A8 ; c:\lib\sqlite3-64.dll
:000000000082273B TSQLRequest.Step + $4B
mORMotSQLite3.TSQLRestServerDB.MainEngineList('SELECT ID FROM FileStatRec WHERE SrcRec = :(''000000000000000C''): AND DstRec = :(''000000000000000A''): AND SectRec = :(''0000000000000014''): AND FileRec = :(''000000000001E313''):',False,nil)
mORMot.TSQLRestClientURI.URI('root','GET',$B3DF3B8 {''},nil {''},$B3DF3E8 {'SELECT ID FROM FileStatRec WHERE SrcRec = :(''000000000000000C''): AND DstRec = :(''000000000000000A''): AND SectRec = :(''0000000000000014''): AND FileRec = :(''000000000001E313''):'})
mORMot.TSQLRestClientURI.ExecuteList((...),'SELECT ID FROM FileStatRec WHERE SrcRec = :(''000000000000000C''): AND DstRec = :(''000000000000000A''): AND SectRec = :(''0000000000000014''): AND FileRec = :(''000000000001E313''):')
mORMot.TSQLRest.MultiFieldValues(TSQLRecordClass($B96558),'ID','SrcRec = :(''000000000000000C''): AND DstRec = :(''000000000000000A''): AND SectRec = :(''0000000000000014''): AND FileRec = :(''000000000001E313''):')
mORMot.TSQLRecord.CreateAndFillPrepare($7FF4FDD4BBF0,'SrcRec = :(''000000000000000C''): AND DstRec = :(''000000000000000A''): AND SectRec = :(''0000000000000014''): AND FileRec = :(''000000000001E313''):','ID')
mORMot.TSQLRecord.CreateAndFillPrepare($7FF4FDD4BBF0,'SrcRec = ? AND DstRec = ? AND SectRec = ? AND FileRec = ?',(...),'ID')

The code for the query is made with CreateAndFillPrepare (using TSQLRestClientDB) and the SrcRec parameter is filled with the previous created SrcRec and added as SrcRec.AsTSQLRecord. All my queries only fetch the ID value. The thrown exception is FLOAT_OVERFLOW. When I change the SrcRec.AsTSQLRecord to SrcRec.ID it doesn't throw the exception.
For me it seems it's related to SrcRec.AsTSQLRecord?

Thanks in advance and regards!

#36 Re: mORMot 1 » open source project- really? » 2020-02-13 15:48:09

It's an open source project and lives by contribution of other people. Why don't you make the needed changes? You want to have it and seems your the only one who needs it, so make it possible!
Or donate some money to ab, guess he might have a bit more time to look into your specific issue then. You can't expect to get everything in an instant manner in a FREE open source project!

Board footer

Powered by FluxBB