As a (very) long time Pascal programmer (TP/ FPC / Delphi), I have helped the developer of mORMot
(http://synopse.info/fossil/wiki?name=SQLite3+Framework) to port his framework to FPC. With success. Many Linux (ARM) servers now run mORMot thanks to FPC.

There are, however, two showstoppers, that inhibit the full deployment of mORMot with FPC.
They were reported, by the developer, as being feature requests and/or bugs (#26773 and #26774).

My question to the list.

I have a personal interest in 100% integration of mORMot with FPC (Linux [ARM]).

Questions:
1) Are there any known workarounds and/or design changes that I could implement into mORMot to tackle these two mORMot-problems.
2) If acceptable, what can we do for FPC to get these two aspects to work for mORMot.
(e.g. #26774: who will implement this feature and when ; can we help implementing this feature)

Thanks.

The fixing of these bugs/features is definitely acceptable.

For 26773:
this will also need fixes in the compiler, since you propose a change in a compilerproc. However, this should be easily doable.

(however, it makes me wonder what will happen if delphi fixes their compiler. Being able to change a const parameter is simply a bug in the compiler)

For 26774:

- You can try contracting joost van der sluis (), he offers commercial support for lazarus/FPC. He did recently some work on the extended attributes, I'm sure he can do the task.

- You can try offering a bounty on the mailing list and see who takes up the task.

- Last but not least, you can dive in the code yourself.

Michael.

Michael Van Canneyt wrote

For 26773: this will also need fixes in the compiler, since you propose a change in a compilerproc. However, this should be easily doable.

If it's just a change from "var" to "const", nothing needs to be changed in the compiler. The parameter passing of compilerprocs is handled by the regular call node code. The ability to do this was the main reason to introduce them.

Some of the other changes would however need a note on http://wiki.freepascal.org/User_Changes_Trunk , since they may require changes to user code (given that a number of tests also need to be changed).

Jonas

Even better.

Some of the other changes would however need a note on http://wiki.freepascal.org/User_Changes_Trunk , since they may require changes to user code (given that a number of tests also need to be changed).

Well, if no compiler changes are needed, I will 26774 is out of my league, though.

Michael.

Just so everyone is up to date on this.
As I wrote in http://bugs.freepascal.org/view.php?id=26774: It would be useful to have somebody provide a specification for the RTTI layout. I'm willing to supply a patch, since I have a working implementation with my own layout one top of the current trunk.

mfg Steve Hildebrandt

As far as I know, the layout of this particular kind of RTTI can be deduced from the TypInfo unit of Delphi. At least XE seems to have the info present.

Michael.

Michael Van Canneyt wrote

As far as I know, the layout of this particular kind of RTTI can be deduced from the TypInfo unit of Delphi. At least XE seems to have the info present.

This should be done using a clean room approach though: one person can read the code and document the layout, while someone else implements it. Especially since you'll presumably also have to write your own TypInfo unit code for FPC afterwards to access the data.

Jonas

I have fixed bug 26773. (test included in testsuite) I will try to document the RTTI format tomorrow, so it can be implemented/patched ASAP.

Michael.

Thank you for fixing the variant issue !!

In mORMot, the fix works as expected.
Late binding behavior is now compatible with Delphi.

Thanks again for the very quick actions.