mORMot Open Source

Strange indeed.

I was thinking about asking for a FPC_HAS_PPTYPEINFO flag.
But I presume this is a "feature" that will become a standard for everything after FPC 3.0.
So, if VER>3_0 : PPTypeInfo. Perhaps this is the reason for not adding a flag.

And FPC core will argue that FPC trunk is a running target, I expect.

Thanks for undefining HASDIRECTTYPEINFO. mORMot will work out-of-the-box again with current trunk.

If the weather remains as bad as it is right now, I will have a look at it again ... ;-)
Tests will be done with FPC fixes (3.0.1/3.0.2) and FPC trunk (with PPTypeInfo).

@ab
Allright !
Latest commit: everything working as expected, with and without interface RTTI !

@Chaa
I could help.
But tell me how to generate an exception as you would expect ?

Unfortunately (installing in any folder) is not that easy !
The config-files of FPC and Lazarus are full of paths.
These have to be set beforehand.
That is why there is the prescribed directory.

But the zip also contains fpclazup and all the necessary batchfiles.
And alll crosslibs and crosstoolchains
So, users can also perform the whole setup by themselves.
In any directory they want.
If needed, I will give extra instruction to do so.

@hnb
Keep faith ! You are doing good work.
But opensource means compromise and patience.
Which is sometimes hard.
Although I must commit that three years is very looooong ... ;-) ... and indeed frustrating ...

Opensource also means: freedom to fork. So lets move forward and don't look back !!

@all
About the binary, I propose the following (I have good experience with this).

Many people are interested in the mORMot / FPC combi. If we help them, they will become mORMot users.
Many have difficulty with cross-compiling. If we help them, they will become mORMot/crossFPC users.
mORMot is now fully cross-platform. mORMot running on Linux64 is a MAJOR plus.

For a start, I can make a Windows zip with a fully self-contained FPC (with RTTI)/Lazarus/mORMot.
No install, just an unpack in a (prescribed) directory. Click the start-shortcut and you are ready to go !
With cross-compiling enabled for Win64, Linux32/64, ARM (RPi2) and aarch64 (Odroid-C2).

The self-contained means no install and no changes in the system of the user.
Just unzip. It also means that the users can use this in parrallel with his own FPC/Laz install. They will never touch.
(at the moment, I have 5 different installs on my system)

This is the most easy for me to make. A real install will consume time. I could dive into it.
But I think that the install has to be self-contained. Just use it and remove it at will, without any consequences.

@hnb
We can use your FPC version with the nice features you described.
Patch it with RTTI (easy), put it on Github and maintain it for important (trunk) changes that are necessary for the mORMot.
I can build the cross package, and also put it online. And off-we-go ! We go forward, the rest will follow.
This special FPC version can also be added to fpc(laz)up, making it in easy reach of many more users.

All the above is just a proposal.
But also a way for an easy start. For ourselves and the users !
In due time, I hope that FPC core developers will follow us.

@ab
Thanks for refactoring and including latest changes. mORMot (interfaces) now runs 100% on aarch64 !

I used movlpd because FPC warns for possible errors when loading a 64bit value into a 128bit register.
Thats it. As it seems, FPC does not detect the fact that zero-extension is used by movsd.

I will ask again to take over the RTTI branch on the FPC svn server. That will be the most easy way.
I will also work on more systems for RTTI: a patch (working) for aarch64 is already made.

Ok.

Added some necessary changes into the latest commit.
Can be found at: https://github.com/LongDirtyAnimAlf/mORMot
This also answers question 2.

Question 1:

The original code of AddrAllocMem can be found at:
https://github.com/RRUZ/Delphi-IDE-Colo … etours.pas
https://github.com/RRUZ/vcl-styles-util … etours.pas

The FakeStubs use relative jumps.
But FPC maps the requested memory too far away for a relative jump.
This code finds a piece of memory close by.

Naturally, there is room for improvement (speed-up) !

I am maintaining a separate uptodate branch of the mORMot, with all the necessary (minor) bug-fixes for the great mORMot.

https://github.com/LongDirtyAnimAlf/mORMot/

You can try this branch. I think it will work for you. The reported problems will be solved.

(I even added low level asm for aarch64 today !)

Interfaces now working 100% on Linux 64 bit (and FPC Win64 and Delphi .... no regressions detected yet) !!!
Major goal reached with mORMot on Linux 64 bit !!!
This means that code change for FP-registers is ok and working.

Path towards ARM and Aarch64 now open.

Please test.
https://github.com/LongDirtyAnimAlf/mORMot

Not mandatory. Just safety.

This FPC/mORMot bug-hunting makes me (slightly) crazy. Code that should work, does not work.
Work-arounds that are non-logical make things work. So, I am getting a bit paranoid, and add more safety than perhaps needed. Does not do a lot of harm however.

Thats it.

Hi Ab,

ARM (and aarch64) invoke support is not yet finished !
It was just copy/past of old code. To get placeholders for the new ARM/aarch64 opcodes. CallMethod is started but still a lot of work-in-progress.

Thanks for your integration effort.

Main review should be about the introduction of separate floating point registers.
My tests show no regressions with Delphi.
And less errors with FPC.
In fact, the CallMethod assembler for FPC with FPR registers and stack-loop also works 100% with Delphi.

But still much work to be done.

There are some hard to solve (minor) bugs in the 64bit compiler of FPC that have to be circumvented.
As you can see from my fork, there are patches that are non-logical, but still needed for 64 bit FPC.

(My) Timeline:
Full integration of separate floating point registers, without regression for (Delphi) 64 bit, and with your code-review-ok.
Port to FPC Win64.
Port to FPC Linux64.
Port to FPC ARM.
Port to FPC aarch64.

@ab
Thanks ! I will await your code-approval on further changes !

@edwinsn
For my main project(s), I am using a javascript framework for user interaction: OpenUI5 by SAP. Many mobile clients. So, I only need a REST server.
Server connects directly to Internet.
I am using a T2 micro. Free of charge for 1 year. Cheap after that. With a custom (very lean) Arch Linux x64.
Due to the CPU scaling and bandwidth and price (three year contract) , very hard to beat.
But I am also studying (and using) the Odroid-C2 for server purposes. Aarch64. Very quick. On my private fiber onto the Internet.

No. These are not fixes, but hacks.

But I will adapt (fix) the special branch of mORMot in one way or another to get things running by:
change the assembler into working assembler for FPC 64 bit
or
fallback to pure-pascal

I will do the latter first. And, when more time is available, the former.

It seems that this is an assembler problem.

You could try to disable the assembler by:

{$define AES_PASCAL}

somewhere around line 1750 in SynCrypto.pas

Look here ...

http://bugs.freepascal.org/view.php?id=30112

I think my answer for this bug will answer yours too !

Don't worry about sharing (and disturbing) configurations.
The libraries contain FPC/Lazarus versions that are self-contained.
No paths are changed. No config changed. Just copy files.
That is also why you need to use the startup-script.

Besides, Lazarus is of no importance for mORMot.
mORMot only needs FPC.
And FPC trunk has some very important bug-fixes that are important for mORMot.

Well, you need FPC and Lazarus trunk sources to build FPC and Lazarus trunk.
If you can get the latest sources, fpc(laz)up can do the (dirty) patch and build work for you !
But you need the sources.

Can you download from Google Drive ?

Try:

initialization
  TTextWriter.RegisterCustomJSONSerializerFromText(TypeInfo(TStTaxRate), 'taxRate string');
end.

So, replace "word" with "string" .....

Well .... you could press Ab a bit ... ;-)

I did send him a huge patch / mod to get mORMot running on Linux 64bit.
Not yet 100% correct. But enough for a bit of mORMot on Aarch64 ! And that is Linux 64bit !
I am waiting for his code-review before I go on with the last 64 bits and pieces.

@shobits1

Can confirm !

For now, just use something like

fpclazup --installdir="C:/yourdirectory" --fpcURL="trunk" --lazURL="trunk" --verbose  --getfullrepo --fpcPATCH="fpctrunkrtti.patch"

The trunk rtti patch can also be found on the fpclazup github.
This will give you trunk + RTTI needed by mORMot.

At the moment, the new interfacertti branch does not compile on my system (Win8.1).
I would welcome reports !

Yep !
Because of this bug, I asked for an update of the RTTI branch.
Unfortunately, Steve updated to 33592. So I asked again, for at least 33597 !

When working with the mORMot, I would advice to always use

{$MODE DELPHI}

Then this "HTTPServer.OnRequest := HTTPServerRequest;" would have worked !

I use this (with FPC):

TMyHttpServer = class(TSQLHttpServer)
  protected
    function Request(Ctxt: THttpServerRequest): cardinal; override;
  end; 

function TMyHttpServer.Request(Ctxt: THttpServerRequest): cardinal;
begin
  .. your code
  result := inherited Request(Ctxt);
  .. your code
end;

Hope it helps.