Rollo62

Interesting, 8GB would feel a little too small for me. Nevertheless, I use a MacMini M2 for such tests running XCode on ARM M2, but I have never tried to install a VM with Delphi on it. I only remote-access the PAServer there, to build ARM M2 binaries, which works very well. Perhaps I'm forced to try the Delphi on MacMini in April, sooner as I loved to. Nevertheless, it would make more sense to run Delphi from a Windows Workstation. But the MacBook is not completely dead directly, it might still be used as Delphi workstation, only using the external MacMini for builds and iOS.

Yes, but I currently run Delphi 13 under Parallels VM, thats why I have 32GB machine to run it smooth. This is what I meant, by changing the whole infrastructure. Do you run Delphi under Parallels VM on the MacMini M1 8GB too and if so, isn't it too slow? My plan would be at least to have 16 GB, but Apples RAM pricing strategy is really ridiculous.

Yes, I wanted to update to the latest Sequoia version, which should be Macos 15.7.1. https://support.apple.com/en-us/120283 So that means it will debug this Macos too, not only iOS 17+, which was the last status I have noted in my files? My understanding ist that the debug issue only affected iOS, not Macos (yet), I hope I'm right. Great, that sounds very promising that its already running. Thats my plan, to move slowly step-by-step, to avoid additional, unwanted issues. Currently I'm a little under fire, because of missing updates, so I don't want to mix up anything. To upgrade until next year April will be fine. First I have to get back some stable ground again, in the Delphi / Apple / Android swamp, to move on safely. Actually I thought that it would last until September 2026 with its Tahoe enforcement, but if you say its only April 2026, then this means I have to re-structure my whole setup hardware here too, with a new Mac machine. The (old) Intel MacBook Pro was a nice piece of hardware, but not worth it, if it lasts only a handful of years as development machine, so my plan for the new year will be to move entirely from MacBook Pro Intel to MacMini M2+x ( and maybe a Windows Workstation instead, if the MacMini doesn't to Parallels VM well ). Apple is always the source for the biggest headaches, just before Android.

Thanks, but that part was clear to me. Whats unclear is, how about debugging under Intel MacBook, MacOS Sequoia 15.6 apps itself? What is the latest, most stable upgrade path for Delphi 13 ( Intel MacBook, MacOS Sequoia 15.6 , XCode 16.4, iOS 18+, ... )? I cannot move to MacOS Tahoe, because that will break my whole Workstation support as well, not only the iPhone part, and I would have to switch to another Mac. But I think MacOS Tahoe is far out of reach for Delphi 13 anyway, I hope they can fix this within one year. My problem now is, that I cannot upload to store anly longer, with my XCode 15.4.

My old iPhone X with max. version iOS 16.7.12 seems to be banned from Apple development now, so it seems I have to purchase a newer development iPhone iOS 17+. When I borrowed an iPhone 14 Pro with iOS 17.6.1and using XCode 15.4 with SDK iPhoneOS 17.5 I can build and run fine with Delphi 13 Patch 1. Only when trying to debug, Delphi 13 P1 shows this ( German message, although IDE is fully english setting ) meaning: "Debugging of the app on devices with iOS 17 or higher is currently not supported." What is new now is, that I cannot build and upload an Release any longer, getting this message from Transporter: So finally I need to install Delphi 13 P1 with the desired XCode version ( XCode 16.4 seems the latest, known supported, from above statements and this additional note from Dave ) https://en.delphipraxis.net/topic/13630-linker-errors-all-of-a-suddenios/?do=findComment&comment=104840 While the latest current version of the 16.x line seems to be XCode 16.4, the next version jumps to XCode 26 https://developer.apple.com/download/applications/ From this thread so far, I would assume that XCode 16.4 line should still work as expected, while the next XCode 26 perhaps breaks even more. By the way, it seems Apples XCode Release notes claims support from iOS 15 still well https://developer.apple.com/documentation/xcode-release-notes/xcode-16_4-release-notes What puzzles me is the strange table from Embarcadero, for the latest Delphi 13 Florence Version which lists only XCode 15 ?? https://docwiki.embarcadero.com/PlatformStatus/en/Main_Page#Development_Tools_Support Is that just a typo, or what does it mean? If that is true, that would mean no upload to AppStore would be possible, right? Because XCode 15.45 would not include support for SDK 18: https://developer.apple.com/documentation/xcode-release-notes/xcode-15_4-release-notes I've tried to stay as long as possible under XCode 15.4, because it was still able to debug iOS, but XCode 15 is quite too old and even XCode 15.4 is not supported any longer. So the best compatible pathway is a little uncleat still. The debug issue with iOS 17+ under XCode 16.x is clear, whats not so clear is, if XCode 16.4 can still debug Macos Apps then with Delphi 13 P1. This would be my last resort emergency fallback, but I assume the next step to XCode 16.x will remove all debug options, is that correct? Would be good to know what breaks and whats not, before upgrading to XCode 16.4, using Delphi 13 P1 and purchasing a new iPhone.

Seems back to normal for me. 👍

That is correct, I also wondered why this was not simply copied to the main Embarcadero/37.0/PAServer/ folder, as it should be the normal way patches shall work, IMHO. I also had to search this for little while.

Ok great, it forces you to change the name in all places, at least nicely supported by compiler and CodeCompletion, thats fair enough. 👍

I cannot find any background information to NameOf(), how it internally really works. It seems to be implemented intrinsic in System.NameOf, but how does it magically retrieves a name at runtime? If this NameOf() call intrinsically also includes the RTTI-System by calling System.TypeInfo or the like, as an unwanted side-effect, that would not be a good thing, IMHO. Perhaps its some other kind of compiler magic, that is going on here. 🤔 Who knows what it really does, under the hood? Edit: Ok, I just checked what it can do and whats not. It really seems to replace only like: typing the text "nameof( Sender );" instead of "Sender"; typing the text "nameof( Self );" instead of "Self"; in the code. My gut feeling was right, yes its useless and even has more text to type. Or do I oversee some hidden useful magic or some really fancy use-cases here? Maybe the use in Attributes would make some sense https://en.delphipraxis.net/topic/1775-i-wish-i-had-rtti-for-constants-andor-a-compiler-magic-nameof/?do=findComment&comment=108278

Still no iOS 17 debugging in Delphi 13, including September Patch. What can be the problem, since other IDE's seems to have solved this issue already one year ago? When I peek a little deeper into this: The root cause seems to be the change from usbmuxd to devicectl, as far as I can see, enforcing the new CoreDevice.framework. // Communications-Stack until iOS 16: ┌─────────────────┐ │ IDE/Tool │ ├─────────────────┤ │ libimobiledevice│ (Open Source) ├─────────────────┤ │ usbmuxd │ (USB Multiplexer Daemon) ├─────────────────┤ │ lockdownd │ (iOS Service) ├─────────────────┤ │ iOS Device │ └─────────────────┘ // Communications-Stack since iOS 17: ┌─────────────────┐ │ IDE/Tool │ ├─────────────────┤ │ devicectl │ (CLI Tool) ├─────────────────┤ │ CoreDevice.fw │ (Closed Source) ├─────────────────┤ │RemoteXPC Service│ (New Protocol) ├─────────────────┤ │ iOS Device │ └─────────────────┘ It seems to change a few permission requirements and the protocol, but it mainly seems to be a doable change on the communication level, IMHO. Maybe I'm wrong and there were deeper changes and showstoppers too. I cannot find much about the CoreDevice.framework, it seems to be still private and not fully public (perhaps still under development). https://marcoeidinger.github.io/appleframeworks/ Is this perhaps the reason that Embarcadero has no sources available yet, to implement a solution??!! I would think that Embarcadero should have all files to provide a solution, but maybe need to wait until Apple officially makes it public. Does it make sense to look after other IDE's, how they solved the issue and learn from them about fixes and workarounds under Delphi 13 too? So far I cannot see a clear, official solution description yet, but others seems to have it.

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

What means "fixed", where is this noted? There are use-cases in views where I want edge-to-edge and where I don't. Is there a kind of switch in Delphi to handle this, perhaps even on-the-fly? Personally I think the right way would be to do this in the manifest file, but this is for the whole application only. Perhaps it would make sense to have options to switch the Form between normal, normal-edge-to-edge, fullscreen, fullscreen-edge-to-edge, without hacking this on my own. Now a solutions could be to insert layouts and elements on the form, in the way you want, showing or don't showing depending on the version. I'm still installing and setup a fresh Delphi 13, if you have infos I can try to test this.

Perhaps this will do it: https://learndelphi.tv/ https://www.amazon.de/-/en/Code-Faster-Delphi-Alister-Christie/dp/B08KH3R42T

Ok, it has kindof strange infos too, like bugfix would be possible somehow. https://docwiki.embarcadero.com/RADStudio/Florence/en/Release_Notes#Launching_iOS_fails_with_PAServer_22 it doesn't say here either very clearly https://docwiki.embarcadero.com/PlatformStatus/en/Main_Page#Supported_Platforms_and_Operating_Systems Perhaps its not clearly noted, that there were any issues. For example at Delphi 12 it clearly stated that its not able to debug on iOS 17 devices, https://docwiki.embarcadero.com/PlatformStatus/en/Main_Page#cite_note-iOS17-2 Strange, why did they removed this note in Delphi 13? Maybe they intend to fix this in an early patch.

Good question, I've tried this "How can I debug iOS with Florence?" As far as I know, debugging iOS ist still broken, which I can find also in the release notes for example If this compainion was trained on the current data, then its a little off here. So I wonderwhat they used for training really, I hope also some insights from Jira or the like.

There are a stunning 5.4% not using AI at all, hooray, brave men and ladies

Oh my God, AI really doesn't have much support in this forum, or at least fair, open treatment. We'd be better off banning the use of the anti-term “AI” with a flashing red warning light, rather than thinking about new forum sections.

I would say it is already much, because there were so many GitHub Delphi AI libraries popping up including the Delphi AI support too, so I think it is a high topic density right now. It would be worth to give them a common home, and keep all their questions focused into them. On the contrary, if no AI forum, what will the best place to ask questions ( Off-Topic, Other stuff, ... )?

Thanks a lot. So you say Option C is working on MacBook M1, or have you tested it also successfully under MacBook x86, because thats still my main system? Maybe I will give it a try.

Hi there, I have see a new not that Parallels 26 is available, but with some not so nice news. It says, translated from German: One of my main functions was to use MacOS as a last resort for debugging iOS BLE devices and their protocols. Because the MacOS and iOS Bluetooth systems are fairly compatible, this has been a 100% error-free option up to now. According to the text above, this now seems to be a thing of the past. An external dongle brings with it a 99% probability of further new errors and problems during debugging, and 1:1 behavior between macOS and iOS may no longer be guaranteed. Because multi-platform debugging under Delphi is currently almost completely unusable anyway, this is my last hope for testing external Bluetooth devices (Android debugging is extremely unreliable, iOS debugging has not been possible for some time, and macOS debugging has still been possible until now). Yes, there is still the option of debugging under Windows with a BLE dongle, but that was also relatively tricky and not really compatible with iOS/Android, etc. It starts with finding a compatible BLE dongle that works with Windows/macOS. Does anyone else have the same concerns as me? Maybe there are already solutions for this, or, at best, everything still works as before under PLS 26? BTW: I'm still working on an Intel MacOS, which maybe also behaves different to the M1, regarding external BLE-Dongles.

Two places, I would say, thats what I noted above regarding its disadvantage. I'm fully aware of its pros and cons, it was just a proof of concept, but it works not that bad, I must say. The main usefulness perhaps comes from its wildcard and RegEx options and its general good readability, IMHO, while its not the most pure string to case solution of course. This was just a fast hack yesterday, combining my thoughts over some years, if this would makes sense or not, just think about that problem a bit deeper. Right, it doesn't replace a real, native string case of, but perhaps it has its place in the world too. True, that why I considered a combination with the enum type too, that should be easy to add and extend to the former enum proposals. All these "case TRttiEnumerationType<TMyStrings>.GetValue(s) of" solutions, I would see more related to enums, than to the original demand of a "case-of" implementation. They need perhaps even more than two pre-definitions and more code distributed over the whole unit, with defining specific enum types. To use kindof fluent interface with anonymous methods would work perfectly too, but thats way too far from the case-of look-and-feel I am thinking of. There are some ideas, but all of them has a lot of pros and cons, hard to find the sweet spot, for a general "case-of" implementation

Interesting, do you have a small sample how you get this running? Its quite a messy protocol https://gpsd.gitlab.io/gpsd/NMEA.html#_talker_ids I wonder, what subset of the data will be available over Android phones, I think the phones will miss out a lot of data, right?

Thanks, that looks good, but I'm unsure if this is only working under Win11. It only tells us Win11 ready, but nothing about MacOS. My setup is on a MacBook (Intel x86), running Parallels Desktop VM with Windows and Delphi, when debugging on the MacOS hardware it was always possible to access the Mac's BT device when running on this. There three scenarios, I would think: A.) MacOS -> PLS -> Win11 -> Delphi -> Debugging on MacOS hardware -> Accessing MacOS BLE shall be possible still ( I hope so ) B.) MacOS -> PLS -> Win11 -> Delphi -> Debugging on Win11 VM -> Accessing original MacOS BLE through PLS -> seems to be gone in the future C.) MacOS -> PLS -> Win11 -> Delphi -> Debugging on Win11 VM -> Accessing BLE dongle via MacOS -> PLS making BLE dongle available in Win11 VM -> You mean this? Does such Asus BLE dongle works for the Mac too, or doesn't it need to work under MacOS as it is handled by Win11 alone? I've tried years ago to find some working dongle and gave up, as it is nearly impossible to get clear answers to the BLE dongle compatibility. At that time, it was only said possible by a specific Allpe-compatible chipset and some hacky driver installation, as far as I remember.

Here the file, belongs to previous post. CaserTest.zip

Here is another update, with registration of group patterns and guard options. Usable like this: procedure TMainFrm.SimpleWhenExample; begin Log_Memo('=== RegEx Pattern Matching Example ==='); var LCaser := TS4Caser_Factory.New( True, -1 ); LCaser .Register( 1, 'aaa' ) .Register( 2, 'bbbb' ) .Register( 3, 'ccc' ) .Register( 4, 'aa' ) ; var LTest := 'ccc'; case LCaser.Match( LTest ) of 1: Log_Memo( 'aaa matched' ); 2: Log_Memo( 'bbb matched' ); 3: Log_Memo( 'ccc matched' ); 4: Log_Memo( 'aa matched' ); else Log_Memo( 'nothing matched to ' + LTest ); end; LTest := 'bbb'; case LCaser.Match( LTest ) of 1: Log_Memo( 'aaa matched' ); 2: Log_Memo( 'bbb matched' ); 3: Log_Memo( 'ccc matched' ); 4: Log_Memo( 'aa matched' ); else Log_Memo( 'nothing matched to ' + LTest ); end; LTest := 'bbbb'; case LCaser.Match( LTest ) of 1: Log_Memo( 'aaa matched' ); 2: Log_Memo( 'bbb matched' ); 3: Log_Memo( 'ccc matched' ); 4: Log_Memo( 'aa matched' ); else Log_Memo( 'nothing matched to ' + LTest ); end; LTest := 'aa'; case LCaser.Match( LTest ) of 1: Log_Memo( 'aaa matched' ); 2: Log_Memo( 'bbb matched' ); 3: Log_Memo( 'ccc matched' ); 4: Log_Memo( 'aa matched' ); else Log_Memo( 'nothing matched to ' + LTest ); end; // // GUARD: Ignore <= 2 char lengths // LCaser .WhenAny( function ( const AValue : string ) : Boolean begin if AValue.Length > 2 then Result := True else Result := False; end ) ; LTest := 'aaa'; case LCaser.Match( LTest ) of 1: Log_Memo( 'aaa matched' ); 2: Log_Memo( 'bbb matched' ); 3: Log_Memo( 'ccc matched' ); 4: Log_Memo( 'aa matched' ); else Log_Memo( 'nothing matched to ' + LTest ); end; LTest := 'aa'; //! This ís guarded ( len <= 2 ) case LCaser.Match( LTest ) of 1: Log_Memo( 'aaa matched' ); 2: Log_Memo( 'bbb matched' ); 3: Log_Memo( 'ccc matched' ); 4: Log_Memo( 'aa matched' ); else Log_Memo( 'nothing matched to ' + LTest ); end; end; // Example 2: OR-Pattern for groups procedure TMainFrm.SimpleOrExample; var Command : string; LCaser : IS4Caser; begin Log_Memo( '=== OR Patterns Example ==='); LCaser := TS4Caser_Factory.New( False, -1 ); // RegisterOr: Mehrere exakte Alternativen für gleichen Index LCaser .RegisterOr( 1, ['start', 'run', 'begin', 'launch', 'execute']) .RegisterOr( 2, ['stop', 'halt', 'end', 'terminate', 'kill', 'abort']) .RegisterOr( 3, ['pause', 'suspend', 'hold', 'freeze']) .RegisterOr( 4, ['resume', 'continue', 'unpause', 'thaw']); // RegisterWildcardOr: Mehrere Wildcard-Pattern LCaser .RegisterWildcardOr(10, ['config_*', 'cfg_*', 'setting_*']) .RegisterWildcardOr(11, ['log_*', 'trace_*', 'debug_*']); Command := 'execute'; case LCaser.Match(Command) of 1: Log_Memo( ' Service startet: ', Command); 2: Log_Memo( ' Service estopped: ', Command); 3: Log_Memo( 'â¸ï¸Service paused: ', Command); 4: Log_Memo( 'â–¶ï¸ Service resumed: ', Command); 10: Log_Memo( 'âš™ï¸Config-Command: ', Command); 11: Log_Memo( ' Logging-Command: ', Command); else Log_Memo('â“ Unknown command: ', Command); end; Command := 'halt'; case LCaser.Match(Command) of 1: Log_Memo( ' Service startet: ', Command); 2: Log_Memo( ' Service estopped: ', Command); 3: Log_Memo( 'â¸ï¸Service paused: ', Command); 4: Log_Memo( 'â–¶ï¸ Service resumed: ', Command); 10: Log_Memo( 'âš™ï¸Config-Command: ', Command); 11: Log_Memo( ' Logging-Command: ', Command); else Log_Memo('â“ Unknown command: ', Command); end; Command := 'suspend'; case LCaser.Match(Command) of 1: Log_Memo( ' Service startet: ', Command); 2: Log_Memo( ' Service stopped: ', Command); 3: Log_Memo( 'â¸ï¸Service paused: ', Command); 4: Log_Memo( 'â–¶ï¸ Service resumed: ', Command); 10: Log_Memo( 'âš™ï¸Config-Command: ', Command); 11: Log_Memo( ' Logging-Command: ', Command); else Log_Memo('â“ Unknown command: ', Command); end; Command := 'go'; case LCaser.Match(Command) of 1: Log_Memo( ' Service startet: ', Command); 2: Log_Memo( ' Service estopped: ', Command); 3: Log_Memo( 'â¸ï¸Service paused: ', Command); 4: Log_Memo( 'â–¶ï¸ Service resumed: ', Command); 10: Log_Memo( 'âš™ï¸Config-Command: ', Command); 11: Log_Memo( ' Logging-Command: ', Command); else Log_Memo('â“ Unknown command: ', Command); end; Command := 'config_database'; case LCaser.Match(Command) of 1: Log_Memo(' Start-Command: ', Command); 10: Log_Memo('âš™ï¸Configuration in progress: ', Command); 11: Log_Memo(' Log-Command: ', Command); else Log_Memo('â“ Unknown Command: ', Command); end; end;