Lars Fosdal

Optimism is underappreciated. 🖖

No feature freeze until Delphi Antarctica

Do you have the http.request.connection set to 'keep-alive'? I've seen posts that indicate that it will prevent dropping the port. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive - There are options to limit the life time / number of uses. Is the TIdHttp properly disposed of? Did you try something like TCPView (https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview) to find out what holds the endpoints?

I am really looking forward to nullable base types. Variants sort of work, but you have to write a lot of checking code that could be made less complex with nullables + operators + validation. Some food for thought here: https://developers.redhat.com/blog/2020/03/05/c-8-nullable-reference-types/

I wish there was a way to have the Json engine recognize the T in TObjectList<T> from the RTTI. That would have saved us a ton of scaffolding code.

https://strøm.no/ i.e. https://xn--strm-ira.no/

Nice, Uwe! I missed your reply from Friday! Going to test it out. Is it possible to inject this at the root of a class hierarchy, or is it necessary to inject the attribute per objectlist reference in the descending classes?

If you have Azure AD, using PowerShell and storing credentials in Azure Vault is a good alternative to passing credentials on the command line.

There is input in the shape of attributes. I was just disappointed that they didn't go the whole nine yards with TObjectList<T> support in addition to TArray<T>.

What about that renamed Delphi thing? Can't even remember it's name now - App...something.

I didn't read that as a conclusion, but as defining a goal for testing. More diverse testing = better testing. Naturally, the quality of the bug reports is important. Good description of context: OS, platform, libs, etc Good description of symptom / problem Proper steps to reproduce

IDN is pretty common in Norway, due to our beloved æ ø and å characters.

I guess it to a certain degree reduces rumors and opinions on thin foundations - but, yeah... it is an antiquated approach for a public beta.

Note that even if every update subscriber gets access to the beta, they are still under NDA and may not discuss testing 10.4 Denali in public.

For me, using JSON is a must. The same single JsonRPC server serves Google Glass Java applets, Python clients in VoCollect A500 hip computers, Delphi FireMonkey touch applications under Windows 10, and various APIs to PLCs and third-party autonomous robots from Toshiba, Elettric80 and others. If I can find a viable alternative that allows me to replace the TArray<T>'s with TObjectList<T>, I'll be happy to have a look at it for robustness and speed, but the current solution handles a very large number of transactions daily, and the serializing and deserializing is not something that raises issues.

@Uwe Raabe Both ways. I implemented a generic JsonRPC server and client using this method of JSON serializing/deserializing. The protocol endpoint handler code does not see the raw JSON all, only objects.

Suggestions on how would be appreciated. Apart from the generic list thing - this works so well.

I'd like to do that - but when creating Json with the TJson helpers, the TList<T> creates an unwanted effect. TArray<T>: {"int":0,"list":[{"str":"A"},{"str":"B"},{"str":"C"}]} TObjectList<T>: {"int":0,"list":{"ownsObjects":true,"listHelper":[{"str":"A"},{"str":"B"},{"str":"C"}]}} Ideally, I'd like to use TObjectList<T> - but have the Json look like what a TArray produces. program TArrayVSTList; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes, Generics.Defaults, Generics.Collections, Rest.Json; type TObj = class(TObject) private FStr: String; public property Str: String read FStr write FStr; constructor Create(const s: String); virtual; end; TListTest<T:TObj> = class(TObject) type TCont = class(TObjectList<T>); private FInt: Integer; FList: TCont; public property Int: Integer read FInt write FInt; property List: TCont read FList write FList; procedure Add(const s: String); constructor Create; virtual; destructor Destroy; override; end; TArrayTest<T:TObj> = class(TObject) type TContA = TArray<T>; private FInt: Integer; FList: TContA; public property Int: Integer read FInt write FInt; property List: TContA read FList write FList; procedure Add(const s: String); constructor Create; virtual; destructor Destroy; override; end; { TObj } constructor TObj.Create(const s: string); begin str := s; end; { TListTest<T> } procedure TListTest<T>.Add(const s: String); begin FList.Add(TObj.Create(s)); end; constructor TListTest<T>.Create; begin FList := TCont.Create; end; destructor TListTest<T>.Destroy; begin FList.Free; inherited; end; { TArrayTest<T> } procedure TArrayTest<T>.Add(const s: String); begin var len := Length(FList); SetLength(FList, len + 1); FList[len] := T.Create(s); end; constructor TArrayTest<T>.Create; begin // Nothing needs to happen here end; destructor TArrayTest<T>.Destroy; begin for var Element:T in List do Element.Free; SetLength(FList, 0); inherited; end; procedure TestJson; begin var Arr := TArrayTest<TObj>.Create; Arr.Add('A'); Arr.Add('B'); Arr.Add('C'); Writeln(TJson.ObjectToJsonString(Arr, [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601])); var List := TListTest<TObj>.Create; List.Add('A'); List.Add('B'); List.Add('C'); Writeln(TJson.ObjectToJsonString(List, [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601])); end; begin try try TestJson except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; finally Write('Press Enter: '); Readln; end; end.

Once. That was enough.

Every bloody time I've tried to use the 64-bit debugger, breakpoints stopped working, evals were wrong, stepping stopped working, so in the end, I simply decided it was too soon. I really hope they get it right eventually.

Which is why I started with

By keeping current, you will deal with changes, one version at a time. After the D5->XE2 experience, I very much prefer that option. @Fr0sT.Brutal mentioned 64-bit. We didn't even go there yet, as the 64-bit debugger is utter and completely crap.

The worst breaking changes were Ansi -> Unicode. Migrating a million line D5 project to XE2 was something that I would prefer not to attempt again. Since then, there are been mostly type or constant renames, which are trivial in comparison. Other challenges have been the deprecation of BDE and dbExpress. Fortunately, FireDAC turned out quite well. I agree that the transition between the "named" version has been pretty much trivial, but then again - we usually don't migrate until the first Update pack shows up Last night, four of our SQL Servers that still linger on 2008R2 refused to accept schema updates for two specific stored procedures that were using functions only found in 2012 and upwards. The rest of our servers are 2012 and 2016/17. That is a similar risk to your components no longer getting updates for your Delphi version since the component author drew a line in the sand and started using language features or classes that only exist in the newer Delphi versions.

From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current. Of course, that does not necessarily apply for everyone, and I can understand the cost perspective for a one-man shop - but for a corporate developer that is continuously developing internal systems, it is a no-brainer to stay current. You get the fixes, you get the support, and since we do relatively frequent releases, we do the testing anyway. Rio -> 10.4 will mean a lot of work on the FMX side - but on the bright side - you can finally stop having to think about two memory models when you write code for cross-platform. That dual model has actually been a roadblock for cross-platform for us. We did not want to spend time on that duality.

I've never set these up, but isn't that something you would configure on ISS itself, and then refer to from Delphi? Lots of security angles to consider