Just installed Delphi 10.3 and used migrationtool.exe to import 10.2 settings, and my projects fail to compile with the following error (I am not even compiling a BPL, and all the directories mentioned in the argument exists)

[Fatal Error] The "HasTrailingSlash" function only accepts a scalar value, but its argument "$(DCC_BplOutput)" evaluates to "C:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl\Win64;s:\BPLs\XE10-64" which is not a scalar value. c:\program files (x86)\embarcadero\studio\20.0\Bin\CodeGear.Delphi.Targets

Any ideas where this setting now lives or can be fixed ?

Looks like edn.embarcadero.com is down, and I need to access it to reinstall a Delphi... did the url change?

Benchmarking a new xxHash32 implementation for Delphi.

xxHash rules the roost when hashing 48 bytes or more, and holds its own on small sizes, only losing to FNV when hashing less than 4 bytes. Hashing quality looks quite good.

Anyone knows of a "reference" binary I could benchmark against? (compiled my own, but I am uncertain if it is running as fast as it could)

How long before EMBT support responds to registration limits extensions these days?

Reinstalled on Friday, thinking I could rely on the 14 days grace period to get me through, only to get stuck on the command-line compiler being disabled during the grace period, which in turn prevents JCL from installing...

I got a request about showing the recent changes from https://quality.embarcadero.com/ on https://www.beginend.net/, however there does not seem to be a public feed... or is there?

Following recent bug findings, anybody up for a TryStrToFloat mini "fast code" challenge ?

You could contribute in two ways:
- code implementations :)
- testing material !

Testing material would be either special cases or datasets of actual float strings you encounter in the field (ideally streamlined in "one float per line" plain text files)

The aim would be performance while being "as good as" historical 32bits StrToFloat on both Delphi 32 and 64 bit compilers in terms of precision.
So without C's strtod correctness requirements, as that would be staring at an abyss of complexity I assume very few of us need (cf. http://www.exploringbinary.com/how-strtod-works-and-sometimes-doesnt/ for a peek at the abyss)

Microsoft will include an x86 emulator in a new ARM Windows 10 version, so that full desktop "classic" apps can run on ARM, opening a whole new set of hardware to "classic" Delphi apps!

The interesting tidbit is that the emulator will be for 32bits x86 apps... this might bring renewed life to ye olde 32bits Delphi compiler, and probably means 32bits Windows apps will be around for an even longer time than anticipated.

I wonder if x86-32-emulated-in-ARM will run faster than Delphi-ARM compiled apps? While unlikely, some wonders have been done to run ARM-emulated-in-x86 at high performance (Intel's Houdini for Android), and Delphi-ARM code generation is not exactly stellar, so depending on the amount of work MS will invest, who knows...

http://www.theverge.com/2016/12/7/13866936/microsoft-windows-10-arm-desktop-apps-support-qualcomm

In comment of +Jim McKeeth 's "How big is your Delphi project?" (http://community.embarcadero.com/blogs?view=entry&id=8890 which does not allow comments).

Largest binary here is 1.57 millions lines, full build in about 15 seconds, with optimizations and detailed map file (without map file, build takes 12 seconds). This is with XE 32bits.

...and this is with an "old" AMD Phenom II CPU. Compile times are definitely one of the reasons I keep using Delphi.

Hopefully compiler speed will be a renewed focus for future Delphi versions!

I have been looking at +Rudy Velthuis BigIntegers unit (http://rvelthuis.de/programs/bigintegers.html) with an eye to using it in DWScript.

The contact email appears invalid, and there does not seem to be a repository.... In case you're reading this Rudy, I have a couple bug fixes to report, and some question about moving it to a repository :)

https://freedom-to-tinker.com/blog/aylin/when-coding-style-survives-compilation-de-anonymizing-programmers-from-executable-binaries/

I often recognize developers just from their source code style and variable naming habits, but it looks like you can recognize developers from their compiled binary with a reasonable accuracy... even with symbols and debug information stripped off.