11

I just bought XE2 version, installed the update 1 ISO, and made my Open Source projects compile with it.

In fact:

  • I added the source code paths of the library to the general settings IDE (for all platforms I use, i.e. Windows 32 bit and 64 bit up to now);
  • I compiled the TestSQLite3.dpr regression tests of our framework - no problem: EXE is compiled and all tests passed;
  • I've a strange issue with the IDE background compilers: even if the project compiled, the IDE displays some errors about unknown files (not in the bottom compiler messages, but in the top of the classes navigation tree - left to the source code editor), and in the .dpr source code, the unit names are underlined in red, and I'm not able to navigate inside the source (using Ctrl+Click on a symbol).

I've added the source code paths of the library to the project options (for Win32/Win64 - even if it was already set at the global IDE level). Now the errors about unknown files disappeared, but the unit names are still underlined in red in the source code, and the Ctrl+Click does not work.

The TestSQLite3.dpr source code do not specify the full path of the units:

uses
  {$I SynDprUses.inc}
  Windows,
  Messages,
  SysUtils,
  Classes,
  SynCrypto,
  SynCrtSock,
  SynCommons,
  SynDB,
  SynOleDB,
  SynDBOracle,
  (...)

In the above lines, SynCrypto, SynCrtSock, SynCommons are underlined in red.

My actual guess is that full paths are needed in the .dpr (SynCrypto in '..\SynCrypto.pas'). I did not test this because I don't have XE2 at work.

Since there was no issue with the previous IDE with this kind of source code (it worked from Delphi 6 up to XE), I wonder if there is a possibility of regression, or a new option not available with the previous version of the IDE (probably platform-based) which I did not set properly. Or perhaps the full path is now needed in .dpr - but this sounds like a regression in the Code/Error Insight compiler to me.

Arnaud Bouchez
  • 42,305
  • 3
  • 71
  • 159
  • Still the same issue with Update 2. The common library folders are not retrieved by the background compilers. – Arnaud Bouchez Nov 04 '11 at 20:32
  • 1
    After Update 3 installation - still the same. I found a solution by getting rid of any code in .dpr and putting all files in an external unit. See http://synopse.info/fossil/info/ddcf953db5 – Arnaud Bouchez Jan 07 '12 at 12:38
  • hello! stumbled upon this in mORMot SAD: " The less frequent queries may be executed other separated collections" - bet you meant "over" not "other" :-) PS. Did you think about adding transactions-awareness to the replication? So that if master/slave connection drops in the middle of the large table update it would not end being half-updated? Obvious solution would be all-or-nothing, however it has its own problems over slow/fuzzy internet – Arioch 'The Apr 01 '15 at 14:53
  • one more glitch. i read online SAD 1.18 html - and in 4.1 section i click over WinAnsiString link. It redirects me to a 404 URL `http://synopse.info/files/html/api-1.18%5CSynCommons.html#WINANSISTRING` - notice the wrong `%5C` there instead of a correct slash single character – Arioch 'The Apr 01 '15 at 15:24
  • @Arioch'The I've tried to fix the doc. Thanks for the feedback! About remote connection, there is the BATCH feature in the framework which allows this automatic transaction. Even our latest master/slave replication uses transactions whenever possible. – Arnaud Bouchez Apr 04 '15 at 11:28
  • Yes, online docs seems fixed. /// yes, but am i right that the replication batch is a all-or-nothing One Grande Batch ? Since the information about "in work" batches seems to be lost when creating record versions. And the replication is designed for slow and unreliable internet scenarios. It reminds me about getting files via mail 20 years ago. Outlook Express makes POP3 connection over 19200 baud dialup, fetches few letters and finally finds some 5MB one. It puuuuuuls it for few minutes until the server says "timeout!" and rolls the transaction back. That is where it all stalls. – Arioch 'The Apr 06 '15 at 13:07
  • I just fear that if there happened to be enough delayed changes that cause the all-updates-blob to fail transmitting, we are in the same trap: new changes would be added making the blob grow like a snowball. And we cannot slice the replication to lesser atoms since we removed transaction information from the record versions. Of course it would not be an issue in case of fast and reliable connection, but in those setups the replication is not needed to start with. – Arioch 'The Apr 06 '15 at 13:10
  • @Arioch'The There is a parameter for replication, so that the data is retrieved by chunk. Huge database content would be retrieved by several smaller calls. And then, asynchronous real-time replication may be enabled. – Arnaud Bouchez Apr 07 '15 at 06:35

2 Answers2

12

I asked the question to Dr Bob (by whom I bought the XE2 license - since the 1 $ = 1 € equation sounded a bit unfair, I wanted at least to have a real Delphi expert for being my reseller).

Here is his answer:

You did not make a mistake. The problem is that the there are three compilers in XE2 (like in previous versions of Delphi): the real compiler (which works fine), the Code Insight compiler (which is faster), the Error Insight compiler (which must be even more faster), and the syntax highlighting parser (which is the fastest).

XE2 introduced a number of features that made the normal compiler slower, and gave the Code Insight and Error Insight compilers a bit of trouble. First of all, we have the new targets: Win32, Win64 and OSX which cause the search paths to be different for each target (see $PLATFORM directive), as well as build configuration, although there is only one "Library path" for each PLATFORM (and not for the build configurations).

The second complexing factor is the dotted unit names (scoped unit names) that were introduced. Windows is no longer Windows, but Winapi.Windows.

My guess is that these two additional complexing factors cause problems for the Code Insight and Error Insight compilers. Note that the real compiler still works. But the Error Insight shows incorrect errors, and the Code Insight doesn't always work for these units.

You could try to explicitly add them to the project again (in which case the full path will be used, like you mention in your question on stack overflow as well).

So I'm afraid this is some regression...

Edit at closing question:

First point is that adding full paths:

  SynPdf in '..\SynPdf.pas',

in the .dpr did let the files been found - but the background compiler is still lost, unable to find a class declaration in this body.

Just another regression sample:

   var Thread: array[0..3] of integer; 
       Handle: array[0..high(Thread)] of integer;

Is a perfectly safe syntax, compiles just fine, was interpreted by the previous Error Insight compiler without any problems (works since Delphi 5), but fails under XE2.

I'm a bit disappointed about XE2 IDE. Compiler makes it work. But IDE is really disappointing. It is not usable, from my point of view. I'll continue using Delphi 7 as my main editor, and just use XE2 as cross-platform compiler and debugger.

Arnaud Bouchez
  • 42,305
  • 3
  • 71
  • 159
  • I had problems with the "scoped unit names" feature of Delphi XE2. This was the main modification I had to apply to our framework source code: the `Graphics` unit has to be labeled as `VCL.Graphics` in the `uses` clause. OK, that's just a matter of a conditional to add, but honestly the less conditionals I have to write in my code, the better. There are a lot of third-party projects (not only Open Sourced) which rely on supporting a lot of Delphi platforms (at least Delphi 7 / 2007). Such regressions are no issue with private applications code, but are not nice for libraries. – Arnaud Bouchez Oct 03 '11 at 12:22
  • 2
    I suspect this is worth a QC entry, what do you think? – Arnaud Bouchez Oct 03 '11 at 14:34
  • 1
    I really feel disappointed about this. Perhaps using FPC should have been enough, and is already better (since it supports more platforms and targets). – Arnaud Bouchez Oct 15 '11 at 11:47
  • The necessary unit scope names can also be passed as `-NS` parameter to the compiler instead (iirc this option exists since Delphi 2009) to avoid conditionals in the code – mjn Oct 15 '11 at 17:35
  • @mjn 1 .The COMPILER works as expected, and there is no conditional in this part of my code. Other IDE-specific background compiler fails to compile valid code, and IMHO they don't use those parameters. Even the Project/Options parameters are ignored by those compilers. 2. And IMHO these issues do not have any link to unit scope name, but to library path for the 1st issue, and incorrect compiler for the 2nd. Perhaps implementing unit scope names broke those compilers, but setting unit scope won't help. – Arnaud Bouchez Oct 17 '11 at 06:36
0

Might be related to what Barry Kelly mentions here:

http://blog.barrkel.com/2011/10/delphi-xe2-compiler-performance.html

Francesca
  • 21,452
  • 4
  • 49
  • 90
  • This article spoke about the main compiler (in IDE and DCC32.exe - the one creating the EXEs), which worked with the source code. The issue is in the background IDE compilers, which seem not to be at the same level than the main Delphi compiler. – Arnaud Bouchez Oct 05 '11 at 12:30