mORMot Open Source

Tested on similar settings, using !0.4.2 though, and all ran through, however, 1 test failed

!  - Mustache renderer: 1 / 157 FAILED  2.05s

Final:

Generated with: Delphi 10.4 Sydney 32 bit compiler

Time elapsed for all tests: 1m42
Performed 2021-04-15 06:16:01 by Daniel Wischnewski on DANIEL-VM

Total assertions failed for all test suits:  1 / 41,661,926
! Some tests FAILED: please correct the code.

Darn, I did read that topic, but did not connect the dots in my head :-D

Or... split the string, it's just a compiler limit

TTextWriter.RegisterCustomJSONSerializerFromText(
TypeInfo(TMyClass), 

'field1, field2, ' + 'field3 RawUTF8'

).Options := [soReadIgnoreUnknownFields];

From mormot.core.os, aka ExeVersion (mORMot 1).

They, currently, do not even compile (Sorry, forgot to write that in the original post)

[dcc32 Error] mormot.db.raw.sqlite3.static.pas(1089): E2065 Unsatisfied forward or external declaration: 'sqlite3_progress_handler'
[dcc32 Error] mormot.db.raw.sqlite3.static.pas(1094): E2065 Unsatisfied forward or external declaration: 'sqlite3_stmt_scanstatus'
[dcc32 Error] mormot.db.raw.sqlite3.static.pas(1095): E2065 Unsatisfied forward or external declaration: 'sqlite3_stmt_scanstatus_reset'
......
[dcc32 Fatal Error] mormot2tests.dpr(709): F2063 Could not compile used unit 'mormot.db.raw.sqlite3.static.pas'

Regards,
Daniel

For how long? :-D

I would leave it at asynch - while you are right - async may just become a keyword at some point, as it is in other languages already, and thus may break compiling, when used in/as unit names ;-)

So far, looking great. I am using mORMot2 for internal production code (however, basically just the JSON-part), and it is working smoothly. The code created by that is working standalone, as we have to work on XML data, so, no fear of a pre-production version going into production code themselves.

The tests on Delphi 10.4 look promising.

Win32, Release:
Time elapsed for all tests: 56.27s
Total assertions failed for all test suits:  0 / 41,982,561
! All tests passed successfully.

Win64, Release:
Time elapsed for all tests: 45.14s
Total assertions failed for all test suits:  0 / 41,955,145
! All tests passed successfully.

However, when starting, I get a little popup warning:

Static SQLite3 library as included within mormot2tests is outdated!
Linked version is 3.31.0 whereas the current/expected is 3.34.0.
Please download latest SQLite3 3.34.0 revision from
https://github.com/synopse/mORMot2/releases/download/pre1/mormot2static.7z

And I have, just before, updated to the latest version.

Regards,
Daniel

P.S.: Du to user error, I've tested a three day old version, however, the current version performs similar, with the same popup ;-)

Your problem is, that ODBC simply does not support multiple statements in a single command/query. However, if you use MySQL, there is an option, that will enable that special feature.
More on that: https://stackoverflow.com/questions/414 … 6#15440056

Regards,
Daniel

I suppose you've heard my forehead bump onto the table... :-D

Thx

Perfekt and thanks for the flowers - see you in Düsseldorf in November, I hope :-)

I have opened up that bug for discussion at the Delphi-PRAXiS as well, hoping to get some traction: https://en.delphipraxis.net/topic/3155- … elphi-104/

As for your question, whether any hints are left, yes one, at first glance looking alike, but this time, I believe it to be correct.

In mORMotService.pas, method    function TService.GetControlHandler: TServiceControlHandler; (line 1143)

It says
[dcc32 Hint] mORMotService.pas(1170): H2077 Value assigned to 'TService.GetControlHandler' never used

However, you have a non-conditional EXIT in line 1154, so the code after that shall never be reached.

Please review ;-)

P.S.: Last, but not least, with the latest changes to mORMot, it works fine under Delphi 10.4 :-) As we are currently just developing, with a release years ahead, I feel okay continuing to use 10.4 ;-)

Nope, problem still exists. However, a nicer fix for your particular problem exists as well.

Replace the very first else with a semicolon --->

  if (self=nil) or (Dest=nil) then begin
    Result := nil;
    Exit;
  end else
  if (Source<>nil) and (SourceChars>0) then begin
...

change to

  if (self=nil) or (Dest=nil) then begin
    Result := nil;
    Exit;
  end;
  if (Source<>nil) and (SourceChars>0) then begin
...

And the problem is gone as well. I am trying to minimize the problem and will submit that to the team on Monday.

Regards,
Daniel

P.S.: Quick Fix - but not compatible with older compilers like Delphi 7:

Exit(Dest);

Replace that line with

@ab - I cannot confirm 1.18.6078 working.

I have tried back to version 1.18.5749 and the problem persists. It seems to have to do with the SynCommons.MoveX87 method.

Log from the revision: https://pastebin.com/hWC7d3Lc

So, I had the time to at least get logging into the MVC demo with 10.4
After building a RELEASE version of it and starting it, it crashes on TInterfaceFactory.Create.

The log can be found at https://pastebin.com/ZxtCTe7m

Currently, I am a bit flabbergasted as to why that happens though.

@Arnaud, as written in the Email, you may get remote access to a VM with Delphi 10.4 and that demo to fiddle arround.

Regards,
Daniel

While not my choice of words, it matches my sentiments ;-)

As written before, this was a sample, boiled down to minimal code. Interestingly, the same mistake happened in the sample, as in the real app. However, in the sample it was way more obvious.

destructor THttpApiServer.Destroy;
{$ifdef LVCL}
var i: integer;
{$endif}
begin
  {$ifdef LVCL}
  Terminate; // for Execute to be notified about end of process
  {$endif}
  try
    if (fClones<>nil) and (Http.Module<>0) then // fClones=nil for clone threads

----------- fClones<>nil needed? removing that, it seems to work...

      DestroyMainThread;
    {$ifdef LVCL}
    for i := 1 to 500 do
      if fExecuteFinished then
        break else
        SleepHiRes(10);
    {$endif}
  finally
    inherited Destroy;
  end;
end;

See comment above. I have not seen - in my demo case - where fClones is accessed within DestroyMainThread, so, it being NIL wouldn't be a problem. But in other cases it might...