Lars Fosdal

@Glenn Dufke stated although that only indicates that to create Ventura compliant apps, you need 11.3.

VNC is another option for remoting - or install Windows for ARM under Parallells on the MAC and run it all on the Mac. It certainly is fast enough with enough RAM and SSD space.

BTW - when searching in files, use "in directories" and check "Include subdirectories" and point to the topmost folder that contains your source code. "In projects" does not necessarily include all units, since you can reference a unit without adding it to the project.

I am not sure which version of Delphi you are using, @GP_23 (You can set that in your profile), but the following has been working at least since Sydney: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Custom_Title_Bar_for_VCL_Forms Edit: ... and I fell into the trap of not reading the OP properly. Surely there must be a way to get the main menu and custom title bar working?

A question of definition, I suppose. Without the Mac, you'll not have a binary that can be sideloaded?

Compiling / Building does need a Mac, since it uses XCode for the final steps.

Any text editor can be used to edit .pas files. It is when configuring projects and editing frames/forms that you are stuck with using the Delphi IDE. CoPilot supported editors are listed here: https://docs.github.com/en/copilot/getting-started-with-github-copilot VS Code works with DelphiLSP and CoPilot - so that is a clear candidate.

Why? In my experience, coming together periodically has been invaluable - particularily in the phase where design requirements and decisions have been on the table. Whiteboard + access to actual production premises and people has been crucial. No text description can convey the same knowledge as being able to observe the users/operators in person, doing the tasks your software assists them with. One could argue that should be the job of architects, but for my projects, the developers have also been the architects. Another case is in discovery and learning phases - having frictionless access to people for numerous short discussions, lowers the inclination of the learning curve. Can it be done via Teams/etc? Sure, but - in person is more efficient. As always, the needs depends on the project / team.

Note - I've not tried this with TDate - but in theory it should behave the same?

interface uses REST.JsonReflect, System.RTTI; type TSuppressZeroDateInterceptor = class(TJSONInterceptor) public function StringConverter(Data: TObject; Field: string): string; override; procedure StringReverter(Data: TObject; Field: string; Arg: string); override; end; SuppressZeroDateAttribute = class(JsonReflectAttribute) public constructor Create; end; implementation { TSuppressZeroDateInterceptor } function TSuppressZeroDateInterceptor.StringConverter(Data: TObject; Field: string): string; var ctx: TRTTIContext; date: TDateTime; begin date := ctx.GetType(Data.ClassType).GetField(Field).GetValue(Data).AsType<TDateTime>; if date <= 1.0 then begin result := EmptyStr; end else begin result := DateToISO8601(date, True); end; end; procedure TSuppressZeroDateInterceptor.StringReverter(Data: TObject; Field, Arg: string); var ctx: TRTTIContext; date: TDateTime; begin if Arg.IsEmpty then begin date := 0; end else begin date := ISO8601ToDate(Arg, True); end; ctx.GetType(Data.ClassType).GetField(Field).SetValue(Data, date); end; { SuppressZeroDateAttribute } constructor SuppressZeroDateAttribute.Create; begin inherited Create(ctString, rtString, TSuppressZeroDateInterceptor); end; A trick I learned from @Uwe Raabe : Add the above code somewhere. In your class that emits Json, add the SuppressZeroDate attribute before the Field of the property. TMyClass = class private [SuppressZeroDate] FDate: TDateTime public property Date: TDateTime read FDate write FDate; end;

FMX or VCL?

As do most of us, but the uncomfortable truth is that work mobility has changed a lot. The younger generations seem to thrive on switching job far more often than the older, who appear to enjoy staying in the same place. And, finding Delphi developers is very hard, as it seems they tend to stay? On relocation - I agree that a lot of work can be done remotely, but even distributed teams do need to get together periodically.

More or less what you write - but as mentioned - the smaller the sample base, the lower the chance of actual working code.

Sounds nice, create request to QC? 🙂 I would, except compiler magic is not a popular subject these days. Also, the corner cases for very short arrays would make it a lot of code for very little gain.

@David Schwartz There is no such thing as 100% perfection. Did you actually read the article - or did you just quote the wrong link? There is nothing about AI being error prone, AI mistakes, or AI immaturity in that article in the quoted link. It is about AI that is proven to work well for code. On another note: I also hear that Co-Pilot X is quite a bit better than the initial Co-pilot. Also - this discussion appear to have two legs - generative AI on the path to general AI (where I disagree) - generative AI applied to code (where I see some benefits, but a lot of pitfalls - particularly for languages with a small sample base) I don't like mundane code or scaffolding either, so I write generic frameworks to minimize that sort of code.

This topic is drifting, so I'll cut and run here 😉

It is nice to have the ability to embellish with color and font size, but I agree - it sucks when people abuse that ability.

There is a lot of strange code in that helper. Have a look at function IsEmpty, which compares the string to a record local const Empty - when the unit already has a global constant EmptyStr. Go figure.

It could have had a parameterless overload that could be used for the instance. if string.IsNullOrWhiteSpace(s) then Writeln('Yup'); if s.IsNullOrWhiteSpace then Writeln('Yup'); As it is now, only the first construct is supported.

Also, on the term "AI": Uncovered in https://www.bloomberg.com/opinion/articles/2023-03-26/even-with-chat-gpt-4-there-s-no-such-thing-as-artificial-intelligence

Like the latter, yes. Then there is the question of codepage. What if we combine Unicode characters that are not available in the same codepage in the same set of ansi characters? I guess that will fail. AnsiString has codepage declaration support - but AnsiChar does not. Relevant read: Marco's Tech Paper https://www.embarcadero.com/images/dm/technical-papers/delphi-and-unicode-marco-cantu.pdf True - but look at InOpArray. Technically it would be possible to have a in operator that checks if a value exists in an array that would be syntactically identical to value in set. Whether it would be efficient or not with even more compiler magic is questionable.

/on-topic This is application of "AI" in ways that I can like https://visualstudiomagazine.com/articles/2023/03/23/vs-ai.aspx

Interesting. Did they have other plans once upon a time? This means it would be safer with if/then/else structures when testing for Unicode chars. or use var ch: char; begin ch := '€'; if System.WideStrUtils.InOpArray(ch, ['æ', 'ø', '€']) then DebugOut('Yup'); but that is just a sequenctial scan of a widechar array.

/off-topic Me: I need help defusing a bomb AI: What kind of bomb Me: posts a series of photos of the bomb AI: Cut the red wire ... *BOOM* AI: ... after cutting the green wire

The input char is mapped correctly. For keyboards with national keys (f.x. äöæøå etc in Nordic), it at least works correctly. Not sure how it translates source code to AnsiChar, considering that source code can be UTF-8. procedure TestChar; var ch: char; begin ch := '€'; if ch in ['æ', 'ø', '€'] // gives [dcc32 Warning] : W1050 WideChar reduced to byte char in set expressions. Consider using 'CharInSet' function in 'SysUtils' unit. then DebugOut('Yup'); end;