mORMot and FPC 3.0/3.1.1

shobits1 · 2016-02-10 15:44:59

I'm trying to test and evaluate mORMot for an upcoming project but when I try to compile `TestSQL3.lpi` using lazarus1.6RC2 (FPC3.0) the compiler returns the following error:

mORMot.pas(22986,7) Error: Internal error 2006111510

Since the document states FPC2.7.1/3.1.1 is required, I was wondering if FPC3.0 won't work.

Now, using Lazarus 1.7/FPC3.1.1 (downloaded from getlazarus.org) the projects compiles ok; but running the generated executable (a self test for the entire framework) reports many errors and eventually crashes.

Any help would be appreciated.

Last edited by shobits1 (2016-02-11 00:15:44)

ab · 2016-02-11 08:59:56

Yes, there are issues, mainly due to string constant comparison in FPC.
In Delphi, AnsiStrings with code page do not handle source constant with a particular code page, when compared with another string. It is handled as it code pages do match.

But FPC has a much more pessimistic approach, and depending on the compiler revision, it may - or may not - make a codepage conversion.
A lot of aString='constant' are failing with FPC, whereas aString DO contain the expected 'constant'.
IMHO FPC AnsiString implementation is still broken, and induce a huge performance penalty.
We are waiting for the RTL and compiler to stabilize, until we make some more changes.

In all cases, the interface-RTTI branch is highly recommended.
Perhaps FPC users may help identifying the problems, and help here.

shobits1 · 2016-02-11 16:22:06

If I understood right, then mORMot is still not fully supported by FPC, and complied projects will not guaranties consistent results and for the time being using Delphi is the only choice.

if I'm right then which version of Delphi is the best to work with mORMot in your honest opinion?

ab · 2016-02-11 16:56:01

Sadly, we do not have full support of all FPC versions.
We would like perhaps to validate a particular version of FPC...

Any version of Delphi, since Delphi 6 would work just fine with mORMot.
About performance, see http://blog.synopse.info/post/2014/06/0 … E4-and-XE6
The latest versions of the IDE tends to have issues with huge main units of the framework (SynCommons.pas and mORMot.pas), so I usually still use Delphi 7 + CnPack when working on mORMot core, then run the regression tests on all compilers I've installed, until Delphi 10.
From my experiment, XE2 and XE6 were pretty stable...
So for end-user code, choice here is a matter of preference.

shobits1 · 2016-02-11 18:51:56

Well, thank you;

I hope FPC improves fast so we all enjoy free development tools.

ab · 2016-02-12 07:56:48

Yes, the latest evolutions of Delphi do not please me so much.
Forcing ARC is for me a showstopper.
See http://blog.synopse.info/post/2016/02/0 … nd-of-2016

This is why FPC may really be the future of mORMot!

shobits1 · 2016-02-12 13:54:55

I'm not expert in the field but I read here and their some developers troubled with recent changes to the compiler; still for me (and many others) a free development tools like Lazarus/FPC is best choice.

BTW, I tried to use the latest version of Lazarus with FPC (rtti branch) the `TestSQL3.lpi` compile fine (with tones of warnings and hints); running it produces errors but doesn't crash like my previous test (using version obtained from getlazarus.org).

Here is the output of `TestSQL3.exe` under Win10 x64 http://pastebin.com/JZMHECae
it also generate huge `TestSQL3 20160212 142455.log` (about 112MB). download the file

is there anything I can do to reduce those errors (e.g compiler option...).
is it safe to build small project using REST where client only request reports from server with one database containing 1 table with about 1 million records.

AOG · 2016-02-13 13:51:28

I will try to identify the FPC problems !

ab · 2016-02-14 12:50:02

@AOG

Thanks a lot!

AOG · 2016-02-14 12:51:33

Would you mind trying this (if you agree):

//{$ifdef FPC_HAS_CPSTRING}
{$ifndef FPC_HAS_UNICODESTRING
// see http://wiki.freepascal.org/FPC_Unicode_support
{$define HASCODEPAGE} // UNICODE means {$mode delphiunicode}
{$endif}

shobits1 · 2016-02-14 19:52:55

AOG, Thanks a lot.

The suggested modification indeed solves good amount of previously reported errors and `TestSQL3 20160214 203025.log` is now ~2.14MB (previously 112MB)

this is `TestSQL3.exe` output http://pastebin.com/X6grS2Q2
and the TestSQL3 20160214 203025.log

AOG · 2016-02-14 21:01:30

That's good to hear.
Debugging mORMot/FPC consumes a lot of time.
So, I still need to know if Ab agrees with this change.
If so, I will continue on the choosen path to try to solve the remaining bugs!

ab · 2016-02-14 21:18:11

In fact http://wiki.freepascal.org/FPC_Unicode_support was very confusing to me.

AOG setting sounds fine.

We should probably go into this direction...

edwinsn · 2016-02-15 05:57:04

Hi, maybe the recent FPC change below, is what breaking the FPC-compatibility of the mORMot source?

http://wiki.freepascal.org/User_Changes … t_platform

AOG · 2016-02-15 09:49:27

In between report:
Even my (temporary) solution as stated above is not working as expected.
It's more complicated than I thought.
FPC is doing all kinds of codepage conversions, consuming enormous amount of (processing) time.
Wiki is indeed confusing.
Going on ...

ab · 2016-02-15 12:54:44

Yes, this is what I've seen too...
The FPC RTL is IMHO half-backed... any string comparison would involve slow charset conversion, which are not needed at all. Delphi 2009 did make something similar, before its first update, AFAIR.
It does not handle RawByteString to be neutral, so it makes a conversion from the current system code page to the compared string code page... whereas I think it should accept RawByteString as a match to any other code page, when comparing strings.

In practice, it slows down A LOT the string process, in comparison to older FPC versions...
I'm wondering why no-one is complaining about this performance regression.

AOG · 2016-02-15 13:36:19

Unfortunately, I have not succeeded in finding a good solution for the string problems, other than some (ugly) hacks.
Perhaps the people behind ZEOS have some good ideas ?
Many people have made remarks about the string-changes.
So, I think, its (still) a moving subject !

Due to limited time, I have to stop debugging for the moment.
Sorry about this. Will go on later.

EgonHugeist · 2016-02-16 05:37:20

Hello Alfred,

we (Zeos-Team) are in same trouble for the moment. Since FPC3 gen all my non usascii tests are broken. Some of them i got running inbetween by declaring some constants like:

MyTestString: UnicodeString = 'äüö';

but up until now i could not find a common design for UTF8 or WIN1252 raw encoded string which would work for all delphis and FPC2.4>3.x.
So my current intention for our test-suites is to continue with the UnicodeString design and replace const declared variables by vars and initialize them on startup. Ugly i know...

Some remarks for the FPC users:
Delphi by default stores the developers code-page of current Delphi environment in the project file. So the compiler always know how to compile conversion required const Strings. From my POV this is the missing point. I do not understand how they are able to decide which encoding a constant string may have...

Since FPC3 we've had so much trouble. Memoryleaks with the RawByteStrings for a long time and users who had been using codetyphoon 5.4...5.6 are in such trouble too. We got loads of bad critics, just because they didn't know anything about the broken FPC3.x gen arrow. Comming CT5.7 is memoryleak free. Puhh good news for Zeos. (personaly i don't know why, the CT guys also patching the compiler such like CT5.7 will have a replaced memorymanger ...)

And of course i know about the damn slow string conversions they are doing. I just suppressed such things by introducing some mover functions with defines in current Zeos design. Which than means Allocate a new RawByteString and move the data is almost faster and safer than trust in what current FPC is doing with the RBS strings. You won't find any line about SetCodePage() somewhere in the Zeos-code. Just because i was in same trouble since a long time. And of course i can undef all the defines if they make me lucky (:
Yes this kills the performance but note such things are not relavant for Zeos+mORMot. This just cames to shove if Zeos is doing the conversion control for FreeTDS f.e. or FireBird+CS_NONE.

According the http://wiki.freepascal.org/FPC_Unicode_support ... I'm confused too. They are writing about "source file codepage" but i can't locate it somewhere in a project. Also the intendet "no conversion happens just increase the refcount" (if target or source string is a RawByteString) sounds very nice... But i can't confirm it this way.

There some more such weired things ... Just compare a PWideChar()^ WideCharacter with a const declared char like 'a' or #0. Or just move some WideChars from a Source to Dest like PW1^ := PW2^.. A performance nightmare.. Dead slow! Using PWord(PW1)^ := PWord(PW2)^ kills the performance leak..

@shobits1

I wouldn't agree saying mORMot or Zeos are not ready for FPC3 ... The more FPC3 isn't ready for such projects
We missed loads of things pre FPC3 but we got a stable behavior until 2.7

Cheers, Michael

AOG · 2016-02-16 13:16:48

@Michael

Thanks for elaboration your point of view !
We are definitely in the same league of problems, so combined efforts will help.

Speaking for myself, I do not have much trouble in putting (much) effort into the (mORMot) source to make it compatible with latest FPC.
But it should be clear (for all of us) how to proceed. Otherwise, a lot of time will be spend in hacking around, in stead of using the right way of handling strings.

And the right way is not yet clear (to me).
For mORMot, omitting CodePage (see above) did solve a lot of errors.
But is it the right thing to do ?

Sure we can expect more string troubles.
But if we choose the right way, and FPC core solves the (string) bugs, than we are good.
Otherwise, time consuming bug-hunting efforts will be a waste of time.

It would be good if the FPC Wiki would contain examples of (future) string handling that follow the new string design of FPC.
I do not (yet) know if they want us to use codepages, and/or unicode, UTF8 and/or UTF16 and/or UTF32.
But we have to remember that FPC has to work on 30+ platforms ... a very difficult task.
So, a certain amount of hacking will always be needed.

Again, I value your input (and others) to decide how to proceed.

Greetings, Alfred.

EgonHugeist · 2016-02-16 14:36:10

@Alfred

consider ALL Lazarus/CodeTyphoon IDE's currently use the {$codepage utf8} define, because of the wrong premisse every string is ut8 encoded.
From my personal POV you'll never be able to get a stable behavior running except your tracking the define which than breaks our tests.. The FPC DefaultSystemCodePage is always set to UTF8. So the failing test regression tests need to be UTF8Encoded !!IF!! this define was set. Same trouble i've on Zeos side.. MyTests just make it possible to run in 3 environements + some subsettings (unrealted here): CP_ACP, CP_UTF8 and CP_UTF16. Zeos is able to make a "floating" behavior ... up until latest FPC3 (just for my test > Zeos it's selves can what i want!) So we'll tag current 7.2-testing as a RC-candidate next days.

Regards, Michael

shobits1 · 2016-02-16 18:08:01

EgonHugeist wrote:

@shobits1
I wouldn't agree saying mORMot or Zeos are not ready for FPC3 ... The more FPC3 isn't ready for such projects

I didn't say that but I said:

shobits1 wrote:

If I understood right, then mORMot is still not fully supported by FPC, and complied projects will not guaranties consistent results ...

Anyway thanks for the clarification; much appreciated .

Last edited by shobits1 (2016-02-16 18:11:14)

AOG · 2016-02-18 10:03:19

@Ab, @all,
Some progress.
Trivial change:

{$ifdef ISFPC27}
//DefaultSystemCodepage := CODEPAGE_US;
DefaultSystemCodepage := CP_UTF8;
{$endif}

The above is, IMHO, a good change(start) to solve some of the problems.
If acceptable (Ab?), I will go on with this change and do som serious bug-hunting ... ;-)

ab · 2016-02-18 10:33:33

Under Windows, I'm afraid it would break any access to the API calls, which expect the text to be encoded with the system code page...

EgonHugeist · 2016-02-18 11:06:27

Hi All,

well this is exactly my issue too. The new LCL IDE's with FPC3 just use the {codepage utf8} define. Result is: all <Ansi>Strings(CP_ACP) have a default encoding of UTF8. So i did this in a differnt way by simply storing a ZOSCodePage which will be initialized on startup like:

procedure SetZOSCodePage;
begin
  {$IFDEF MSWINDOWS}
  ZOSCodePage := GetACP; //available for Windows and WinCE
  {$ELSE}
    {$IFDEF WITH_DEFAULTSYSTEMCODEPAGE}
    ZOSCodePage := Word(DefaultSystemCodePage); << This is for the UnicodeIDE's and FPC2.7+ but broken because of Lazarus 
    {$ELSE}
    ZOSCodePage := CP_UTF8; //how to determine the current OS CP?
    {$ENDIF}
  {$ENDIF}
end;

Instead of trust the DefaultSystemCodepage i just use my lokalized one. Some more remarks: Since the eval LCL is doing that you'll need to check all cast or better you use own conversions like i've introduced them in Zeos.

Hope it helps

AOG · 2016-02-18 11:45:12

Allright ! Sounds good !!
But then, we also need (for the mORMot at least):

SetMultiByteConversionCodePage(CP_UTF8);
SetMultiByteRTLFileSystemCodePage(CP_UTF8);

Edit1:
Just forget the above: it just seems to set the CodePage again to UTF8.

Edit2:

Under Windows, I'm afraid it would break any access to the API calls

I thought, the RTL would handle this: LCL (Lazarus uses UTF8) ??

Last edited by AOG (2016-02-18 12:15:17)

willo · 2016-03-04 11:11:02

Hi guys,

Been looking at FPC / Lazarus lately, even if it's just server side for now. Lazarus is looking GOOD, and the new FPC features looks awesome. What a downer when I found this thread!

@Ab
1. Which of these changes have been implemented?
2. I notices the SAD(#25.4.4) encourages us to use FPC 3.1.1, but using the ComputeFPCInterfacesUnit function.
Are these still options or is 3.1.1 completely broken?

ab · 2016-03-04 17:05:24

Honestly, I did not have time lately to focus back on support of latest versions of FPC...
Since we do not use FPC here on production, and are implementing features on proprietary mORMot-based code using Delphi and (old) CrossKylix, I was not able to go back on this topic.

Alfred did some investigation, and asked for additional information on the FPC-DEV mailist.

AOG · 2016-03-06 11:26:44

In between my normal work, I have done a lot (a LOT) of testing / experiments for the past few weeks, to get FPC and the mORMot back in business again.
To no avail at the moment.

And it remains very silent around the question I asked on the fpc mailing list.

As stated in the fpc-list, it is ok to add some hacks into the mORMot to get things running again, but the hacks need to be based on solid knowledge about (the future of) strings in FPC.

A single hack can consume a day of (debugging) work. An I do not have that much time anymore. Therefor my wish for solid knowledge and solid hacks.

ab · 2016-03-06 16:37:45

My guess is that FPC support of code page is broken, at least for our expectations (which are related to Delphi behavior).
The best option may be to identify all incompatibilities of the FPC RTL, which should work the same as Delphi, in "Delphi mode".
Then create some tickets about each incompatibility.
I'm confident that the FPC team may change their current implementation, for better compatibility with Delphi.
AFAIR it is what they asked for...

AOG · 2016-03-07 09:01:01

@ab.

If you read this:

http://wiki.freepascal.org/Better_Unico … in_Lazarus

What do you think of it ?

ab · 2016-03-08 07:49:55

It is very confusing.
They added some hidden conversions, in regard to what Delphi does, even in Delphi $mode.
There is IMHO some issues about some implicit conversions during string comparison.
AFAIR from my previous (and quick) investigations, I guess there is still some problem with how the code pages where implemented at RTL level.
Some time is needed to find out what is wrong. I hoped we were not the only one facing similar issues. I do not have currently time to do it.
But I would eventually debug & contribute about this subject, since we think that FPC is to be a first class citizen to mORMot.
The upcoming "record constructors" feature from Maciej - see https://plus.google.com/u/0/11578287858 … nmCLHf2xCd - is IMHO an amazing feature for mORMot future.
And the announce that Delphi for Linux would use ARC is a dead end to our code base.

The more I think about it, especially in terms of business risk and for managers, a 100% Open Source solution would definitively be a cleaner alternative than Delphi's.
I did never see anyone complaining about the fact that a software like CouchDB uses Erlang as a language for its core.
We have here some projects involving a mORMot farm of servers, and some back-end using their SOA interfaces from php or node.js.

So eventually, we will support FPC string types.
And we may help debugging the RTL.
But it is not our current highest priority.

AOG · 2016-03-08 08:09:46

I think you already have seen this thread:
http://lists.freepascal.org/pipermail/f … html#36759
and also this one:
http://lists.freepascal.org/pipermail/f … html#36771

Good news for record operators.

The bad news for strings: at the moment the consensus is still to be reached among the FPC core developers.
The good news for strings: its work in progress, but the work will be done in the near future.

For me personally, it is still hard to decide how to proceed with FPC.
Debugging is so time consuming.

But again: FPC + mORMot is such a strong multi-platform product !
Worth the effort !

ab · 2016-03-08 09:58:13

Yes, I find also http://lists.freepascal.org/pipermail/f … 36098.html worth considering...

AOG · 2016-03-14 11:03:25

After doing a lot of research and reading (and a bit of elaborate guessing), I still think the way to go is setting the fpc CodePage to UTF8 !!

  //DefaultSystemCodepage := CODEPAGE_US;
  SetMultiByteConversionCodePage(CP_UTF8);
  SetMultiByteRTLFileSystemCodePage(CP_UTF8);

On my systems, it does not break anything.

I would welcome any report on TestSQL3 results with this setting !

In the meantime, I also filed my first ever FPC bug: http://bugs.freepascal.org/view.php?id=29833

I am curious to learn if this is a real bug, or an error/mistake by me.
mORMot suffers from this "bug", when I set SockString to RawByteString !
(I think SockString must be a RawByteString, also under FPC !!)

shobits1 · 2016-03-16 00:34:18

Thank you AOG,,
it reduces the total failed operations but there is still some reported:

...
!  - Socket API: 92 / 2,274 FAILED  20.32s
     1
!  - Websockets: 79 / 3,405 FAILED  920.34s
     1=6130/s  2=6411/s  5=7164/s  10=6990/s  30=0/s  50=0/s
...
Total failed: 171 / 45,068  - Multi thread process FAILED  944.30s

...
!  - Email validation process: 3 / 55 FAILED  27.91ms
!  - User CQRS repository: 7,002 / 57,106 FAILED  1.01s
  Total failed: 7,005 / 80,443  - DDD shared units FAILED  1.27s

Using mORMot 1.18.2458 FTS3
Running on Windows 10 64bit (10.0.10586) with code page 1252
TSQLite3LibraryStatic 3.11.1 with internal MM
Generated with: Free Pascal 3.1.1 compiler

Time elapsed for all tests: 1034.22s
Tests performed at 16-03-2016 01:28:51

Total assertions failed for all test suits:  7,176 / 21,164,965
! Some tests FAILED: please correct the code.

PS: using FPC RTTI branch and Lazarus Trunk.

Last edited by shobits1 (2016-03-16 00:36:02)

ab · 2016-03-16 07:34:19

My guess is that this change may break almost all Windows API calls, as soon as there is some accents within the text...
Windows never supported UTF-8 as system code page...

AOG · 2016-03-16 07:46:31

@shobits1
Thanks for reporting back.

I know that some errors (as you encountered) still remain (or appear), after my proposed change.
But these can be resolved. Its just bug-hunting.

For now, I wait on the results of the reported "bug" in FPC : http://bugs.freepascal.org/view.php?id=29833
The ZEOS author (EgonHugeist) is also helping on this subject.

Most important thing to know for me: does my proposed change to UTF8 work for all locales (on Windows).
So, I would be interested to know what codepage (locale) you are on !?

mORMot's boss Ab is afraid that the change to UTF8 would break API calls on Windows, but I think that the FPC guys use compiler magic to get things right.
At least, that is what I have learned after searching the Internet for a week on this subject.

The best (for Delphi compatibility) would be a change to real unicode by using {$mode delphiunicode}, but that is not finished yet.
However, I am testing with this setting already, because, acccording to FPC core, this is the way to go into the future (for Delphi compatibility on Windows).

AOG · 2016-03-19 06:59:15

The FPC bug (http://bugs.freepascal.org/view.php?id=29833) has been solved !
With latest FPC trunk and the RTTI patch (installed through fpclazup), the mORMot now runs nearly 100% again.
With (syncommons)

SetMultiByteConversionCodePage(CP_UTF8);
SetMultiByteRTLFileSystemCodePage(CP_UTF8);

and (syncrtsock)

SockString = type RawByteString;

AOG · 2016-10-21 16:00:56

Good news !!!
Some recent changes in FPC trunk (optimizers for i386 by Florian) now allow for a flawless mORMot with -O0, -O1, -O2 and -O3 on i386 !
NewPascal release will soon be updated to include these changes.

joaolevada · 2016-10-24 17:52:03

Hello guys!

I'm starting with mORMot, and trying to use it with FPC and Lazarus.

Downloaded the IDE from NewPascal, opened via link (Lazarus_NewPascal.lnk) and everything works fine. But when I've tried to open TestSQL3.lpi, the IDE starts flickering (??? it must be something with this release of Lazarus), I can build just fine, but I can't make it run. Got this misterious error:

TestSQL3.exe
An unhandled exception occurred at $00463D64:
EAccessViolation: Access violation
  $00463D64
  $00480A4D
  $0047B204
  $0047B2F2
  $005CA7EA
  $005BF60C
  $005BE66A
  $005BE6E9
  $004B5EB9
  $0040E134

Is it something I've missed, or have to wait for a new version of FPC?

Unfortunately, it's out of my plans to get back to Delphi IDE. I found very very pleasant the proposals of mORMot framework on the development subject (Service Oriented Architecture, and DDD, to name a few), but if Delphi is a price, maybe I can't afford.

(Sorry about my poor english. Hope I can help the project somehow)

joaolevada · 2016-10-24 17:59:05

It is always safe to look twice!

Now I finally found the "ccr" sub-folder on NewPascal dir. That put a smile on my face!

The tests are running just fine (well, some errors, but I think those are the expected ones).

AOG · 2016-10-25 06:34:02

Latest mORMot for FPC here: https://github.com/newpascal-ccr/mORMot/

ComingNine · 2016-10-25 10:56:12

AOG wrote:

Latest mORMot for FPC here: https://github.com/newpascal-ccr/mORMot/

Dear AOG, does this mean that we can download zipped archive from that github link and replace the c:\NewPascal\ccr\mORMot ?

If yes, can you comment whether you can keep mORMot in your github link above always sync with http://synopse.info/fossil/timeline ?

Many thanks !

AOG · 2016-10-25 12:29:35

Yes, you can. And should ... ;-)

However, this separate mORMot is (only) created for the benefit of the NewPascal initiative.
This NewPascal has some features that require (small) changes in the mORMot source.

If things are more or less stabilized, the changes could/should be merged with official mORMot. After review.
Much better to have a single source, also because changes required are minor.

But untill then, you are free (with FPC) to use the special mORMot !

ComingNine · 2016-10-26 07:41:47

Many thanks for your helpful comments !

vonH · 2017-03-07 12:38:39

Is newpascal-ccr/mORMot designed to work with stable versions of FPC, eg FPC 3.0.2 and 3.0.0? I read somewhere that it is a version of newpascal/mORMot with some fixes to allow it work on FPC 3.0.2 etc?

I also noticed this announcment on the FPC mailing list - Feature announcement: Interface RTTI - http://lists.freepascal.org/pipermail/f … 50021.html

Does this mean that future versions of mORMot will work directly with FPC trunk without needing any fixes to it?

d.ioannidis · 2017-03-08 11:20:58

Hi,

vonH wrote:

Is newpascal-ccr/mORMot designed to work with stable versions of FPC, eg FPC 3.0.2 and 3.0.0? I read somewhere that it is a version of newpascal/mORMot with some fixes to allow it work on FPC 3.0.2 etc?

there is no need for special mormot version, currently I'm using mormot trunk with fpc 3.0.2 after the hard work of Alfred (AOG), see https://synopse.info/forum/viewtopic.php?id=3852 .

regards,

Last edited by d.ioannidis (2017-03-08 11:32:15)

hnb · 2017-03-08 12:03:06

d.ioannidis wrote:

... there is no need for special mormot version ...

that is true. newpascal-ccr/mORMot was created as temporary solution:

1. to host binary files in repository for supported platforms
2. was created for initial support for Mac.
3. as important part of CI for NewPascal

All is merged now into "upstream" mORMot repository, so even NewPascal CI system uses https://github.com/synopse/mORMot .

vonH · 2017-03-08 18:43:13

hnb wrote:

d.ioannidis wrote:
... there is no need for special mormot version ...
that is true. newpascal-ccr/mORMot was created as temporary solution:
1. to host binary files in repository for supported platforms
2. was created for initial support for Mac.
3. as important part of CI for NewPascal
All is merged now into "upstream" mORMot repository, so even NewPascal CI system uses https://github.com/synopse/mORMot .

What are the additional benefits in NewPascal besides better support for mORMot?

Is there a list of its new features and some code to illustrate them in comparison with FPC? Are they things that the average user might need in their everyday programming? I haven't used any of the newer languages like C# and even the newer versions of Delphi.

Is NewPascal always compatible with the FPC trunk branch it is forked from?

Last edited by vonH (2017-03-08 18:51:04)

AOG · 2017-03-09 07:20:30

@vonH
The trunk changes can be found here: http://wiki.freepascal.org/User_Changes_Trunk
I leave it to hnb to explain more about NewPascal, but in general, NewPascal is a very recent trunk without the dangers of trunk.

mORMot Open Source

#1 2016-02-10 15:44:59

mORMot and FPC 3.0/3.1.1

#2 2016-02-11 08:59:56

Re: mORMot and FPC 3.0/3.1.1

#3 2016-02-11 16:22:06

Re: mORMot and FPC 3.0/3.1.1

#4 2016-02-11 16:56:01

Re: mORMot and FPC 3.0/3.1.1

#5 2016-02-11 18:51:56

Re: mORMot and FPC 3.0/3.1.1

#6 2016-02-12 07:56:48

Re: mORMot and FPC 3.0/3.1.1

#7 2016-02-12 13:54:55

Re: mORMot and FPC 3.0/3.1.1

#8 2016-02-13 13:51:28

Re: mORMot and FPC 3.0/3.1.1

#9 2016-02-14 12:50:02

Re: mORMot and FPC 3.0/3.1.1

#10 2016-02-14 12:51:33

Re: mORMot and FPC 3.0/3.1.1

#11 2016-02-14 19:52:55

Re: mORMot and FPC 3.0/3.1.1

#12 2016-02-14 21:01:30

Re: mORMot and FPC 3.0/3.1.1

#13 2016-02-14 21:18:11

Re: mORMot and FPC 3.0/3.1.1

#14 2016-02-15 05:57:04

Re: mORMot and FPC 3.0/3.1.1

#15 2016-02-15 09:49:27

Re: mORMot and FPC 3.0/3.1.1

#16 2016-02-15 12:54:44

Re: mORMot and FPC 3.0/3.1.1

#17 2016-02-15 13:36:19

Re: mORMot and FPC 3.0/3.1.1

#18 2016-02-16 05:37:20

Re: mORMot and FPC 3.0/3.1.1

#19 2016-02-16 13:16:48

Re: mORMot and FPC 3.0/3.1.1

#20 2016-02-16 14:36:10

Re: mORMot and FPC 3.0/3.1.1

#21 2016-02-16 18:08:01

Re: mORMot and FPC 3.0/3.1.1

#22 2016-02-18 10:03:19

Re: mORMot and FPC 3.0/3.1.1

#23 2016-02-18 10:33:33

Re: mORMot and FPC 3.0/3.1.1

#24 2016-02-18 11:06:27

Re: mORMot and FPC 3.0/3.1.1

#25 2016-02-18 11:45:12

Re: mORMot and FPC 3.0/3.1.1

#26 2016-03-04 11:11:02

Re: mORMot and FPC 3.0/3.1.1

#27 2016-03-04 17:05:24

Re: mORMot and FPC 3.0/3.1.1

#28 2016-03-06 11:26:44

Re: mORMot and FPC 3.0/3.1.1

#29 2016-03-06 16:37:45

Re: mORMot and FPC 3.0/3.1.1

#30 2016-03-07 09:01:01

Re: mORMot and FPC 3.0/3.1.1

#31 2016-03-08 07:49:55

Re: mORMot and FPC 3.0/3.1.1

#32 2016-03-08 08:09:46

Re: mORMot and FPC 3.0/3.1.1

#33 2016-03-08 09:58:13

Re: mORMot and FPC 3.0/3.1.1

#34 2016-03-14 11:03:25

Re: mORMot and FPC 3.0/3.1.1

#35 2016-03-16 00:34:18

Re: mORMot and FPC 3.0/3.1.1

#36 2016-03-16 07:34:19

Re: mORMot and FPC 3.0/3.1.1

#37 2016-03-16 07:46:31

Re: mORMot and FPC 3.0/3.1.1

#38 2016-03-19 06:59:15

Re: mORMot and FPC 3.0/3.1.1

#39 2016-10-21 16:00:56

Re: mORMot and FPC 3.0/3.1.1

#40 2016-10-24 17:52:03