Navid Madani

The Parnassus plugins are still maintained by David Millington, who probably has his hands full with C++ Builder's Clang adoption. I don't think many existing C++ projects will be transitioned to C++ Builder, if not only for cost and C++ Builder's maintenance history. Meanwhile, the global C++ to Rust transition gaining momentum is a different story.

I, too, noticed that my IDE is significantly faster and more responsive without the Parnassus plugins. I have not had any crashes after a fresh install with the avoidance of all Parnassus plugins. Meanwhile, MMX has always been as solid as possible - thanks to Uwe Raabe.

I cannot tell what your code is doing for sure. However, your question is also general about how to tackle asynchronous programming in Object Pascal. You are calling procedures in your class that do not return any values, where a more functional approach might be better suited for your needs. Assuming the consumer is in the main thread that you do not want to lock, you have a couple of options: You could use a TThread descendent class and set its OnTerminate even to a TNotifyEvent in your main thread (i.e., a method with the procedure(Sender: TObject) signature) that will receive the TThread descendent before its destruction and allow you to extract the necessary data. Alternatively, you could use an IFuture<T> (System.Threading) and query its value when you are ready, but this can be a blocking call if your future result is not yet available.

Just an update: I went the long way: after a fresh installation of Windows ARM via Parallels, RAD Studio 12.1, and MMX Code Explorer (and avoided all Parnassus plugins), it looks like a fix. The IDE is faster, and no longer sluggish. Thanks again to everyone for your suggestions.

Thank you to every one. I changed the emulation settings to strict execution: I think it did cause some improvement. I had already checked all paths and they were good. I also have no networked drives in any of the library paths, which can cause problems. I do not not believe that those Parnassus terms still apply. The new terms are Embarcadero's and can be found at https://getitnow.embarcadero.com/Navigator-12-1.6.5.2/ I am so used to Navigator's ctrl-G for jumping around the code ... what do you use? As mentioned, I uninstalled all plugins and still had a freeze. But I can't disagree that the freeze might be due to network activity. Thank you all again!

Thanks. My main concern is the IDE freezing. The 'Problem Reports' Control Panel does not include the freezes, and I could not find any entries in Windows 'Event Viewer' either. Does anyone have any thoughts as to how I could investigate further?

Is anyone else experiencing frequent (~ hourly), random IDE freezes, and unresponsiveness on Windows ARM, even with small and new projects? Task Manager shows 0% CPU activity. The only recourse has been to force-quit the IDE using the Windows Task Manager and restart. A lot of productivity has been lost as a result. I have installed Navigator, Bookmarks, TwineCompile, Bonus KSVC, Radiant Shapes, and MMX Code Explorer. Oddly, GetIt claims that the "12.1 Patch 1 1.0" previously applied is not installed, and clicking "Install" does nothing. I have already tried removing the IDE plugins without resolution. And just to add a rant, this is now my second uninstall/reinstall cycle of 12, which is enough for me. What is the best way to investigate (log files, etc.)? Thanks in advance.

RAD Studio 11.3 (2024 build) was posted on my.embarcadero.com on 2/20/2024. Does anyone have further details about this re-release? Thanks in advance.

Looking at Swift 5.9 release notes, there is talk of bidirectional C++ interoperability. Has anyone tried it? https://www.swift.org/documentation/cxx-interop/

TDirectory.GetFiles in System.IOUtils has a bug on macOS: In the returned dynamic string array, valid files with names that contain three or four consecutive periods are not included. I ended up having to use macOS system functions instead. If it would help others who could run into this problem, my solution is below. Please post if you find any errors. macOS programming is certainly not my forte. unit Nm.IOUtils; interface uses System.SysUtils , System.Types {$IFDEF MACOS} , Macapi.ObjectiveC , Macapi.CocoaTypes , Macapi.Foundation , Macapi.Helpers {$ENDIF} ; {$IFDEF MACOS} type EItemType = (itFiles, itDirectories); EItemTypes = set of EItemType; function macOS_GetDirectoryContents(const DirectoryPath: string; const ItemTypes: EItemTypes): TStringDynArray; {$ENDIF} implementation {$IFDEF MACOS} function macOS_GetDirectoryContents(const DirectoryPath: string; const ItemTypes: EItemTypes): TStringDynArray; const ARRAYSIZEINCREMENT = 32; var FileManager: NSFileManager; URL, FileURL: NSURL; FileEnum: NSDirectoryEnumerator; Options: NSDirectoryEnumerationOptions; Error: NSError; IsDirectoryVal: Pointer; IsDirectory: Boolean; Candidate: string; i: Integer; ArraySize: Integer; begin FileManager := TNSFileManager.Wrap(TNSFileManager.OCClass.defaultManager); URL := TNSURL.Wrap(TNSURL.OCClass.fileURLWithPath(StrToNSStr(DirectoryPath), True)); Options := NSDirectoryEnumerationSkipsSubdirectoryDescendants; FileEnum := FileManager.enumeratorAtURL(URL, nil, Options, nil); FileURL := TNSURL.Wrap(FileEnum.nextObject); ArraySize := ARRAYSIZEINCREMENT; SetLength(Result, ArraySize); i := 0; while Assigned(FileURL) and FileURL.isFileURL do begin IsDirectoryVal := nil; if FileURL.getResourceValue(@IsDirectoryVal, StrToNSStr('NSURLIsDirectoryKey'), @Error) and Assigned(IsDirectoryVal) then begin if i >= ArraySize then begin Inc(ArraySize, ARRAYSIZEINCREMENT); SetLength(Result, ArraySize); end; Candidate := UTF8ToString(FileURL.path.UTF8String); IsDirectory := TNSNumber.Wrap(IsDirectoryVal).boolValue; if IsDirectory then begin if (itDirectories in ItemTypes) then begin Result[i] := Candidate; Inc(i); end; end else begin if (itFiles in ItemTypes) then begin Result[i] := Candidate; Inc(i); end; end; end; FileURL := TNSURL.Wrap(FileEnum.nextObject); end; SetLength(Result, i); end; {$ENDIF} end.

https://quality.embarcadero.com/browse/RSP-26436 Such a fundamental pattern being broken, it could be a sign of more ominous problems.

I have encountered a strange problem: Delphi Athens is running via Parallels on Apple Silicone. In the following demo, none of the destroyers are called when targeting macOS ARM 64, while everything works OK targeting Windows). Also, I can get the Windows target to report the memory leak when I comment out fDebug.Free in FormDestroy, but not with macOS ARM 64. Can anyone else reproduce this? Am I missing something? Thanks! unit Unit1; interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs; type TForm1 = class(TForm) procedure FormDestroy(Sender: TObject); procedure FormCreate(Sender: TObject); private fDebug: TObject; public destructor Destroy; override; end; var Form1: TForm1; implementation {$R *.fmx} // TForm1.FormDestroy is not called when Target is macOS ARM 64-bit procedure TForm1.FormDestroy(Sender: TObject); begin ShowMessage('FormDestroy Called'); fDebug.Free; end; // TForm1.Destroy is not called when Target is macOS ARM 64-bit destructor TForm1.Destroy; begin ShowMessage('Destroy Called'); inherited; end; procedure TForm1.FormCreate(Sender: TObject); begin fDebug := TObject.Create; end; end.

Retracted.

Duh! Thank you! I should have tested adding other characters on the tests. When the REST API added the hyphens, that's when everything broke down ...

Thanks, David. No, I don't shun any value types, but we're talking about large record sets, too large for the stack. I was referring to bugs that creep in when the integrity of (mutable) data on the heap is not guaranteed, when variables are mutable. Certainly, records can emulate data integrity patterns with private fields, but that approach is not front and center with Delphi records. Interfaces too can cause memory leaks, and be complicated when weak references are needed. But again, it's an overall safer pattern in Delphi, at least in my experience. Interfaces also help write testable and more easily maintainable code by keeping things decoupled. And yes, try-finally blocks are written by the compiler, but compilers ultimately write machine code. That's the whole purpose of using a high-level language: so we don't have to write all that code. It helps keep things readable. I agree that it's the same basics with memory allocation and release patterns. But again, different languages implement them in different ways, and some patterns are more idiomatic for a specific language, as in this case. I think our discourse is more over language semantics than technical. While I understand and appreciate your points, I am not convinced to change my approach to large amounts of data on the heap.