Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

AOG · 2016-05-23 12:18:14

ARM implementation for interfaces (SOA services) ready and working !

About Mac OS.
I do have some GUI clients for Mac. Working fine.
But I am not yet in the need for more.
Besides, a code refactoring should be done to distinguish better between Linux, Unix and Darwin.
And that is a lot of (debug) work.

Next target: aarch64 !

hnb · 2016-05-23 20:12:10

Yay ;D the power of mORMot is scary. All of my mobile app on Android can be used as server...

KK · 2016-05-27 19:39:16

AOG wrote:

ARM implementation for interfaces (SOA services) ready and working !

Hi,

it`s great to have the possibility to implement restful with delphi/fpc!!! Thanks for that work!
I`ve downloaded the windows version from AOG (fpclazrtticross) and the fork mORMot. When I compile to linux64 everything works fine, but when I try to compile to arm I get some errors during compilation:

SynCommons.pas(19015,11) Error: Wrong number of parameters specified for call to "Align"
generic.inc(2036,10) Error: Found declaration: Align(LongWord;LongWord):DWord;
generic.inc(2046,10) Error: Found declaration: Align(Pointer;LongWord):^untyped;
SynCommons.pas(19037,11) Warning: Arithmetic "-" on untyped pointer is unportable to {$T+}, suggest typecast
SynCommons.pas(19056,10) Error: Wrong number of parameters specified for call to "Align"
generic.inc(2036,10) Error: Found declaration: Align(LongWord;LongWord):DWord;
generic.inc(2046,10) Error: Found declaration: Align(Pointer;LongWord):^untyped;
SynCommons.pas(19074,12) Error: Wrong number of parameters specified for call to "Align"
generic.inc(2036,10) Error: Found declaration: Align(LongWord;LongWord):DWord;
generic.inc(2046,10) Error: Found declaration: Align(Pointer;LongWord):^untyped;
SynCommons.pas(19120,10) Error: Wrong number of parameters specified for call to "Align"
generic.inc(2036,10) Error: Found declaration: Align(LongWord;LongWord):DWord;
generic.inc(2046,10) Error: Found declaration: Align(Pointer;LongWord):^untyped;

can you help me?

AOG · 2016-05-27 20:16:09

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

ab · 2016-05-28 13:04:13

@AOG
I will do the merging of your branch now.

Stay tuned!

Some questions:

1. where does the AddrAllocMem() complex function in mORMot.pas comes from?

2. in the following code:

   //necessary on aarch64: make stack length always 2 byte multiple (Stack aligned on 16 bytes)
    if ((call.StackSize MOD 16) <> 0) then call.StackSize:= call.StackSize + 16 - (call.StackSize mod 16);

since call.StackSize is in 8 bytes unit, shouldn't it be simply:

   //necessary on aarch64: make stack length always 2 byte multiple (Stack aligned on 16 bytes)
    if ((call.StackSize MOD 2) <> 0) then inc(call.StackSize);

ab · 2016-05-28 15:40:36

The merge is available in http://synopse.info/fossil/info/9408c0ea83

I tested only against regression with Delphi Win32/Win64, so it is still a work in progress...
But I tried to include all your modifications into the official trunk.
Just with a few minor changes, mostly about source code formatting.

Still pending the 2 questions on my previous post.

Thanks a lot Alfred for sharing such valuable code!

hnb · 2016-05-28 16:09:08

AOG and ab - amazing . Can I use code from mORMot to implement Invoke function for RTTI module for FPC?

ab · 2016-05-29 07:08:52

@hnb
In mORMot, we use directly the JSON as input/output, with no temporary conversion to an intermediate variable like TValue.
See also how https://github.com/remobjects/pascalscript is implemented.

Yes, but you would need some kind of TValue to transmit the parameters.
See http://docwiki.embarcadero.com/Librarie … tti.TValue
But TValue has some overhead.
So http://tech.turbu-rpg.com/100/tvalue-is-very-slow
Consider using something more clause to TOmniValue - see http://otl.17slon.com/book/chap03.html - or TAnyValue
and see http://www.cromis.net/blog/2013/02/tval … s-revised/ as reference.

AOG · 2016-05-29 07:31:11

@ab
I think I just did something wrong on GitHub.
But I made a new fork, of your recent commit.
Will add some necessary changes soon, to solve some regressions !
Be back soon.

AOG · 2016-05-29 07:48:21

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

ab · 2016-05-29 10:34:17

Thanks!

About 3.0.2, it may be the occasion to merge the interface RTTI branch to the FPC trunk.
I tried to make this request to the FPC-dev list.

AOG · 2016-05-29 13:24:01

Good news ... I hope and wish they will include ... I have extra RTTI patch available for aarch64.

At https://github.com/LongDirtyAnimAlf/mORMot/ some more (minor) tweaks for the previous commit.

Especially, the (large) stack-tests revealed some problems.
And FPC aarch64 does not (yet) use the last float register for passing params .. I will report as a bug ... curious if this is a bug.

hnb · 2016-05-29 16:00:24

Thanks for links, I will start my work soon.

http://www.cromis.net/blog/2013/02/tany … container/

TAnyValue was my inspiration for management operators (Initialize,Finalize,Copy,Clone):

https://plus.google.com/115782878581272 … nmCLHf2xCd

ab · 2016-05-29 16:23:14

@hnb
Yes, with management operators, a FPC TValue-like would be just rocking!
Perhaps it may be a good idea to make your value storage compatible with Delphi's TValue.
Even if within mORMot we do not use this TValue, other libraries may do.

@AOG
I've made some more refactoring, to ease future code maintenance, and including your latest tweaks.
See http://synopse.info/fossil/info/9042a62c28

BTW why did you use movlpd instead of movsd for x64 asm in procedure CallMethod?
AFAIK movlpd set the high values of the SSE registers untouched, whereas movsd to zero-extension.
I guess this zero-extension is safest, and may be also slightly fastest, during out-of-order execution.
See http://www.popoloski.com/posts/sse_move_instructions/

hnb · 2016-05-29 17:56:28

ab wrote:

About 3.0.2, it may be the occasion to merge the interface RTTI branch to the FPC trunk.
I tried to make this request to the FPC-dev list.

I think it is pointless. That may happen somewhere around 2030-2040. I have terrible experience with ready to merge Generics.Collections which is waiting 2 years (!), RTTI branch (attributes only) 3 years (!).

...

AOG · 2016-05-30 08:45:53

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

AOG · 2016-05-31 08:11:46

The special interface RTTI branch of FPC has been updated, but still does not compile.
I am trying to solve this together with the maintainer.

In the meantime, I have created a branch of FPC trunk with RTTI on GitHub.
https://github.com/LongDirtyAnimAlf/fpctrunkrtti

The latest version of fpc(laz)up will use this repo.

If you want to use it without updating fpc(laz)up:
change
RTTI=http://svn.freepascal.org/svn/fpc/branches/interfacertti
into
RTTI=https://github.com/LongDirtyAnimAlf/fpctrunkrtti.git/trunk
inside of fpcup.ini

I hope you will succeed.

ab · 2016-05-31 08:47:46

From the FPC maillist, it sounds like if they do not want to do the merge, for reasons I can't understand exactly.
Sven wrote about the upcoming official "Invoke" implementation in FPC's RTL, but here we need the RTTI patch for our own mORMot "Invoke", so I do not see where the issue is.
I'm afraid working on our own FPC fork may be the best option, in the meanwhile...

It may be handy to provide also some ready-to-use binaries, if possible.
Or at least, provide a simple multi-platform (linux + windows) install process, to ease fpc(laz)up setup in a single step.
Including latest mORMot sources for github, of course!

hnb · 2016-05-31 09:35:36

@ab I am working on this already!

"Invoke" topic was raised in 10.02.2013 and in 05.02.2015 - It is almost 3 years... Nothing will change. I'd like to omit strong words so let me not commenting Sven reasoning and core team. It is very frustrating.

I think we need fresh air and MORE POSITIVE energy around FPC/Pascal. Your project inspired me to many open source work (!). Today I have for "our" mormotish FPC compiler few extensions (all already works!):

- management operators
- nullable types / optional types
- new kind of "specialized helpers" for types like interfaces, dynamic arrays etc.
- more usable variant record
- smart pointers
- arc objects

I need just few days to publish this (few tests), let me do that fork on github together with merge for other forks (RTTI for interfaces + RTTI attributes + Generics.Collections + few bug fixes for compiler + mentioned above changes).

Last edited by hnb (2016-05-31 09:38:16)

hnb · 2016-05-31 09:53:08

Additionally after our FPC fork, I can publish simple Lazarus "pendrive" edition used in my company ^^. (for now windows only)

Leslie7 · 2016-05-31 12:58:14

hnb wrote:

Thanks for links, I will start my work soon.
http://www.cromis.net/blog/2013/02/tany … container/
TAnyValue was my inspiration for management operators (Initialize,Finalize,Copy,Clone):
https://plus.google.com/115782878581272 … nmCLHf2xCd

TOmniValue might be worth a look for ideas.

http://www.thedelphigeek.com/2010/03/sp … e-and.html

Last edited by Leslie7 (2016-05-31 12:58:51)

ab · 2016-05-31 15:50:23

@hnb
It could be indeed a good idea to maintain our own fork.
If it is not too much work!

I do not see any problem including some of your patches, as soon as it does not break the installation of other components.
The idea is to have a Lazarus distro which may be used as a replacement from the current trunk version.

About new compiler features, my proposal is that any patch should include its own FPC_HAS... conditional define, to identify that we are running on a patched compiler, and that new features are available.
And that we don't include any patch or unit from dubious source, as the ORCA/DXScene library in CodeTyphon.

All this may help both FPC/Lazarus and mORMot Open Source projects.
This distribution may be close to Ubuntu against Debian. Less conservative, but also less stable. Less platforms supported, but with latest features on main Linux/Windows targets.
This is what is good about forking: if it is on a purpose, it could benefit from anyone willing to contribute!

I guess I could also help at compiler level.
I start understanding how the FPC compiler works...

edwinsn · 2016-05-31 15:52:03

@hnb, Wow! Wonderful. And exciting!

Last edited by edwinsn (2016-05-31 15:52:27)

AOG · 2016-06-01 04:40:24

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

Last edited by AOG (2016-06-01 04:41:53)

AOG · 2016-06-01 06:53:05

Here is a first try !
Reports are welcome.

https://github.com/LongDirtyAnimAlf/fpc … otBase.zip

Edit:
Forgot to mention, that you HAVE to follow the install rules !!!
https://github.com/LongDirtyAnimAlf/fpc … s/tag/v1.0

Last edited by AOG (2016-06-01 11:19:08)

edwinsn · 2016-06-01 07:53:32

@AOG,

I think just zip file would be enough, it's just like a so-called portable software, the one I downloaded from your Google drive was OK - as you definitely know, I have successfully configured it and compiled the mORMot MVC demo.

But it'll be ever better if people can exact it to any folder - I'm just saying, I can live with the current situation - it's in my C:\fpclazrtticross folder.

For the mORMot part, I would prefer to configure it myself, as I did, as long as we have a clear instruction online.

Just my 2 cents. Great work, you all!

AOG · 2016-06-01 08:10:31

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.

ab · 2016-06-01 08:36:55

Perhaps a mustache template may help a lot here.
Provide all batch as templates, then change all path at setup.

We need some clear instructions, though, for beginners/reviewers of the FPC+Lazarus+mORMot solution.
A one-pass setup, with no manual modification whatsoever could be a big live changer!

hnb · 2016-06-01 08:38:20

To omit confusion and for better identification, new IP is needed. I have domain newpascal.org and I'd like to create modern small start page to link github, zip packages to download and mORMot forum (see below ab).

We are Pascal users so name like Pascal++ is wrong. I think New(Pascal); is what we want.

@ab
as you know licensing is always my top priority (my discussion about mORMot LGPL license), so library like Orca is rejected by definition. I agree with all points.

I think I can help in topic "how to start work on compiler", maybe some small PDF is good idea.

If all "compiler changes" are marked with comments like:

  original_fpc_code;
{ new pascal compiler begin }
  our_changes;
{ new pascal compiler end }
  original_fpc_code;

then maintenance of fork with merging is quite simple. A simple and effective trick used by Typhon developers (I don't like them but this is quite good approach as addition for WinMerge or for other tools). Additional "mark comment" was extremely usefully for my Sparta project.

Any of my compiler change is full backward compatible and optional (unlike ARC objects in Delphi). If you like NewPascal name I think is good to have also more generic conditional define than FPC_HAS_*, I mean NPC (beside the FPC).

I have one question:
Is possible to use part of mORMot forum as "home forum" for our pascal fork? I think the best place is just below "mORMot Framework" subforum.

@AOG
The most frustrating was Sven for management operators. All was developed as he wanted, with Florian cooperation. For final release he told me in shortcut : "sorry I changed my mind, I won't include your changes in trunk"... Fortunately Florian has different opinion than Sven. I have much more examples but I think the more important is to keep positive energy.

AOG you have good ideas, but please give me time.

All of those *.zip can be done automatically for major platforms on github for each commit or for tags. I'd like to finish few scripts for github as our start point. When I take all together I will give you (ab and AOG) access as admins.

We don't need any installer, ever. We can have unique solution because is possible to create zip (Lazarus + FPC + mORMot) which can be unpacked in custom directory (for example is possible to get full individual IDE + Compiler + mORMot for each project on single machine). It requires dark magic knowledge (without improper tricks) but is quite simple.

edwinsn · 2016-06-01 11:41:26

@Maciej,

First, I appreciate and admire your contribution to FPC.

With respect, I would ask, is it really a good idea to change the language name? The bottom line is, the planned FPC fork should provide full backward compatibility for the official FPC.

Re. the website, I would strongly suggest to use github.io. Because you'll be able to collaborate on github.com, because, with respect, I assume github will generally last longer than other webistes But all after all, it'll be the decision you guys should make.

Re. installer, yes, I agree with you, I don't think it's worth to spend the time to make the installer script and compile for each release. We programmers should be able to deal with zip files

hnb · 2016-06-01 12:01:55

@edwinsn it is still FPC, NewPascal is just fork name with full credits for FPC and with full backward compatibility for the official FPC. We need to somehow distinguish between FPC and the FPC dedicated for our purposes.

github.io is worth to consider , seems good for me.

Mentioned zip file is special zip - included Lazarus should be ultra easy to run.

Last edited by hnb (2016-06-01 12:02:33)

edwinsn · 2016-06-01 12:07:55

Yes, a download-and-ready-to-use Lazarus distribution with cross-compile feature would definitely greatly lower the barrier for people to built web services with FPC/mORMot.

I'm saying so because I know the difficulty

Last edited by edwinsn (2016-06-01 12:08:09)

moctes · 2016-06-01 17:43:30

@AOG

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.

I am, please go on

@AB

We need some clear instructions, though, for beginners/reviewers of the FPC+Lazarus+mORMot solution.
A one-pass setup, with no manual modification whatsoever could be a big live changer!

Agreed, I'm ready to give it a shot if you need some feedback

@hnb

it is still FPC, NewPascal is just fork name with full credits for FPC and with full backward compatibility for the official FPC. We need to somehow distinguish between FPC and the FPC dedicated for our purposes.

Great! I like that too, compatibilty is dead serious, this is all very exciting I'll be watching the progress

d.ioannidis · 2016-06-03 13:27:27

Hi,

ab wrote:

@hnb
It could be indeed a good idea to maintain our own fork.
If it is not too much work!

hnb wrote:

I think we need fresh air and MORE POSITIVE energy around FPC/Pascal. Your project inspired me to many open source work (!). Today I have for "our" mormotish FPC compiler few extensions (all already works!)

IMO, forking FPC, at this time, is something that mormot doesn't need .

As Eric Raymond says in ‘Homesteading the Noosphere’ in ‘The Cathedral & the Bazaar”:

" There is a strong social pressure against forking projects. It does not happen except under plea of dire necessity, with much public self-justification, and requires re-naming."

Food for thought from James Dixon ( founder of Pentaho ).

Forking Protocol: Why, When, and How to Fork an Open Source Project

regards,

--
Dimitrios Chr. Ioannidis

Chaa · 2016-06-16 09:48:02

With the latest changes for Linux support there is a problem with exception handling on x64 Windows (I use EMVCApplication).

I see "Debugger Fault Notification" message in RaiseException call.

If I restore code to old version, exceptions worked as expected:

procedure CallMethod(var Args: TCallMethodArgs);
{$ifdef CPUX64}
assembler;
asm
    .params 64    // size for 64 parameters
    .pushnv r12   // generate prolog+epilog to save and restore non-volatile r12
    // get Args
    mov r12, Args
    ...
@d: movlpd qword ptr [r12].TCallMethodArgs.res64, xmm0
@e:
end;
{$endif CPUX64}

I think the ploblem in RBP register value.

Delphi XE5 complier creates code like this:

push rbp
push r12
sub rsp,$208
mov rbp,rsp
....
lea rsp,rpb+$208
pop r12
pop rbp
ret

Last edited by Chaa (2016-06-16 09:49:20)

ab · 2016-06-16 12:06:10

@Chaa
Please try http://synopse.info/fossil/info/c0b0fced3e

Chaa · 2016-06-17 05:40:11

ab wrote:

Please try http://synopse.info/fossil/info/c0b0fced3e

Thanks, now it works.

ab wrote:

ensure CallMethod() on x86-64/Delphi use regular .params command for easier debugging

No, problem not in debugging, but in exception handling.

Release build crashed as well (in KERNELBASE.DLL!RaiseException). I think the ploblem in RBP register value:

Delphi asm          Manual asm
----------------    ----------------
push rbp, r12       push rbp, r12
sub rsp,$208        mov rbp,rsp
mov rbp,rsp         lea rsp,[rsp-MAX_EXECSTACK] + and rsp, -16
....                ...
lea rsp,rbp+$208    mov rsp, rbp
pop r12, rbp        pop r12, rbp

Can somebody check exception handling in Interface-based services in 64 bit FPC under Windows?

AOG · 2016-06-17 07:30:25

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

Chaa · 2016-06-17 09:10:25

AOG wrote:

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

Start with sample "14 - Interface based services".

Then in file Project14Server*.dpr change function TServiceCalculator.Add:

function TServiceCalculator.Add(n1, n2: integer): integer;
begin
  raise Exception.Create('Hello, world!');
  result := n1+n2;
end;

Change target platform to 64-bit windows and run server.

Then call ICalculator.Add from client.

You can see APPCRASH in KERNELBASE.DLL!RaiseException.

AOG · 2016-06-17 10:29:09

Working as expected.
I get a nice "Hello World" exception while debugging with MinGW GDB under Win64/FPC64.
See: https://drive.google.com/open?id=0B96fg … TdtRGp1cGs

Last edited by AOG (2016-06-17 10:30:59)

ab · 2016-06-17 11:36:09

http://synopse.info/fossil/info/c0b0fced3e was only for Delphi Win64 target.
FPC version was untouched...

I have difficulties find out what is the error here...

Chaa · 2016-06-17 15:04:05

I downloaded FPC+Lazarus from FPCmORMot.

Then I download mORMot 1.18.2751, because in 1.18.2752 there was access violation in TDynArray.Init.
Open project options and set Target OS = Win64 and Target CPU family = x86_64.

After exception raised I see Windows Error Reporting tool:

<ProblemSignatures>
	<EventType>APPCRASH</EventType>
	<Parameter0>Project14ServerInMemory.exe</Parameter0>
	<Parameter1>0.0.0.0</Parameter1>
	<Parameter2>00000000</Parameter2>
	<Parameter3>KERNELBASE.dll</Parameter3>
	<Parameter4>6.1.7601.19160</Parameter4>
	<Parameter5>56bcd73c</Parameter5>
	<Parameter6>e0465043</Parameter6>
	<Parameter7>000000000000965d</Parameter7>
</ProblemSignatures>

Sadly, I have not found how to start the debugger for 64-bit executable in Lazarus.

ab · 2016-06-17 16:21:38

There was a breaking change in FPC trunk this month.
All pointers storage in the RTTI information changed.
Please see http://wiki.freepascal.org/User_Changes … mat_change

Please try http://synopse.info/fossil/info/6192ddb9da

@AOG
If you have issues with this commit (e.g. if you have a trunk from this month), disable HASDIRECTTYPEINFO conditional below $ifdef VER3_1 in Synopse.inc.
I would disable it by default in a few weeks, when the trunk would be stabilized...

AOG · 2016-06-18 05:21:18

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

ab · 2016-06-18 05:43:59

@AOG
I still do not understand why this breaking change was introduced by Sven with no associated FPC_HAS_* conditional, and at the same time the non-breaking RTTI interface has not yet been included!
The RTTI for interfaces won't break anything, since it was a missing set of information...
Whereas this PTypeInfo binary modification was really breaking everything...
I was not able to find a way to detect this change, and use the new TypeInfo.pas' DeRefPTypeInfoPtr() function...

We may add a FPC_NEWPASCAL conditional with an increasing number for our FPC fork, to mitigate such issues?

ab · 2016-06-18 13:28:45

I think HASDIRECTTYPEINFO has to be undefined for the trunk, and defined for 3.0 branch.
Older revision of the trunk would just have to define HASDIRECTTYPEINFO if needed.

See http://synopse.info/fossil/info/678067ff08

AOG · 2016-06-18 15:27:39

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.

ab · 2016-06-18 15:42:37

We may use this policy: let mORMot work directly with FPC trunk and latest FPC stable branch (e.g. upcoming 3.0.2).

hnb · 2016-06-18 16:58:48

ab wrote:

We may use this policy: let mORMot work directly with FPC trunk and latest FPC stable branch (e.g. upcoming 3.0.2).

We can get example from FPC RTL:

FPC RTL must be compileable with the latest release and with trunk. Make cycle compiles 3 times compiler. First pass will compile the RTL
with latest stable release.

To get ride of breaking changes between stable release and trunk version is used:

{$if FPC_FULLVERSION>30100} or {$IFNDEF VER3_0}

FPC_FULLVERSION is IMO more PRO . I see 3 scenarios to handle:

1. FPC_FULLVERSION>30100 to detect FPC trunk
2. FPC_FULLVERSION<30100 to detect latest release
3. FPC_NEWPASCAL or NPC to detect our tuned fork.

maybe I will be able to run complete auto-build system for our fork in this weekend.

edwinsn · 2016-06-23 15:35:30

@ab,

Do you think it makes sense to have a first-level link from this website to @AOG's https://github.com/LongDirtyAnimAlf/fpctrunkrtti

mORMot Open Source

#51 2016-05-23 12:18:14

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#52 2016-05-23 20:12:10

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#53 2016-05-27 19:39:16

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#54 2016-05-27 20:16:09

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#55 2016-05-28 13:04:13

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#56 2016-05-28 15:40:36

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#57 2016-05-28 16:09:08

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#58 2016-05-29 07:08:52

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#59 2016-05-29 07:31:11

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#60 2016-05-29 07:48:21

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#61 2016-05-29 10:34:17

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#62 2016-05-29 13:24:01

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#63 2016-05-29 16:00:24

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#64 2016-05-29 16:23:14

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#65 2016-05-29 17:56:28

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#66 2016-05-30 08:45:53

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#67 2016-05-31 08:11:46

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#68 2016-05-31 08:47:46

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#69 2016-05-31 09:35:36

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#70 2016-05-31 09:53:08

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#71 2016-05-31 12:58:14

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#72 2016-05-31 15:50:23

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#73 2016-05-31 15:52:03

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#74 2016-06-01 04:40:24

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#75 2016-06-01 06:53:05

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#76 2016-06-01 07:53:32

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#77 2016-06-01 08:10:31

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#78 2016-06-01 08:36:55

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#79 2016-06-01 08:38:20

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#80 2016-06-01 11:41:26

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#81 2016-06-01 12:01:55

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#82 2016-06-01 12:07:55

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#83 2016-06-01 17:43:30

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#84 2016-06-03 13:27:27

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#85 2016-06-16 09:48:02

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#86 2016-06-16 12:06:10

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#87 2016-06-17 05:40:11

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#88 2016-06-17 07:30:25

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#89 2016-06-17 09:10:25

Re: Some findings after spent an afternoon fiddling Linux/Lazarus/mORMot

#90 2016-06-17 10:29:09