First look at XE7
So XE7 came out today. I downloaded it and installed it, curious about some of the stuff I’d heard.
So first, the installation experience. I really have no idea why it’s so needlessly complicated, but in order to install Delphi with the Android support, you need to do the whole thing twice: once without it and then again for the “add-on”. (Yeah, I got it. Remember my complaint a year ago about Embarcadero’s handling of all this? Well, to my surprise they actually listened!) The second install doesn’t seem to be installing an add-on; it looks like it’s running the entire installation process again! Why?!?
But despite the excessively lengthy installation process, everything went smoothly, with no interruptions, errors, or requests after it started actually installing things. That’s a huge improvement over the early Embarcadero days!
Next, I opened up the \source folder in Beyond Compare, checking it against XE6’s RTL. It found changes all over the place, but the vast majority of them were minor refactoring things. The only significant thing I found (outside of the cross-platform stuff, which I admittedly didn’t look too closely at) was the addition of the System.Threading unit, which adds a thread pool, a Task class, a Future<T> class, and a TParallel static class offering two basic functions: For and Join. (Join, as near as I can tell, is a special type of parallel for loop that works on an array of function pointers. Not sure why that’s something distinct from the normal parallel for loop.)
Also, there have been some syntactic improvements in array handling. It’s possible to declare a new array literal surrounded by brackets rather than parenthesis, like DWS and Oxygene. But there seem to be a few quirks in it.
[code lang="Delphi"]
const
GOOD: array of integer = [1, 2, 3, 4]; //this works
BAD: array of integer = (1, 2, 3, 4); //error
GOOD2: array [0..3] of integer = (1, 2, 3, 4); //this works
var
values: array of integer;
begin
values := GOOD; //[dcc32 Error]: E2008 Incompatible types
values := GOOD2; //[dcc32 Error]: E2010 Incompatible types:
// 'Dynamic array' and 'array[0..3] of Integer'
values := [1, 2, 3, 4]; //this works
values := values + [5, 6, 7]; //this works too! Yay!
end;
[/code]
However, if “GOOD” and “values” are both defined as TArray<integer> instead, it compiles and works as expected. So it’s the ancient Pascal array identity problem rearing its ugly head once more. Delphi has improved on enough classic Pascal points where room exists for improvement; why doesn’t it just finally make “array of X” always assignment-compatible with itself and get it over with? DWS does that and it works just fine!
The array concatenation syntax is interesting, though to be perfectly honest I don’t see much of a use case for it. But being able to do it is kind of cool, I guess.
So that’s it for now. I think enough things have finally improved in the language to make it worth taking a serious look at updating the TURBU codebase (currently still on XE) to the new version. I’ll have to see what that process is like.
I’d also like to update DWS to run on Android. I’ve been poking around with Android development for a while now, and one thing I was a bit horrified to learn is that there’s no good scripting solution anywhere. Script engines in general are in very short supply in Java-land, and the few that exist appear to be JVM only, with little or no Dalvik support. Android has something it calls a script system, but that’s for running self-contained “script apps”; there’s essentially no such thing as an in-process script engine to automate a larger program, at least if you don’t want to use JavaScript. (And it should come as no surprise to hear that I don’t. James Iry was absolutely right about it in his satirical comments on the history of languages!) DWS still has a few rough edges, (hey Eric, when are we gonna get closures?!?) but it’s a very nice scripting system, especially for those of us with a Delphi background, and it would be awesome to get it working on Android.
So, what’s your first impression of XE7? As always, comments are welcome, but please note that it is not actually a first impression if you haven’t actually installed and used the product yet. 🙂
“why doesn’t it just finally make “array of X” always assignment-compatible with itself and get it over with?”
Because we have TArray which does that.
TArray is a bit of over-engineering/obfuscation/hack TBH, why add a generic layer where the language is already perfectly descriptive?
“array of xxx” perfectly readable, easy to type
“TArray” weird to read, annoying to type (on azerty keyboard)
🙂
To avoid the double run while installing with mobile, I always download the ISO version of the installer.
Windows 8 can mount it directly.
“why doesn’t it just finally make “array of X” always assignment-compatible with itself and get it over with?”
Becasue if the compiler doesn’t properly check for array sizes it’s a buffer overflow? Dynamic arrays has a different assign semantic than static ones. If SA and SB are static arrays, and DA and DB are dynamic, SA := SB is not the same than DA := DB. The former copies data, the latter makes SA point to SB data. The former could be highly optimized by the compiler without risks of buffer overflows.
So how SA := DA should work? Copy data? Probably. But it would also need proper run-time checks to ensure it doesn’t lead to a buffer overflow. But what about is SA is declared array [n..m] of something, where n > 0 (you can do it in Delphi…) while dynamic arrays are always zero based? Is it correct to copy data at different array indexes just because the array size is the same? Or indexes should be respected? And what to do if the array don’t match? Raise an exception? Copy what fits and ignore the rest?
I’m not that surprised that many vulnerabilities, even big, dangerous ones, have their root in overflows. Developers always prefer lazy coding over strong checks. Just, today, it can mean to be p0wned…
I meant “array of X”, specifically, as a dynamic array. But likewise, “array[y..z] of x” should always be compatible with itself. When the data type and the defined bounds are identical, there is no risk of overflow.
@KM It’s nothing to do with that at all.
Retested the Scimark test here http://code.google.com/p/scimark-delphi/
x64 bit compiler generates same results for XE7 and XE6, upd 1.
For the x32 bit compiler, something has happened again.
This is XE6, upd 1 32 bit
Mininum running time = 2,00 seconds
Composite Score MFlops: 551,86
FFT Mflops: 278,19 (N=1024)
SOR Mflops: 863,72 (100 x 100)
MonteCarlo: Mflops: 169,52
Sparse matmult Mflops: 340,09 (N=1000, nz=5000)
LU Mflops: 1107,78 (M=100, N=100)
This is XE7 32 bit
Mininum running time = 2,00 seconds
Composite Score MFlops: 748,82
FFT Mflops: 358,31 (N=1024)
SOR Mflops: 1165,38 (100 x 100)
MonteCarlo: Mflops: 162,34
Sparse matmult Mflops: 509,22 (N=1000, nz=5000)
LU Mflops: 1548,88 (M=100, N=100)
And in a positive way, I mean. (The more MFlops, the better).
Overall the IDE seems solid and snappier.
My bad. Used the old XE6 without update 1. Correct results are more or less the same with XE7 and XE6 upd 1. Sorry.
How does it compare with XE on the same machine?
IIRC the performance loss was a bit higher than 35% in some cases.
Main bottleneck to running DWS on Delphi Android will likely be ARC, though it’s just a guess.
There may be other quirks in Delphi LLVM compiler & RTL which will prove more problematic (like how complete/compatible the Variant support is).
Report about what kind of errors/issues you encounter! (I do not have the mobile add-on, and would not have much time to work on it anyway)
Actually the biggest problem seems to be DWSXPlatform.pas, which… well… just isn’t. It does cross-compiler compatibility, ensuring that you can build on Delphi for Windows or FPC for Windows, but it makes a strong assumption that TRTLCRiticalSection, various unavailable string types, and a handful of WinAPI stuff will all be available.
dwsXPlatform is meant to hold all cross-platform code, but only support those it was written for and tested against 🙂
The idea is that all the platform-specific ifdef’ing should happen there and nowhere else, with missing functionality mimic’ed, aliased, mocked up or recreated as needed.
It means that for TFixedCriticalSection f.i you should add an ifdef to map it to the platform’s equivalent capability. TCriticalSection could probably serve as a temporary ersatz for Android I suppose, though using the actual android OS critical section directly might be preferable as it’ll be more stable across Delphi versions, and can more easily be fixed.
One of the reason why dwsXPlatform skirts or recreates RTL function is in part to avoid bugs in RTL functions and in part to give access to functions that don’t exist in older Delphi versions (or whose behavior was changed in later Delphi versions)
Hi, Mason —
I just purchased and downloaded XE7, and I’m looking forward to digging into it. I haven’t upgraded in a while, but it’s been accumulating enough new goodies to push me over the edge. One I’m eager to explore is the FastCube 2 component that was a freebie with purchase. I’m wondering if anyone has any experience with that.
By the way, I noticed that you mentioned you develop “an industry-leading app that you’ve probably never heard of unless you work in broadcast media.” Very cool!!!! I’m the guy behind T-View, a television audience system that is used by major agencies and several cable nets, and it’s 100% written in Delphi. (See http://www.shsmedia.com/tview/)
Nice to know there are other Delphi fans in this field! Let’s keep in touch!
Kevin Killion
[…] First look at XE7: […]