jbg

Another IDEFixPack development snapshot that fixes the IDEFixPack bug RSP-23405 that was reported to Embarcadero. Changelog: - Fixed: With CompilerSpeedPack64 the Win64 compiler generated broken code for asm-blocks

That's a link to the post in the other thread where the download link is.

There is a new IDEFixPack development snapshot that fixes the issue. The TCustomListBox.ResetContent patch didn't clear the "FSaveItems: TStrings" list if no handle was allocated.

The attached IDEFixPack development snapshot fixes this TCustomListBox IDEFixPack bug. IDEFixPackD103Reg64.7z

That's because the bug is only fixed for the IDE. Your applications don't get the fix from the IDEFixPack.

This assertion is thrown when the debugger's CreateProcess() call to start the application fails. I think it would be better to tell the user what the problem is (RaiseLastOSError) instead of showing the informationless "apiOK" message box. Unfortunately I can't reproduce this bug with the projects I have.

Was this with the 64 bit compiler or the 32 bit compiler?

The JVCL Installer has a checkbox to turn the Global Designtime Editors off. It controls the registry key HKEY_CURRENT_USER\Software\CodeGear\BDS\XXXXX.0\Jedi\JVCL\IDE RegisterGlobalDesignEditors: DWORD = 1

A new development snapshot of IDE Fix Pack for 10.3 Rio is available. The Win64 (DCC64) and Android (DCCAARM) compiler patches should now work as excepted. Changes: Added: Support for Delphi 10.3 Rio Added: Fix for TStringList.IndexOfName bug (RSP-21633) Added: Fix for access violoation in the Welcomepage JScript9.dll binding Added: TCustomListBox.ResetContent is skipped if the handle isn't created yet Added: DFM Streaming optimizations Added: FillChar uses Enhanced REP MOVSB/STOSB cpu feature if available for large sizes. Added: Enabled CPU LOCK string assignment optimization for local variables Added: -Oe (experimental optimizations) and -x-cgo compiler option extension (Remove of some unneccessary push/pop operations) Added: Expression Evaluator allows array access to pointers even if the type wasn't declared with {$POINTERMATH ON} Added: New compiler option extensions: -x--compileonly, -x--reslist, -x--depfile, -x--unitstats Added: More performance optimization for the DCC64 compiler Added: TStringBuilder.SetLength optimization [RSP-19178] Added: TStrings.GetDelimitedText optimization Fixed: Packages with duplicate units may not have caused a fatal compiler error. IDEFixPackD103Reg64.7z fastdccD103vDev.7z

There are still 6 patches collections (about 30 function patches) that I have to reimplement. At least the Win64 compiler doesn't crash anymore. So it will still take a lot of time to get a usable release version.

And they still ship the .jdbg files from the compiler's DEBUG build.

Here is a description of how to debug the IDE.

That means that the library search path registry/EnvOptions.proj were not set by the JCL installer. Could it be that you are you using the "-rOtherRegistryKey" bds.exe command line options, so that the JCL installer adds its paths to the default registry hive instead of you special one?

The call stack you've posted is from the main thread. The more interesting call stack would be the one of the ErrorInsight parser's thread.

There is no IDEFixPack for Rio, yet. There is only the "not_even_alpha" Download with the comment that you shouldn't even come near the Win64 or Android compiler if you install it. That is a work-in-progress version that I uploaded only to help to identify a specific problem.

You can get rid of the failing CreateFile calls by using the attached IDEFixPack development snapshot. But you shouldn't come anywhere near the Win64 or Android compiler if it is installed. Only the Win32 compiler and IDE patches are already working (including the compiler directory cache that eliminates the unnecessary CreateFile calls). You can ignore the error messages during the splash screen that tell you that Win64 and Android patches couldn't be applied. IDEFixPackD103RegDev_not_even_alpha.7z

The code optimizer didn't get a loop unrolling feature. In the compiler's own code there are now some loops unrolled, that IDEFixPack used to replace by SSE instructions. The performance gain is not measurable but the IDEFixPack compiler patches couldn't find the function's memory addresses anymore. for I := 0 to 3 do A[I] := 0; became Zero := 0; // clear one CPU register for all the assignments, instead of clearing the same cpu register for every line. A[0] := Zero; A[1] := Zero; A[2] := Zero; A[3] := Zero;

Unless you use the external compiler, the compiler runs in the main thread and every time it updates the progress dialog it "pauses" the compilation. IDE Fix Pack reduces the slowdown a little bit by only updating the UI after a certain time interval or a filename change, thus not every "compiled lines" update repaints the UI. There are changes in the 64 bit compiler (e.g. some loop unrolling)