Just pushed a few changes to the DWScript repository for compatibility with the just released Delphi 11 Alexandria.
The only change required was related to a fix of the Delphi compiler, which now properly has integer overflow checks controlled by $OVERFLOWCHECKS while they were previously controlled by $RANGECHECKS.
I also added support for the Delphi 11 dialect for binary literals (starting with %). DWScript already supported binary literals with the “0b” prefix since 2012 (as in C), I had been hoping the % symbol would not be sacrificed for this purpose, but oh well. (more…)
After battling for half a day with that subtle bug, I am posting the workaround and analysis here, in case other stumble on it.
The issue lies with the TWICImage class, which encapsulates Microsoft Windows Imaging Component, and can be triggered in multi-threaded usage scenarios, particularly in services.
Just a quick notice that the DWScript source code has begun a transition to Delphi 10.2.3 up from Delphi XE.
The goal is to target Win32 and Win64 compilers, mobile platforms and Delphi Linux are currently not in the scope.
Last week www.beginend.net was launched with the goal of aggregating Pascal and Delphi blogs in a mobile-friendly, secure website with a minimalist UI.
A new syntax-highlighting editor has been unleashed upon the Delphi world by Lasse Rautiainen, it’s named TBCEditor, and it is quite full-featured, clean, stable and fast.
The main source code is TBCEditor on github and supports Delphi XE4-XE8, I have made a fork TBCEditorXE on bitbucket which supports XE.
A trivial way to turn a case-sensitive String hash function into a case-insensitive one is to to pass a lower-case (or upper-case) version of the String.
However, in our days of Unicode strings, this is not innocuous…
Following a recent post by A. Bouchez about an optimized CRC32 hash, I took it as an opportunity to re-run a small String Hashing Shootout on the worst hash function collision torture test I know: ZIP codes in UTF-16 (Delphi’s default String format).
In a Google+ comment to my recent article about inlining in XE6, Leif Uneus posted results from Scimark.
It appears that XE6 is about 30% slower than previous versions at least from XE5 to XE for 32bits floating point.
Note that Scimark does not make use of inlining, but does make heavy use of floating-point computations, loops and arrays.
Edit: issue discussed here was reported in QC 124652 (now marked as resolved)
First noticed by dewresearch, Delphi XE6 introduced a new optimization for inlined functions that return a floating-point value.
Here is an exploration of what was improved… and what was not improved.
Inspired by a recent question by Bruce McGee in the Delphi non-tech forum, here are a couple of mini-polls.
Who purchase the Delphi you use?
Do you use Delphi for work, hobby or both?