Announcing Elements 8.2

Blog
1

I’m incredibly pleased to announce the immediate availability of Elements 8.2, the next major update to our beloved multi-platform compiler tool chain.

Version 8.2 is the culmination of over six months of hard work from the team, building on the strong 8.0 and 8.1 releases

This is a companion discussion topic for the original entry at http://blogs.remobjects.com/2015/11/17/announcing-elements-8-2/
1 Like
2

Great work!!

I have a few questions.

  1. I have the previous version installed with the 2013 Community edition, is there a version that works within this, or is it for 2015 only?
  2. If I install 8.2 with 2015, will the previous version within 2013 still function.

Regards
David

3

8.2 continues to support Visual Studio 2013 and 2015. If you have 2013 installed already, updating (or freshly installing) Elements 8.2 wil, offer to integrate with it (in addition to optionally offering to install VS2015 for you, as well).

Installing 8.2 will upgrade the compiler system-wide. There is no way to keep 8.1 in VS2013 and having 8.2 in VS2015 at the same time (nor is there a good reason to want that, really ;).

4

And what about VS2012?

5

Visual Studio 2012 support has been dropped. Is there anything specific you need 2012 for?

6

Our company has a terribly long evaluation phase and so we unfortunately still have to use VS 2012. We hope to be able to switch to VS2015 sometimes next year.

7

The problem with Elements 8.2: it does not show anything or complain when installed together with VS2012. The version under About still shows 8.1.83.1.1761.
But now, I can’t compile anymore, everything hangs and I get crazy errors and building hangs forever.

What confuses me most:

  • I had installed 8.1.85.1801 before and did not even realize it was not designed for VS 2012.
  • Even when the version under About still showed 1761, somehow the Compiler must have been updated as I realized some differences between 1761 and 1801!
  • Same with 8.2.89.1891, after installation, build started and detected some new syntactical problems in our code but finally looped forever.
  • Finally, I had to uninstall Oxygene and then do a reinstall.
  • As I did use 1801 before, I tried to install 1801. It completed but I ended up without Oxygene support under VS 2012.
  • Now I went back to 1761, without 1801 and I can compile again.

But questions which remain:

  • Did 8.2 installation somehow install the new compiler and VS 2012 did actually pick up the 8.2 compiler?
  • In this case, 8.2 must have a severe bug which causes build to loop/hang forever in compiling our source!
8

Our installer doesn’t touch VS2012 at all, so it probably never has a chance to refresh what it shows in About. But since all the binaries are updated, hitting build in VS2012 will run the latest compiler. But anything else inside the IDE will probably not work (such as intellisense).

9

Thank you for your response.
That’s about what I expected from what I saw.
But, in this case, we have a serious problem with the latest compiler, as a build of our project seems to hang the compiler.

I’m currently back on 8.1.83.1.1761.
Any ideas how to trace the problem? Under VS2012 upgrade to 8.2 again and try to identify the problem or what till we officially can upgrade to VS 2015?

10

Can you send us the project to support@remobjects.com? We wil keep it confidential.

11

Thanx for your help. But if I send you the complete project, you will go nuts for sure :wink:
I’ll give it another try, install 8.2 again (on VS2012) and try to locate the project which causes the hang.

12

I did give it another try with 8.2 and I could figure out the reason for getting the impression of a compiler loop. It does not loop actually but detects 37879 Errors and to produce the error list takes forever.

The reason for this: we now get an error in one of the low level projects and the rest are more or less related to this.

The error we get is: Error 38645 (E0) Internal error: Object reference not set to an instance of an object. 0 0 Toolbox

13

We’re aware of the speed issues with that many errors, we’ll look into that. however the last error sounds like a compiler bug. Unfortunately there’s very little we can do about that one without a project that shows it.

14

In fact, I don’t care too much about the speed issue. But that’s why I first thought that the compiler loops. In the meantime, I could find the code producing the error:

It’s the assignment (self[i, j] := Varying.Empty;) in the extension method where Varying is a VMS Pascal string class.

extension method (array [0.., 0.. ] of Varying).ZERO;
begin
  for i:Integer := 0 to GetUpperBound(0) do 
    for j:Integer := 0 to GetUpperBound(1) do 
      self[i, j] := Varying.Empty;
end;
15

Where’s the method name? (Or is that the actual error?)

16

The method name is ZERO

17

Another extension method (one that’s not so important, was more a playground, but anyway):

extension method (array [0…, 0…] of Zahlen).ZERO;

begin
var low1 := low(self);
var low2 := low(self[low1]); // Error 149 (E341) Type mismatch, cannot infer type from expression without result type C:\Users\C150932\Source\Spezpla-ISS-Root\ToolboxUnitTestPas\VaryingTestPas.pas 139 15 ToolboxUnitTestPas

18

Thanks, logged as bugs://73720

19

bugs://73720 got closed with status fixed.