Rollo62

I would agree, if we talk about 100% compiler managed code. BTW: This warning really only appears with custom CMR, if I replace this by a "normal" Delphi Record, then there is no warning, which I would expect too. Now I can use this warning to find places where custom CMR might cause issues, which would become handy to debug sporadic, unclear issues maybe, where you got no idea where to look at. So I like the warnings and don't think all of them were bogus, at least for the CRM records. Imagine you have an only half-implemented CMR record assignment operator, then you might be pointed to this issue a bit. This could be a perfectly fine, accepted behaviour by design, but good to see these warnings as reminders. Yes, I could make a hint about such special-design decisions in the record itself, but then I wouldn't backtrack the places where it is used so easily. Nevermind, if there is nothing wrong with the code, I will keep it like that. I was looking for a perhaps better implementation, like SmartPointer, Getter, or the like ... returning plain Records as result is maybe never the best idea, only for readability. But the overhead of those other solutions over a simple Record doesn't make it better, IMHO ( and yes, I'm not looking for highest-performance design here, just normal code ).

Thanks, but I think this can still have a true core. From my understanding, this warning tells us, that there is a temporary object, which will be automatically assigned by the custom assignment operator, where the compiler cannot really check the assignment, because its "custom". So in my opinion this warning maybe has some good reasons behind and could be helpful. It would be great if I could take control with the [Result: unsafe] attribute, by telling the compiler: "Nevermind, I know how to handle this case, just keep silent about it." Since I only look into this from time to time, I keep it like that, but maybe for some hard debug sessions this might be useful to switch it on and find some good hints to look into. I'm still in a 50:50 position here.

Perhaps you don't have activated them in the project I try from time to time to cleanup all warnings, but with these "unsafe" checked I've got a huge list with myriads of warnings. Thats why I try to find a better design, how to remove them. Since I usually see warnings same as errors, I try to remove them all, but with these settings nearly every unit ( System units too ) produce massive warnings. All in all they were maybe not so critical, or came from a different ARC-era, but still they point towards some possible flaws in code. I think its always worth to try to find better solutions.

What I have found is that aside the usual [unsafe] there is a specific [Result: unsafe] attribute, which can be used before member functions, where I have assumed that this might suppress the warnings. https://docwiki.embarcadero.com/Libraries/Seattle/en/System.UnsafeAttributehttps://docwiki.embarcadero.com/Libraries/Seattle/en/System.UnsafeAttribute This should be applicable to functions as well, but it doesn't suppress these unsafe typecase warnings But it also says: There is also the unsafe method modifier, or maybe unsafe keyword how Marco called it, which can be added behind a function. This does more than just compiler magic, but it seems to modify reference counting. So this is not what I'm looking for, but mybe with Recors it does this job? Is the [Result: unsafe] attribute maybe a leftover from the mobile ARC stuff and nowadays has no meaning? I'm unsure what this really should do, except suppress warnings. There was an old whiteparer "The Delphi Language for Mobile Development" from 2013, which seems not available any more. What I'm looking for is a selective way to suppress the warnings a Record level, to tell the compiler that I take the responsibility.

If you start by 0, I would also say no, this should not be underestimated, If your question goes in the direction of an existing ERP bringing to web technology, I would say yes. Otherwise C#, PHP/Laravel or even Python will close that gap nowadays. Even large ERP systems were developed with web-technologies much faster and much more capable than desktop, before we even can start an *.EXE file This is just my opinion, perhaps there were different opinions or experiences too.

Thanks for these enlightments. If Spring4D already optimizes to 14ms, how did you get the only 2nd best results at 22ms? Is there any configuration setting needed, to switch on or off the Hash-Algorithm, how to use Spring4D in the right way with Integers?

I'm unsure what advantages to expect from this Are'nt these just several independent server layers between the client and the LLMs, to unify the LLM communications? Currently they talk only about Claude, it seems very Claude centric to me. Do these MCP servers have any REST API or whatsoever, maybe I have overseen this? For the use of agents, wouldn't it make more or same sense to have these features built in the client SDK ( Delphi Code ) in the first place? Then your app would have local, full control over all LLM's and DB's. Yes, a server solution might have some advantages too, but they are not good pointing them out very precisely. I would start with unifying access to different LLMs by implementing a general Delphi Interface for several LLM implementations, to have a compatible interface between several LLM ( if that will be really possible ). Perhaps I completely misunderstood the deeper idea behind this additional layer of complexity, then please let me know.

RegEx?

That would mean, that this tool "compiles" the code and is able to calculate the contents of the variable "foo". This can be from millions of different complex calculations and sources and even user input. I doubt that such tool will exists, but perhaps a Pascal parser together with a Pascal scripter may be able to simulate the codeflow and catch this. Maybe its easier, if you replace/mock the Format() and try to catch or log this error before it is raised.

As far as I know supports MacOS only advisory locks. https://developer.apple.com/forums/thread/709905

Have you also added the featured file "Sqlite driver" in the deployment? https://youtu.be/--HfSCnp24o?t=163

Is that always guaranteed? I would think that the compiler may decide to copy by value for small records.

Hi there, via WholeTomato https://www.wholetomato.com/blog/2024/11/14/how-to-query-file-attributes-50x-faster-on-windows/?utm_source=Eloqua&utm_medium=email&utm_content=Article-250314-WT-50xfaster

Would you please explain a little, how the 64Bit IDE is integrated into the existing system? I understood that both have two separate registry entries, which would make sense, but what about the installation files & binaries? a.) are all these files land in completely separate, external installation folders, outside the normal "Embarcadero/Studio/23.0/bin" folder with all different libraries and *.dll, or b.) is this just another internal folder or *.exe aside the normal "Embarcadero/Studio/23.0/" or "Embarcadero/Studio/23.0/bin" folder a.) would mean that more or less double the size or installation, all files 32-/64-Bit, even if they maybe same. b.) would mean that most libraries, dlls, etc. are maybe shared and the new 64BitIDE is more or less a new *.exe, which is using that. Would be great to know how much the degree of re-use for the new 64BitIDE files there is, Is this doubling the size, or only a fraction? I cannot find any information from Embarcadero to this.

Thats what I think too, but have you tested it already for cross-platform, without issues? Better I wait a day or two.

Oh my, I'm still on Delphi 12.11 and wanted to upgrade to 12.2. My 12.11 was (is) very stable, so I hesitated with the move. Now I have to jump to 12.3 immediately and skip 12.2, will Delphi 12.3 be as stable as 12.2, I doubt it. Shall I update to 12.2 or better directly to 12.3 then? I hope to get some early responses here on stability for Android, iOS, before I decide this.

Hi there, I'm wondering if there have been any changes to the Now() function recently, related to the timer resolution. The Now() returnd TDateTime with Millisecond resolution, while officially they state the resolution is only 1 Sec. https://docwiki.embarcadero.com/Libraries/Athens/en/System.SysUtils.Now Note: Although TDateTime values can represent milliseconds, Now is accurate only to the nearest second. This topic is quite old, so already here discussed on SO https://stackoverflow.com/questions/14573617/how-accurate-is-delphis-now-timestamp With GetTimerTick() I can reach 7-16ms timer resolution, basically. !! And before somebody recommends high performance: I'm perfectly fine with the 15ms resolution and I want to use it. With Now() I can see similar results on all platforms, according to my tests, which is much better than the 1 Sec. stated in the docs, pretty much like the 7-16ms resolution. So what does the 1 Sec. really mean then, is this the worst-case scenario that might happen, while its perfectly 15ms all day long? Perhaps there have been changed something recently, in Delphi or Windows or other Platforms? Windows: System.SysUtils.Now(): is based on GetLocalTime(SystemTime); https://learn.microsoft.com/de-de/windows/win32/api/sysinfoapi/nf-sysinfoapi-getlocaltime https://learn.microsoft.com/de-de/windows/win32/api/minwinbase/ns-minwinbase-systemtime - I cannot find any restrictions like 1 Sec. there, not even a 15ms note. TThread.GetTickCount64: is based in GetTickCount64; https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64 - Which also had no restrictions, aside the known 15ms resolution. Macos/iOS: mach_absolute_time Android/Linux: clock_gettime(CLOCK_MONOTONIC, @res); Other Platforms were way beyond these accuracy - All should reach 1ms without problem. From the behaviour I can see in my tests, I would assume that Now() reaches the same 15ms resolution meanwhile on my current Win11 PC. Is this a safe assumpttion, or are there any other known restriction, which officially state the 1 Sec. resolution? This is why I think the following - Now() and GetTickCount64 both reach about 15ms resolution - Perhaps Now() could show resolution 1 Sec. in rare cases, e.g. under heavy load. - If that is true, I would also expect that also GetTickCount64() might break down to 1 Sec. resolution, under heavy load. Maybe somebody can clarify the situation, under current Windows versions, are there any official statements, aside from Embarcadero's docs? If there were such insights for the other platforms, I'm happy to see them too, but only Windows seems to be worst here.

Thanks, that very helpful. It is what I expected, of course the all should be derived from a deeper hardware clock, with the same resolution. But this is just my assumption, Raymonds article leads to this conclusion too: - GetTickCount64 is based it's same name Windows kernel function, and - Now() is based on Windows GetLocalTime() function. which all belongs to that same group and leads to the same timer resolution of 10 to 55ms ( I believe that is more realistic, but I will stay with 15ms the average ). My quick measurements here show tolerances of approx. 1S = 7-8ms, where within 3S = 21-24 ms I should stay within 95% for all time resolution outliers. But its just a rough test on a virtual machine and no scientific result, but it shows that the resolution shall be far below 1 Sec. With a upper/lower limit of 3S I could catch only very few outliers, and within 4S it showed no more outliers at all. Because of that I would safely assume that a tolerance of 4S = 28-32ms is a realistic worst-case scenario for my virtual machine, which matches to Raymonds note. All in all, that is what I expected and good to know that there is at least an official statement from Microsoft too. It may be possible that Windows system timer functions gets massively blocked by various extra loads, which may then have a good reason. I don't expect any realtime accuracy from those kind of timers in that group anyway. Perhaps the 1 Sec. Note from Embarcadero ist just stupid a "Warning", that the Now() Function is not intended for any precise measurements, although it do support ms resolution. Yes, time is relative ... good that you remind me that. Thats why I can perfectly live with 15ms timers too, in about 99.9% of uncritical cases Regarding TStopwatch.Timestamp(), this is based on the following system functions, whereas I want to avoid the macOS "mach_absolute_time()" function for obvious reasons https://en.delphipraxis.net/topic/13126-apple-gettimertick64-mach_absolute_time-how-to-handle-the-nsprivacyaccessedapitype-privacy/?tab=comments#comment-102072 class function TStopwatch.GetTimeStamp: Int64; //## MSWINDOWS: if FIsHighResolution then QueryPerformanceCounter(Result) else Result := GetTickCount * Int64(TTimeSpan.TicksPerMillisecond); //## MACOS: Result := Int64(AbsoluteToNanoseconds( mach_absolute_time ) div 100); //## POSIX: clock_gettime(CLOCK_MONOTONIC, @res); TStopwatch relies also on GetTickCount as fallback, instead of GetTickCount64, which I hope is only a relict of older Windows versions and would not be seen on any modern ( 10yr ) PC anyway.

Hi there, I was looking into the GetTimerTick64 function and see that under Apple products, the mach_absolute_time function is used, to get a precide timer. Unfortunately Apple requires privacy declarations of mach_absolute_time: mach_absolute_time NSPrivacyAPITypes NSPrivacyAccessedAPICategorySystemBootTime For the usual usage of GetTimerTick64(), I would say the 35F9.1 would be most relevant. I would say this is used in any apps using some kind of internal timing or timerticks behaviour, that will fall under these requirements. Regarding such funktion, I think they can easily automatically test for this, if your app uses the function, or not, so it should already give a warning in an automated test from Apple Review. I do not use the absolute boot time, which they claim to be dangerous, but only derived timer ticks informations, which fall under the exception. My questions are: - Does the exception above mean, that you don't need to give such informations in the manifest? Or do you need to put it there anyway, no matter of exception or not, to declare that you make use of the mach_absolute_time() funtion. - Did Delphi already took care of this somehow ( I cannot see any of such entries in any manifest )? - How do you handle this, does anybody include these markers in the manifest? - Is anybody aware of, that Apple was rejecting an App in the Review, because of this? - If yes, how did you solved this with Apple? Perhaps you could share some logs or noted from their review, how they explain such issue to you. This would be interesting to clarify, before tapping into another Apple booby trap.

Oh yes, I have forgotten about this thread, not considering that this is also related to GetTickCount64() & mach_absolute_time() Thanks, then I know which direction to go.

Thanks, I will look into it. Strange, I have never seen such a Transporter issue yet, but time will come Does it clearly tell you the reason of the rejection?

Thanks for the proposals, but again, I'm not looking for QueryPerformanceCounter, but about the Now(); behaviour. Moreover I'm looking for a cross-platform sulution, not Windows alone. I dont need high performance for this task, the 15ms would be fine. It could be even OK, if 1 Sec., if this happens only very very rare ( but I would like to avoid that ). I hope that someone knows exactly where the 1 Sec. comes from and what conditions will make it to show up.

Like said, I know about performance counters, but I want to use Now() and GetTimerTick64() for other tasks, accepting the 15ms tolerances. The question is about, what the Now() 1 Sec. tolerance really means nowadays, is it gone or is it a valid case?

Hi there, sorry for the little joke in the title, but what currently makes me headaches is the fact that after May will be broken. I used iOS as stable debugging platform for many years now, which seems to breakdown hard in a few days. The alternative Android was never that stable for debugging over the same many years, getting better now, but no replacement. The big problem now is, that Apple seems to enfore the use of their latest tools after 01.05.2024, which would make the use of XCode 14.3.1 for releases impossible. For the possible XCode changes and reasons I figured out the following possible facts for my record. Perhaps they were not all correct, maybe only a few, so please feel free to correct me, if you have more insights into the XCode ecosystem. In general, there seems to be a huge change in the new XCode debugging system. Overview of the changes seen in XCode 15: Topic Old (Xcode 14.3.1) New (Xcode 15) Comments Debugging platform partly still 32-bit using 64-bit only The new debugging platform seems to remove older 32-bit code internally completely. Debugging Framework GDB-based LLDB-based New debugging framework based on LLDB, incompatible with older GDB-based framework. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Debugging Libraries libgcc.dylib, libc++.dylib, New debugging libraries, incompatible with the older libraries used by D12.1. libstdc++.dylib libc++abi.dylib Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Symbolication Manual Automatic Xcode 15 introduces automatic symbolication, incompatible with manual symbolication used by D12.1. Debugging Protocol GDB protocol LLDB protocol New debugging protocol, incompatible with the older GDB protocol used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Breakpoint Handling Software breakpoints Hardware breakpoints Uses hardware breakpoints, incompatible with the software breakpoints used by D12.1. Debug Information STABS debug format DWARF debug format New debug information format, incompatible with the older STABS format used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers I would like to know if this huge XCode change is really upcoming soon, and what can we do about it in the near future? Is there any workaround in sight? I'm afraid, that we have to wait for the next Delphi Update or Patch, which maybe changes a lot of the internals ( libraries, PAServer, workflows, ... ). Are there any news from Embarcadero, about this topic, so that we could see any light in the tunnel? Would be great if there is a way, to make XCode 15 compatible with Delphi, or vice versa. My considerations so far: - Use Android for Debugging, even if it not that stable. Perhaps there are ways to improve Android debugging too. - Forget Mobile debugging, rely only on Logging ( the worst case for me ). - Still use XCode 14.3.1 for debugging, while releasing under XCode 15. This is problematic, because I think XCode 14.3.1 dosen't allow to use iOS 17.4, and perhaps two versions cannot switch easily on the macOS host. Are there any tested workflows, like xcode-select --switch /Applications/Xcode14.app/Contents/Developer and xcode-select --switch /Applications/Xcode15.app/Contents/Developer ? That also means, we would possibly need two sorts of devices with iOS 16.x ( DEBUG + Log ) and iOS 17.4 ( RELEASE + Log ) for proper tests ( Permanent upgrade / downgrade is not an option ). - Embarcadero already had worked out a stable Update 2, to simply make iOS 17.4 debuggable and testable. ( The best case for me ). - Any smart hack, to make XCode 14.3.1 producing releases still? Perhaps, setting a build-ID could do the job, but I'm completely unsure about that. When Apple finds such hacks, this may also be considered as infringement and lead in blocking the app in the store, which could be even harder. - Other ideas / news / thoughs, are there any ? Edit: See above table, it seems that Delphi >= Alexandria can already make use of LLDB debugging system: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers

Thanks, but that was already clear. The problem is, that simulators are not behaving exactly like devices, especially with sensors and hardware stuff, this is why I rarely use them.