Wagner Landgraf

I also have a Mac and develop with Delphi in a Parallels VM inside it. I run XData servers in Windows and access them from Mac. There is not much different to do besides network configuration: properly configure your Windows Firewall to accept incoming requests, and making sure the VM is accessible from the Mac with the correct IP. I use Shared Network in Parallels, not bridged, but I also had not a problem when I used bridged. I believe you will have to dig more into your network configuration. Also try to temporarily disable the Windows Firewall to see if you have configured it properly.

Don't forget that you also have managed services for databases. For example, AWS RDS. It automatically handles some manage tasks for you, like installing, upgrading, backup, replication, etc. And still, you have the advantages of DB, which is you still "own it".

Yes.

It's only used to compile the generator executable. Anyone can compile, teste and contribute to code with the trial version. The compiled executable is provided so you don't need TMS BIZ to use it. The generated client code doesn't require TMS BIZ and works in both Delphi (XE8 and up) and Lazarus. About the custom generator, there are events in the code that you can use to intercept and modify the code generation. The OpenAPI parser can also be used separately, of course.

Well, I see now that this is the original request of this topic. 😅 So there you go folks, hope it's useful. It works with Swagger v2 and OpenAPI 3.0.x specifications.

By "translating" are you referring to importing and generating client for it? If yes, I have provided a tool for that: https://github.com/landgraf-dev/openapi-delphi-generator

@Dalija Prasnikar Nice framework and thanks for contribution! When developing, did you check https://github.com/spinettaro/delphi-event-bus and if yes, why it didn't serve your purpose?

The same issue happens with our TMS Sparkle library. It looks like it affected WinHttp API, which is what both Sparkle and Delphi REST library use. I'm afraid this might be even a Microsoft bug, or at least I couldn't find any valuable or updated information that clarifies better what's happening and if and how to properly use the WinHttp library to overcome this issue.

Yes: https://doc.tmssoftware.com/flexcel/vcl/guides/api-developer-guide.html#reading-and-writing-files

We considered that URL to be the "documentation site" for the GraphQL library. It's analog, for example, to https://doc.tmssoftware.com/biz/aurelius (for TMS Aurelius) or https://doc.tmssoftware.com/flexcel/vcl (for TMS Flexcel), which are also separated "sites" from the main TMS site and the official product pages (downloads, orders, etc.). If you pay attention it's the same structure and output, we used the same tool to generate the content for the three of them. The fact the URL is https://graphql-delphi.com instead of something like doc.tmssoftware.com/graphql is simply a matter of trying to comply with the "pattern" of other GraphQL libraries out there, like graphql-java.com, https://graphql-dotnet.github.io or https://graphene-python.org.

@futuron and @Lars Fosdal and everybody else using M1 and Delphi. I'm about to enter this adventure. 🙂 It's been a while since you posted, are you going through the experience without issues? I think I have 3 main questions: 1. Is Windows 11 the best option, I wonder if someone is using Windows 10 with it. I don't get positive reviews about Windows 11 at all. 2. Is Delphi working flawlessly on it? Compiling for all platforms, the IDE, specially debugging...? 3. Side question, but I wonder your opinion on Pro 16GB to Max 32GB just for software development. Is Pro 16GB being enough?

Fair enough, it was more an example to show that relying on the parameter type is sometimes not enough. But as a library writer I don't think it's bad to give a better error message to the user of my classes (whose code I have no control of) telling him what he did wrong, instead of raising a cryptic AV and waiting him to realize what he did wrong or even blame the framework itself.

If the interface is required for your whole class to properly work, why you wouldn't want to check it in the constructor? Why allowing a instance to be created in an "invalid" state? You would have to check if the interface is nil everywhere in your code and for no use, since your class won't work without it.

He was not the only one posting here.

A very common case is when you inject objects and interfaces in the constructor. At the very least you would want to check if they are not nil.

Amen to that.

I see lots of discussions about how to properly structure try..finally statements and how it behaves depending if a constructor raises an exception or not; if the object should be created inside or outside the try..finally, if the destructor should have a try..finally inside it, etc. Maybe indeed it's a different one. This is the one I'm reading: https://en.delphipraxis.net/topic/6149-bestpractices-to-raise-or-not-to-raise-an-exception-in-a-class-constructor

Wow, what a long thread and discussion for something "simple". Use the 25-year old pattern for Delphi memory management: Foo := TFoo.Create; try finally Foo.Free; end; And let the exception raising begin. Anywhere.

Here is mine as well. This thread brought me back in time, this code is from 2003. 🙂 cronos-fft.zip

Just out of curiosity, I wonder if anyone implements interfaces from Exception classes? Like: EMyException = class(Exception, IMyInterface) Of course this would require interfaces would be non-referenced counted, but it would be a way to add arbitrary information to exceptions without having to inherit them from a specific class.

Maybe you can check the source code of the AWS SDK for Delphi, more specifically the AWS Signer unit, and see how it compares to yours and spot any possible difference in algorithm?

It's an interesting approach when you have a centralize exception handler/processor mechanism - like logging systems, serializers, servers, etc.. It's a way to add metadata to the exception without having to be strict to a specific class hierarchy.

That was true for Windows 10, are you sure it will be the same for Windows 11? I believe ARM in Windows 11 will be a 1st class citizen like Intel.

Doesn't Windows 11 already provide ARM support?

That's exactly the reason why none of them will ever be widely adopted. There should be one single manager that applies all the different ideas. It's not impossible.