Lars Fosdal

What can I say - I like open source where the source is included.

Consider type Use = record public class function When<T>(const aBool: Boolean; const WhenTrue: T; const WhenFalse: T): T; static; inline; end; { Use } class function Use.When<T>(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; begin if aBool then Result := WhenTrue else Result := WhenFalse end; procedure Test(Cond: Boolean); type TObjectClass = class of TObject; var i: Integer; b: Byte; c: Cardinal; w: Word; s: String; d: Double; o: TObjectClass; begin s := Use.When(Cond,'True', 'False'); s := Use.When(Cond, 1, 2).ToString; i := Use.When<Integer>(Cond, 1, -2); b := Use.When<Byte>(Cond, 1, 2); c := Use.When(Cond, 1, 2); w := Use.When(Cond, 1, 2); d := Use.When(Cond, 3.14, 42.0); o := Use<TObjectClass>.When(Cond, TObject, TStringList); end; This is valid code. But i := Use.When<Integer>(Cond, 1, -2); requires the type to be specified. Also w := Use.When(Cond, 1, 128); stops working - actually for any signed or unsigned type - when the second parameter is changed to 128 or higher. It then complains: Why? I though the left hand type would assist in the type inference and hence the parameter validation? Edit: I just noticed that this only happens for Error Insight - not during compilation.

Thank you, @Stefan Glienke - that clears up the fog. It would have been nice, though - if the left side would be able to hint the type.

I guess I was trying to find out which of the constructs that was more readable.

FFS... I need to log off. Scrolling further up in the source code, I found... type Use<T> = record public class function When(const aBool: Boolean; const WhenTrue: T; const WhenFalse: T): T; static; end; { Use<T> } class function Use<T>.When(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; begin if aBool then Result := WhenTrue else Result := WhenFalse end;

Changed the w line to w := Use<Word>.When(Cond, 1, 32000); That works too!

o := Use<TObjectClass>.When(Cond, TObject, TStringList); I did indeed mean o := Use.When<TObjectClass>(Cond, TObject, TStringList); but nevertheless, it compiles. Go figure.

The code compiles without a warning - also for that last line, @Stefan Glienke. In fact, even b := Use.When<Byte>(Cond, 1, 300); compiles. That is a bit weird, I think. Edit: Note to self - make sure you compile the project that contains the file you are fiddling with.

Hence open source effectively stopped being open source.

True, but still not thrilled about the use of the concept of taking something open and making a derivative work semi-closed. Can I make a derivative of sgcWebSockets and publish that as open source with source included?

Open source without the source... not sure what I think about that - particularly when it is based on another open source project.

It has become possible to create completely self-contained .NET apps as well.

That is a significant detail that should have been in your original post, which gives the impression that 64-bit is completely borked as a whole. There are some reports on similar issues when switching platforms in the QP - so it seems that it is not uncommon, but some of the reported issues have been closed with "unable to reproduce". My suggestion would be to try to narrow down the behaviour to a minimal example and submit it to QualityPortal. It can only be fixed if the problem can be reproduced.

Another Q: Do you have third party components/libs without sources and with .dcus compiled with a previous 11.x version?

- check that you don't have stray .dcu files - ensure that all projects build .dcus into different folders for 32-bit and 64-bit - If you have circular unit use, see if you can refactor and apply dependency injection

My advise would be to write a few test apps in .NET before you start your migration. Learn how to do databases, files, classes, interfaces, OS and UI. Understand the new paradigms before you try to csharpify Delphi code, so that you know how things work in C# and what you need to change from Delphi. Sadly, UI is still much more work in .NET compared to all the "freebies" in Delphi - and there are several flavours. WinForms, WPF, MAUI, ASP.NET, Blazor. You need to find the one that suits the needs for your app. You will most likely find yourself wanting to acquire some third party UI controls. For any complex Delphi app, you are not looking at a migration, but a rewrite.

The problem is - the more complex a question, the more complex an answer. As long as ChatGPT is mostly right, most of the time - it is high risk that an answer can be a little wrong or a lot wrong. I will not waste time on solutions that might be partially correct or completely wrong, nor will I spend time on researching the problems other people have with shit they got from ChatGPT. When it gets better, we can discuss it again, but I suspect it would be better use of ML to find flaws or room for improvements in our own code. There is learning in the struggle to understand a new topic. Ready made and wrong answers from an "inventive" "AI" are not good for learning.

If there is an automated system that can eval Delphi libs, I'd like to know it!

Even those with a non-restrictive license?

ChatGPT is still ShitGPT, IMO.

@Fr0sT.Brutall Why has been answered in the thread.

So, my project group with 25 applications, built 7.6M lines of code in 3 min 16 secs without a hitch on my Lenovo P16. I was not surprised, having already tested the builds in my VM during the subscriber beta. But - when I ran the applications against certain production systems - I got an error I had never seen before. After numerous fiddlings with breakpoints, I discovered that the hosts that failed all were ip.ad.dr.es\instance instead of hostname\instance. When googling the error message, I eventually found references to Kerberos security failure and spelunking further, I found a suggestion to add the following to the connection string: In Delphi code, that means adding FDConnection.Params.Values['ODBCAdvanced'] := 'TrustServerCertificate=yes'; to your connection initalization code. Studying the release notes after 11.1, the 11.2 release states which is the one I had installed, but perhaps the Kerberos authentication bit was ignored because the older FireDAC code didn't twiddle the right params? Anyways - problem solved - No more The target principal name is incorrect for ip address host names.

Pfft. Now I discovered that it is already documented at https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Connect_to_Microsoft_SQL_Server_(FireDAC) There is just too much doc to plow 🙂

No, it is related to the use of ip address instead of hostname which creates a trust failure, unless the client automatically approves the server side certificate for establishing a secure connection.

My hard-earned advice Refrain from replicating the database structures in the REST API. Think about the tasks you want to execute, and what data that is needed for these tasks. It doesn't matter how they actually are stored in the database, as it is the REST server's job to sort out what goes where and how. It also enables you to swap out the underlying database without changing the API itself. Use JSON data packages. The good thing about these, is that you can have missing or extra fields in both directions, making the API less fragile. If a value is missing and not critical, simply use a default instead. If an unknown value arrives, just ignore it. This moves the versioning to the API levels, instead of purely on the database. Try https://api.swaggerhub.com for building APIs. Swagger files, now known as OpenAPI definitions, are very useful as there are numerous dev tools that can use them to create both server -and client-side code or configuration. Do not expose primary keys in the APIs - if you need an actual unique key, create a GUID field in the database and use that as the unique id. It is way too easy to do serial breach attempts on queries where the PK is just an integer. Use secure connections - i.e. https. Make sure you use proper authentication. OAuth2 with limited time keys. Remember why it is called RESTful and obey the rules