Compiling mORMot with FPC under Windows

AOG · 2014-09-15 09:29:40

Hello Ab,

I am busy trying to compile mORMot with FPC, under windows.

I am able to compile a simple server, but it is not running.

I have a request.

Would it be possible to extract the RTTI part out of mormot.pas ?

A separate RTTI-unit would make (my) life much easier.
At this moment, RTTI implementations of mORMot and FPC are not working together very well.

It should/could be (made) possible to use (parts of) the FPC typinfo unit ?!

Thanks in advance, Alfred.

ab · 2014-09-15 10:39:40

It was our fist attempt. See USETYPEINFO conditional in Synopse.inc and mORMot.pas.
When defined, typinfo.pp was included for FPC in mORMot.pas.
But in fact, the FPC's typinfo is missing some methods (e.g. for dynamic array properties, and other methods I do not remember well).
And variant support is somewhat broken, in respect to Delphi: for instance, varByRef value instances are not handled directly, as they are with Delphi.
So using typinfo.pp is not an option, unless you write some specific code to enhance/fix it - this is what is done in mORMot.pas.

But the current first problem is not in mORMot.pas I suspect: SynCommons.pas uses RTTI, for record process and dynamic array process.
Our TDynArray is not fully debugged with FPC yet.
First step would be to debug TDynArray and record process first.

I was fed up with the Lazarus debugger: gdb did have issues with the symbols (whereas they were included), and did show wrong information.
Low-level asm debugging is also a nightmare, when compare with Delphi, and it is especially needed when debugging low-level access to binary structures like RTTI.
I will retry with the CodeTyphon 5.0 version I just installed on my computer.

I suspect you may loose a lot of time if you want to do it on your side, unless you have deep knowledge of both Delphi and FPC RTTI.
Reference for RTTI is the typinfo unit for both compilers.
Almost all structures are already translated and defined for both Delphi and FPC in SynCommons.pas and mORMot.pas.
We should start from here, not by calling typinfo directly, IMHO.

Separating RTTI from SynCommons.pas or mORMot.pas may be feasible, but this low-level RTTI access is tied to some optimized code of those two units, for performance reasons.
Making it separate would need to define a set of classes, instead of records and pointers, just like Delphi's new RTTI accessors. And you know perhaps how slow they are told to be.
This is why our units "talk" directly to the RTTI binary content, on each platform.
Then it is encapsulated in mORMot classes, so user code would never need to use RTTI explicitly - with the exception of some "pointer" information.

AOG · 2014-09-15 11:43:39

Thanks for the info !!

And yes, this consumes a lot of time ... and still does ... perhaps I have to stop ... ;-)

I have a final (and perhaps a [very] stupid) request :

Could you refactor your code in mORMot.pas that it does not declare it's own TypeInfo, but something like mORMotTypeInfo.

I have many problems in which the compiler (FPC, CodeTyphon) does not know whre to look for TypeInfo, when I include the typinfo unit.

Refactoring would make it possible to (slowly) use a (future enhanced) typinfo unit from FPC.

Now, I have a lot of errors like this : mORMot.pas(20681,25) Error: Incompatible types: got "TYPINFO.PPropInfo" expected "MORMOT.PPropInfo".

I know this is a strange request ... I will accept your decision !!

Greetings and thanks.

ab · 2014-09-15 12:37:52

In fact, this is why there are some strange pointer(TypeInfoField) everwhere in the implementation section of mORMot.pas: to allow this.

But even under FPC, it should use the mORMot.PPropInfo field.
You should NOT have to define the TypInfo unit in mORMot.pas.

You can add a ticket for this refactoring request, if you wish.

AOG · 2014-09-15 13:03:03

Clear. Thanks !!

I will not make a refactoring ticket, before I have tried->tested->succeeded myself !

Thanks for the explanations.

AOG · 2014-09-17 09:34:52

After a couple (many) hours working with the mORMot code, I think I have succeeded in getting the RTTI part of mORMot running very well with FPC under Windows !

Creation of TSQLModel and TCustomServer ok.

However, now I am struggling with the variant part (TDocVariantData).
This [ field.name := nfo.Name; ] does not work.
This [ TDocVariantData(field)['name'] := nfo.Name; ] does work.

(Following IntSet ----> code stuck inside TDocVariantData.GetValueIndex ---> VName cannot be accessed ---> SigSegFault :
Length(VName) = 2 ; writeln(VName[0]) = error)

Could you please advice me ?

I could replace code, but mORMOt uses more variant trickery on other levels.

1) does it make sense to replace (lot of work) ?
2) do you have a better idea ?
3) does it make sense for me to go on trying ?

Thanks !

ab · 2014-09-17 13:04:45

Great news!
Could you send me the fixed files, so that I could integrate your efforts?
To webcontact01 at synopse dot info.

The [ field.name := nfo.Name; ] issue is a FPC bug.
In short, AFAIR, before TCustomVariantType.SetProperty() is called, a local copy of the "const V: TVarData" parameter is generated by the compiler.
Delphi does not do this, and pass a pointer to V directly - therefore, V can be MODIFIED.
In fact, this "const V: TVarData" is misleading - it should be defined as "var V: TVarData".
Delphi is incorrect, by defining a "const" here, and writing on its content at low-level.
You should be able to write a bug report to the FPC team for the correction. I guess that changing the "const V: TVarData" into a "var V: TVarData" for SetProperty(), and changing the generated asm corresponding to this call by the compiler, should be sufficient.
AFAIK there is almost no FPC library using this feature, which is a part of rtl-objpas compatibility folder.
So changing the default behavior would not break any code.
But since it is a compatibility folder, perhaps the FPC team may want to stay with the Delphi "const V: TVarData" parameter, but should fix the generated asm code to pass the value as a pointer, WITHOUT any temporary copy when calling SetProperty().
So the same exact TCustomVariant code may be shared with Delphi and FPC.
This issue is in fact a show-stopper for us.

I would indeed rather see FPC fixed, without having to change all our code to by-pass the late-binding feature (which is the "beauty" of the current implementation, IMHO, when compared to other JSON libraries).

ab · 2014-09-18 18:57:49

See http://synopse.info/fossil/info/173dfd47ef423

I almost spent the whole day on this one...

ComingNine · 2014-09-18 19:47:28

You guys are brilliant !

ab · 2014-10-14 08:18:55

We have one big issue with FPC which prevents to use interface based services, so our SOA process.
See http://bugs.freepascal.org/view.php?id=26774
We just need the RTTI as available in Delphi 6, more than 12 years ago!
Sadly, the FPC team does not seem willing to fix it soon.

mORMot Open Source

#1 2014-09-15 09:29:40

Compiling mORMot with FPC under Windows

#2 2014-09-15 10:39:40

Re: Compiling mORMot with FPC under Windows

#3 2014-09-15 11:43:39

Re: Compiling mORMot with FPC under Windows

#4 2014-09-15 12:37:52

Re: Compiling mORMot with FPC under Windows

#5 2014-09-15 13:03:03

Re: Compiling mORMot with FPC under Windows

#6 2014-09-17 09:34:52

Re: Compiling mORMot with FPC under Windows

#7 2014-09-17 13:04:45

Re: Compiling mORMot with FPC under Windows

#8 2014-09-18 18:57:49

Re: Compiling mORMot with FPC under Windows

#9 2014-09-18 19:47:28

Re: Compiling mORMot with FPC under Windows

#10 2014-10-14 08:18:55

Re: Compiling mORMot with FPC under Windows

Board footer