Marco Cantu

FYI, the server outage and the JIRA migration were totally unrelated (they happened at the same time, one scheduled the other not). Atlassian has discontinued the self hosted JIRA servers, the only option is going forward it to use the hosted system (or stay on an old not-secure and not-supported version). I don't want to discuss Atlassian offers and pricing, but given the 20 years of JIRA for our team work and bug tracking we decided to stay on it. This wasn't just one instance of JIRA, it was two separate installations with an extremely complex amount of automation and many plugins not supported by the cloud version. The limitations in JSM (Jira customers portal) are significant. We are going some extra mile around them (like sharing reports among customers). There is a lack of voting, but comments can be added. The UI is odd, but searching is not bad. We kept the system as open as possible and are open to additional suggestions, in the realms of what JSM (https://www.atlassian.com/software/jira/service-management) can do (ie, not much). Also, keep in mind that Embarcadero support comes from our support team, not just the bug reporting system. And PMs are always happy to engage in conversations.

We have received reports for this issue already. We don't have a ETA for the solution, but have been looking into it

It's not exactly a glitch, it's how the CE licenses are set up by definition. They last one year. What we did last year and we did again (should be active now, it was completed earlier today) is to allow CE users to apply for a new license key for their existing version.

Let me clarify: Changing the PE format to target newer versions was a design decision. It's the same Visual Studio does. And it does make a difference in the results when invoking some HighDPI related Windows APIs. They FAIL to return the right value if the app is for XP, so if you change the PE setting (doable) you'll ahve some trouble on the latest systems The introduction of an XP braking issue with GetTickCount64 was not intentional and discussed (while of course GetTickCount64 was a requested feature, and it's called by other libraries) . We don't test on XP by design, no one in the beta did, most likley. While we don't officially support XP, such a simple change is doable -- as long there is zero impact on newer systems and it costs a limited time. I doubt we'll release a patch for it, though...

Just FYI, I've updated my component for 10.4.2: https://blog.marcocantu.com/blog/2021-august-delphi-objectdebugger-updated.html Contributions are welcome... there is ample room for improvements

Yes, I dwell here from time to time. I'll have a look, I know there are other tools doing the same but I'll update mine, should not be a big deal... time permitting.

That's a hard question to solve without extra information, please feel free to reach me over email...

Announcing the Availability of RAD Studio 10.4.2 Sydney Release 2 https://blogs.embarcadero.com/announcing-the-availability-of-rad-studio-10-4-2-sydney-release-2/

A new patch for Delphi 10.4.1 is available, addressing iOS 14 and macOS Big Sur issues. Download via GetIt or the new customers porta. For more information see https://blogs.embarcadero.com/apple-platforms-patch-for-rad-studio-10-4-1/

The issue with "Delphi support for the latest iOS Simulator" is that the iOS simulator technology is undergoing a complete change. In the past, on Intel Macs you had to build an Intel App the simulator could run. The new ARM Mac would require a different binary target -- so in effect a different compiler. Well, it might not require a new compiler, given the binary is the same that iOS runs... but I think you get the point. If we ere to build an Intel simulator (64 bit) in a little time that would be totally useless... So we rather skip it and jump on the ARM future sooner. I know

Available at https://blogs.embarcadero.com/rad-studio-roadmap-november-2020/ Also, PM commentary at https://blogs.embarcadero.com/rad-studio-november-2020-roadmap-pm-commentary/

Do you have any actual numbers (compilation time improvement) for any of these. We are gathering some from different developers, and at this point the top one is UnitFindByAlias. Now workaround is stop using unit aliases, but it is our top issue to fix in the compiler. We also have another not in the fix pack that we are rolling out early in a patch, affecting unit cache for large projects and causing compiler time to grow (dramatically!) over successive builds If any other the fixes above (or any not listed) has a very significant effect, we can prioritize it. We are focused on reducing and eventually removing the need of the fix pack, but it takes time as some of the fixes are fairly direct (and many have been implemented in the past) while others require significant rework and spawn threads to do some of the work -- something valuable but requiring extensive testing

Looking into it. I have the impression the original design assumes a UCS4String to have a null terminator. s:= [98,101,114,109,228,223,105,103,0]; // "übermäßig" Not only If you add 0 to the array everything works, but if you call UnicodeStringToUCS4String this is exactly what you get (an array plus the #0) s:= UnicodeStringToUCS4String('übermäßig'); //[98,101,114,109,228,223,105,103,0]; // "übermäßig" ShowMessage (length(s).ToString); Honestly, I don't see us putting a lot of effort in UCS4String

I'm curious are you deploying any additional Java code beside that in core FireMonkey? I wonder what is triggering Google alert...

(and sorry if I don't follow up, I'm out a few days)