Jump to content

Rollo62

Members
  • Content Count

    1917
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by Rollo62


  1. Just to add some some thoughts on an alternative way, with certain pros and cons.
    I like to use a simple TDateTime helper in such uncritical situations, instead of GetTickCount, to determine timeouts:

    function  TDateTime_Helper.Timeout_MSec_IsElapsed( const AValue : Integer ) : Boolean;
    begin
        if Self.IsNull then
            Result := False                                       // is stopped => trigger never
        else
            Result := Now.MillisecondsBetween( Self ) >= AValue;  // is elapsed => trigger conditional
    end;

    Cons:
    - Yes, it has much lower performance, since this has to run through many conversions and calculations.
       Roughly speaking this is in the microseconds range, while the GetTickCounter may lay in the nanoseconds range ( approx. factor 1000 ).
       In these cases, where I just need to test this in quite large periods, like > 10 sec., I think this is not a too big deal to loose some microseconds.

     

    Pros:<
    - It adresses timing questions directly, by easier readable millisecond notation and avoids any tick count mis-calculation or logical errors by default.
    - It avoids possible overflows, which may happen at 32-Bit in about 49.7 days (using GetTickCount64 practically may solve this, by overflow in about after million years).
       (A consideration to use QueryPerformanceCounter also might solve this overflow, but in 99.99% of the use-case any high precision is not needed.)

    - It avoids possible counter blocks or counter resets, by always using the real timestamp
       (of course a user might change the system time, but this is not very likely to be done without a clear user invention).
    - It avoids issues by non-incremental counting, which is noted in the GetLastInputInfo description already

    Quote

    The tick count when the last input event was received (see LASTINPUTINFO) is not guaranteed to be incremental. In some cases, the value might be less than the tick count of a prior event.

    For example, this can be caused by a timing gap between the raw input thread and the desktop thread or an event raised by SendInput, which supplies its own tick count.

    - It elegantly avoids the need to build any additional safety measure around the overflow or incremental issue from above, just to ensure a proper incremental timeline.
    - It should immediately work in the same way under all platform, because a timeline is a universal feature.
      (GetTickCount is originally a Windows function, other platforms may handle this completely different) .

     

     

     


  2. 6 minutes ago, Kas Ob. said:

    Use Awake from Microsoft PowerToys,

    Thanks, that "Awake" is a good tip.
    Usually I use my machines more or less clean and unchanged, like their were intended from their Maker.
    Mainly because finetuning, optimizing GroupPolicies or the like is a pain in the a** and some permanent gameplay for IT nerds or admins.
    I usually try to avoid that on all cost, because that is an evergrowing overhead with little benefit, IMHO.
     


  3. 3 minutes ago, Tommi Prami said:

    Donät know what you mean by local/global.

    Local, I mean within the app itself.
    There its quite easy to detect missing keystrokes or mouse moves by slow running timer.

    So the app could manage an Idle state, similar like banking apps in the browser (log out after 5 min.).

    Global, I mean, when your app is running, but in background.
    While another, long running task is in foreground, for example you wat 1h Youtube video in the browser.
    This means Global is "active" (even if the user is idle), while your local App is Idle.
    What do you expect to happen in such situation?
     


  4. On 6/7/2024 at 9:45 AM, Tommi Prami said:

    Similarly as Screen Saver starts after some time no input and so, I would like to detect/get notification  for that.

    Its unclear to me, if you are looking after an application-wide or global detection of user-idle?
    For the local app, I think its easy, but for the global that can be tricky.
    How will external, long-running tasks in threads be handled?

    For example, if you do a longer running FTP-synchronisation, running updates or something like that:
    Does that mean the user is idle after some time, or not?

    What often disturbs me is, if the system is heavily running, like updating, giving a powerpoint presentation,
    but the OS switches unexpectedly to "idle", only because the user is waiting for finishing such a process.

    This forces me to hit the mouse from time to time, to keep the whole system awake.

    Maybe to improve to detect such situations above, it would be possible by checking the CPU load additionally and block "idle" mode 🙂

     

     

     

     


  5. I can conform Daves code too, works well here also :classic_smile:👍.
     

    3 hours ago, Stewag said:
    
        if TabControl1.ActiveTab.Name = 'XXX' then // limit message to specific tab
          showmessage('Please turn phone to landscape');

     


    What I've implemented in the former manual approach, was a system that shows a message and listens to the user turning the screen into the right position, handled by anonymous method.
    My goal was to distract the user as little as possible from his normal workflow, not enforcing him to press and buttons.

    class procedure TCore_Orientation.SetCurrent( const AOrientNew       : TScreenOrientation;
                                                  const AOrientPossible  : TScreenOrientations;
                                                  const ANotifyWhenReady : TProc );
    begin
        // Use an anonymous method, to notify the change to the caller
        FNotifyWhenReady  := ANotifyWhenReady;
        
        // Do whatever is necessary, either direct or after users message.
        
        // Register my ApplicationEvent handler, that listens to the change has occured, if that is necessary
    end;
    
    ...
    
      //  How to use it in the caller
      TCore_Orientation.SetCurrent(
                        TScreenOrientation.Portrait,          // Desired orientation
                      [ TScreenOrientation.Portrait,          // Possible orientations allowed 
                        TScreenOrientation.InvertedPortrait
                      ],
                      procedure  // Wait until User turned it as desired, or after it was set by hardware. Never reach this when cancelled.
                      begin  
                          // Do whatever you wanted to do, after desired orientation is finally set up (triggered by ApplicationEvent or direct)
                      end );
                      
    ...
    
    end;
    


     


  6. 12 hours ago, PascalBertrand said:

    I have found the problem. It is unicode in TBytes. For Android use WideStingOf() and WideBytesOf instead StrinsOf() and BytesOf().

    I would suggest not to use those second layer functions at all, but to use TEncoding for this task:
     

    Result := TEncoding.Default.GetBytes(Val);

    It seems that all relevant of those overloaded functions use the same TEnconding function internally and the rest of the overloaded functions are only for some special cases.

     


  7. I just have seen an even weirder situation.
    I already used XCode 15.3 with iOS 17.4 before, have installed the iOS 17.4 SDK in D12.1.
    Last week I happily compiled and debugged on my iOS 16.7.7 device.

    This morning, I've got the same message above and the platforms settings looks like this:

    image.thumb.png.ceab8e2f645ae9c4ec5597fc10d8c144.png

     

    It seems that XCode had un-installed the iOS 17.4 device support suddenly, over the weekend.
    Is this something that can happen, without touching the system (not even reboot over the weekend), or do I have any delusions?

     

    After pressing the GET iOS device, it also downloads the simulator

    image.thumb.png.c86db301ce02006321c8b6703e6e4b1e.png

     

    Whow, a lot of Apple-Magic involved, Apple is so much better than Windows :classic_biggrin:

     

     


  8. 9 hours ago, David Schwartz said:

    There's also the problem that XCode upgrades may be required that cannot be installed without upgrading the OS.

    Yes, that is another strategy of Apple to block unwanted, external development systems.
    My older MacBook Pro 2013 stucks on, I guess Catalina, which makes it completely unusable for development.
    The same happens now with Sonoma and older versions all the time.

    This is why I decided not to purchase the most capable, expensive Mac any longer, but looking for the cheapest version instead.
    Windows machines for the same money can do much more, more reliable and lasting much longer.

    Unfortunately also Microsoft is on the track of the business model of Apple now, more and more.

    Don't understand me wrong, cutting old tails from time to time is not a bad thing in general.
    But doing so in a too frequent manner is just kind of fraud.

    Still I'm more fond of the Windows ecosystem, the Macos ecosystem is more and more a no-go, for several lock-in syndrom reasons.
    Sooner or later, I think the Linux ecosystem will be the solution out of both booby traps, but unfortunately still is not ready yet for Delphi devvelopers.
     


  9. @Dave Nottage Thanks for giving hope and pointing to the right direction, as always :classic_cheerleader:

    As expected. simply starting and debugging an iOS 16.7.5 device with SDK 17.4 fails, with the following message:

    image.thumb.png.4007be175e9bb165946017912d57627a.png

     

     

    image.thumb.png.7c667c89434ae7d6236fb6305d1517b4.png

     

    Starting the Debug Build without debugger (  Ctrl+Shift+F9  ) works well, start and seems OK so far.

    After a few more steps, I could really debug again on XCode 15.3 + iOS Device 16.7.5 + iOS SDK 17.4.

    Edit:

    Worth to mention: Running on MacBook Pro Intel: MacosOS Sonoma 14.4.1; Parallels Desktop 19.3.0

     

    Here is the whole process is documented:

    Quote

    Update XCode 15.3:
    - XCode 15.3 with SDK iOS 17.4: Compilation OK
    - App is deployed to device iOS 16.7.5: Can be started there, seems to be running OK.
    - Problem trying debugging within IDE:
      Debugging message in PaServer:
    ">iOS-Ausgabe: dyld[4221]: Library not loaded: @loader_path/python3.10/Python
      Referenced from: <402E8408-6EBB-39CB-BB4F-9E0365D28396> /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/liblldb.15.0.7.dylib
      Reason: tried: '/Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python' (no such file), '/usr/local/lib/Python' (no such file), '/usr/lib/Python' (no such file, not in dyld cache)
    "

    - Python-Version 3.10 seems not available for the symbolic link of PaServer

      Situation:
      "$ python3 --version
      Python 3.9.6
      $ which python3
      /usr/bin/python3
      $ python3 -c "import sys; print(sys.exec_prefix)"
      /Applications/Xcode_1530.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9
     
      $ python3 -c "import os; import sys; print(os.path.join(sys.exec_prefix, 'lib', 'libpython3.10.dylib'))"
      /Applications/Xcode_1530.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/libpython3.10.dylib
      "

    - Install Python 3.10:
      brew install python@3.10

    - ensure python3.10 links correctly:
      python3.10 --version
      which python3.10

      Result:
      Python is installed
      $ python3 --version
      Python 3.9.6
      $ which python3.10
      /usr/local/bin/python3.10


    - Identify correct path to libpython3.10.dylib:
      python3.10 -c "import sysconfig; print(sysconfig.get_config_var('LIBDIR'))"

    - Can vary, use this too:
      find /usr/local -name 'libpython3.10.dylib'

      Results:
      "$ python3.10 -c "import sysconfig; print(sysconfig.get_config_var('LIBDIR'))"
      /usr/local/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/lib
      $ find /usr/local -name 'libpython3.10.dylib'
      /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib
      /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/python3.10/config-3.10-darwin/libpython3.10.dylib
      "

    - Create the correct symbolic link for PaServer:
      There are two paths, use the more general:
      sudo mkdir -p /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10
      sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib    /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python

      Results:
      "$ sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib   /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python
      ln: /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python: File exists
      "

    - It seems already existing link: Check where it points to:
      ls -l /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python

    - If the link doesn'T point to the correct libpython3.10.dylib, delete and recreate:
      sudo rm /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python
      sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python

      Results:
      "$ ls -l /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python
      lrwxr-xr-x  1 root  staff  87 Mar 18 18:35 /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python ->   /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Python3
      "

    - Remove the existing symlink:
      sudo rm /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python

    - Create the new: symlink:
      sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python

    - Restart PAServer:

      Results:
      "$ sudo rm /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python
       Password:
       $ sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib  /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python"
       No failures.
       Restart PaServer with error:
       "Last login: Wed Apr 24 18:14:37 on ttys000
       /Applications/PAServer-23.0.app/Contents/MacOS/paserver -port=64211
       The default interactive shell is now zsh.
       To update your account to use zsh, please run `chsh -s /bin/zsh`.
       For more details, please visit https://support.apple.com/kb/HT208050.
       $ /Applications/PAServer-23.0.app/Contents/MacOS/paserver -port=64211
       Platform Assistant Server  Version 14.1.13.8
       Copyright (c) 2009-2024 Embarcadero Technologies, Inc.
       EIdCouldNotBindSocket: Socket konnte nicht gebunden werden."
      "

    - Check occupied ports
      „EIdCouldNotBindSocket: Socket konnte nicht gebunden werden“ lead to Port (64211) is occupied.
      Check the port:
      sudo lsof -i :64211

      Result: Several processes still running
      "$ sudo lsof -i :64211
      Password:
      COMMAND    PID         USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
      iosinstal 3921 rowa    5u  IPv4 0x6bc8063830379fa9      0t0  TCP *:64211 (LISTEN)
      iosinstal 3921 rowa   6u  IPv6 0x6bc8062500cb5ae9      0t0  TCP *:64211 (LISTEN)
      iosinstal 3921 rowa    7u  IPv4 0x6bc8063830377169      0t0  TCP rowa-macbook-pro-5.fritz.box:64211->plsmb02-alex-p02.fritz.box:49975 (CLOSED)
      "  

    - Kill the running processes b< PID:
      sudo kill -9 3921

    - Restart PaServer  

      Result:
      - PaServer start without failure: OK
      - Delphi App,   no Debugging, starts via IDE: OK
      - Delphi App, with Debugging, starts via IDE heraus and is able to debug: OK

    - Case solved: XCode 15.3 + iOS 16.7.5 + iOS SDK 17.4 = Debugging possible

     


    I hope that can help another poor guy, who is getting crazy from the mysterious Apple moves.
     

     

    • Like 2

  10. Dear Dave,
    thanks for giving me a little relief on the upcoming forced upgrade.
    With "manually" hooking the older SDK, I mean the formerly needed manual copy and past from old XCode SDK into new XCode SDK's PackageContent.
    Is this not necessary too, which means that XCode 15 still offers 16.7.7 SDK without much hazzle?

    Please note: My main goal was not loosing the debugging ability.
    This would require from my understanding an XCode iOS 16.7.7 SDK and an iOS 16.x device.
    When using iOS 17.x SDK, I'm in danger to loose debugging option, right?

    Nevertheless, I will try to install XCode 15, but want to do that as safely as possible, to avoid destroying my current, well-working workstation setup.
    Here I've made a little "actipn plan", how to keep old and new XCode safely side-by-side.
    This is hopefully complete and let me switch safely between old and new. without and negative impact.

    Here I've tried to separate XCode 1431 and 1520 as much as possible.
    Maybe thats helpful for other too, I will check that soon and get back if something turns out terrible wrong:

    Quote


    1. Before Installation:
    - Macos: Delete Delphi 'Scratch-Dir

    2. XCode: - Ensure separate versions - XCode 14.3.1
    - Duplicate DerivedData ( BACKUP )
      Macos: cp -R ~/Library/Developer/Xcode/DerivedData ~/Library/Developer/Xcode/DerivedData_1431

    - Duplicate Archives ( BACKUP )
      Macos: cp -R ~/Library/Developer/Xcode/Archives ~/Library/Developer/Xcode/Archives_1431

      Macos: Check success by:    ls ~/Library/Developer/Xcode/

    - Duplicate XCode.plist ( BACKUP )
      Macos:                      cp ~/Library/Preferences/com.apple.dt.Xcode.plist ~/Library/Preferences/com.apple.dt.Xcode_1431.plist
      Macos: Check success by:    ls ~/Library/Preferences/*Xcode*.plist

    - XCode: Point to new, DerivedData_1431 folder
      # XCode/Settings/Locations/Derived Data/ choose from "Default" to "Custom"
      # XCode Enter new folder location, addinf _1431, to ....../Developer/Xcode/DerivedData_1431
      # Check success: Press the small icon right after the path, to open in Finder.

    - XCode: Point to new, Archives_1431 folder
      # XCode/Settings/Locations/Archives/ choose from "Default" to "Custom"
      # XCode Enter new folder location, addinf _1431, to ....../Developer/Xcode/Archives_1431
      # Check success: Press the small icon right after the path, to open in Finder.


    - Check if all changes still behave properly, restart XCode, PAServer, Delphi, Open project, try build & run, check provisioning
      Check XCode version: xcode-select -p
      Set if needed:     : sudo xcode-select -s /Applications/Xcode_1431.app

     

    - Rename XCode.app to XCode_1431    

      # After renaming under XCode/Settings/Locations/CommanDLine Tools, the selection of the correct command line tools needs to be done again,
         requiring another password entry, but then is pointing to the changes XCode_1431.app.


    3. XCode: - Ensure separate versions - XCode 15.x
    - Setup as usual
      Check XCode version: xcode-select -p
      Set if needed:     : sudo xcode-select -s /Applications/Xcode.app

    - Check if all changes still behave properly, restart XCode, PAServer, Delphi, Open project, try build & run, check provisioning

    4. XCode: - Ensure separate versions - XCode 15.2
    - Duplicate DerivedData ( BACKUP )
      Macos: cp -R ~/Library/Developer/Xcode/DerivedData ~/Library/Developer/Xcode/DerivedData_1520

    - Duplicate Archives ( BACKUP )
      Macos: cp -R ~/Library/Developer/Xcode/Archives ~/Library/Developer/Xcode/Archives_1520

      Macos: Check success by:    ls ~/Library/Developer/Xcode/

    - Duplicate XCode.plist ( BACKUP )
      Macos:                      cp ~/Library/Preferences/com.apple.dt.Xcode.plist ~/Library/Preferences/com.apple.dt.Xcode_1520.plist
      Macos: Check success by:    ls ~/Library/Preferences/*Xcode*.plist

    - XCode: Point to new, DerivedData_1520 folder
      # XCode/Settings/Locations/Derived Data/ choose from "Default" to "Custom"
      # XCode Enter new folder location, addinf _1520, to ....../Developer/Xcode/DerivedData_1520
      # Check success: Press the small icon right after the path, to open in Finder.

    - XCode: Point to new, Archives_1520 folder
      # XCode/Settings/Locations/Archives/ choose from "Default" to "Custom"
      # XCode Enter new folder location, addinf _1520, to ....../Developer/Xcode/Archives_1520
      # Check success: Press the small icon right after the path, to open in Finder.


    - Check if all changes still behave properly, restart XCode, PAServer, Delphi, Open project, try build & run, check provisioning
      Check XCode version: xcode-select -p
      Set if needed:     : sudo xcode-select -s /Applications/Xcode_1520.app

    - Rename XCode.app to XCode_1520

        
    5. Switching between XCode_!431 and XCode_1520
    -  Set    : sudo xcode-select -s /Applications/Xcode_1431.app
                sudo xcode-select -s /Applications/Xcode_1520.app
       Check  : xcode-select -p
       Restore: cp ~/Library/Preferences/com.apple.dt.Xcode_1431.plist ~/Library/Preferences/com.apple.dt.Xcode.plist
                cp ~/Library/Preferences/com.apple.dt.Xcode_1520.plist ~/Library/Preferences/com.apple.dt.Xcode.plist





     


  11. 7 hours ago, Dave Nottage said:

    Delphi can already use Xcode 15. The biggest issue at the moment is debugging with iOS 17 (or higher) devices, which is a problem regardless of Xcode version. Debugging on devices with iOS 16.x still works using Xcode 15. A secondary issue is this onea problem if your app needs to link to 3rd party binaries that were built with Xcode 14 or higher.

     

    Thanks for clarification, I assumed that XCode 15 won't support or can handle older iOS 16.x SDKs any longer.
    If XCode 15 is bundled with and hardly enforces SDK 17.4, or not allow to load or use SDK 16.x and longer, then this won't help either.
    Can you confirm that XCode 15 can still be used for debugging same as XCode 14.3.1, under iOS 16.x, without too much trickery ?

    The older SDK will have to be hooked into XCode manually, with all possible incompatibilities.
    If would expect something like this:

    Quote

    Integration of an older SDK in Xcode 15:
    - Obtaining the older SDK:
            Older iOS SDKs are not directly available through official channels.
           They must be extracted from an older Xcode version.

    - Extracting the SDK:
            Navigate to the Xcode app in the Finder (right-click and select “Show package contents”).
            Find the SDK folder, typically in the path (Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/).
            Copy the desired SDK folder (e.g. iPhoneOS16.74.sdk).

    - Add the SDK to Xcode 15:
            Go to the corresponding directory (Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/).
            Paste the copied SDK folder here.
            Boot XCode.
    - Macos Delphi Scratch-Dir, remove the scratch directory and its entry

    - Delphi SdkManager, check für SDK and "Update local cache"



    Ok, I found this, which states that Delphi already supports the newer LLDB debugging system, perhaps since Alexandria, and that should be a good thing.
    https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers

    I will update my table above accordingly.

    Are there any official notes about whats changed internally and whats currently still possible?
    I must confess, that I had not followed the WWDC videos, because lack of time,
    would be great to find some official statements about these changes and roadmaps.

     


  12. 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

     


  13. Hi there,

    I'm still evaluating the D12.1 version currently, it all looks pretty much OK so far.

    What I have notices is, that the info.plist now containse more entreies:

    	<key>DTPlatformName</key>
    	<string>iphoneos</string>
    	<key>DTPlatformVersion</key>
    	<string>16.4</string>
    	<key>DTPlatformBuild</key>
    	<string>20E238</string>
    	<key>DTXcodeBuild</key>
    	<string>14E300c</string>
    	<key>DTSDKBuild</key>
    	<string>20E238</string>

    Al this is understandable, to improve the development tools stability.
    Only the DTPlatformName wonders me, since I have checked "iPhone & iPdad" for the UIDeviceFamily:

    Which appears like this:

    	<key>UIDeviceFamily</key>
    	<array>
    		<integer>1</integer>
    		<integer>2</integer>
    	</array>

    The general conclusion is like this:

    UIDeviceFamily: Defines the device classes on which the app can be executed. The possible values are:
            1: The app is intended for iPhone (and iPod touch).
            2: The app is intended for iPad.
            If both values are specified, the app supports both iPhone and iPad.

     

    DTPlatformName and other DT keys: These keys are specifically intended to provide information about the development environment and target platform, including the version of Xcode and iOS SDK used to build the app.
    They are important for the build and review process in the App Store, but they are not directly affected by the UIDeviceFamily setting.

    Perhaps this means, that the app should be broadly compatible within the iOS ecosystem, which is relevant during development and later distribution via the App Store.

    This also seems to fix an known error: https://docwiki.embarcadero.com/Support/en/“ERROR_ITMS-90507:_Missing_Info.plist_value._A_value_for_the_key_'DTPlatformName'_is_required”_when_submitting_an_app_to_the_iOS_App_Store

    Here some info from another source:
    https://github.com/godotengine/godot/issues/74154

    https://forums.developer.apple.com/forums/thread/111697

     

    What the heck is this DTPlatformName good for, is there any offical documentation about it?

    Maybe there are there other options too ...

     

     

     

    • Like 1

  14. You could consider a more asynchronous design, for example with TTask, that could avoid the pitfalls of Applicaton.ProcessMessages completely.
    The use of immutable objects could make your design even more robust.

     

    procedure TMyProcess.RunMyProcess;
    begin
      TTask.Run(
        procedure
        var
            LImmutableStatus : TImmutableObject;
            LImmutable       : IImmutableObject;
        begin
          try
    
            LImmutableStatus := TImmutableObject.Create;
    
            while ProcessIsRunning do
            begin
              Step1;
              Step2; 
    
              LImmutable := LImmutableStatus.Clone;
              
              TThread.Synchronize(nil,  // or better TThread.Queue(    if you want to avoid blocking
                procedure
                begin
                  { Update User Interface }
                  UpdateUIWhenNeeded( LImmutable );
    
                  LImmutable := nil;
                end
              );
    
              Step3;
    
            end;
          finally
            TThread.Queue(nil, UpdateUIWhenNeeded );
    
            LImmutable       := nil;
            LImmutableStatus.Free;
    
          end;
        end
      );
    
    end;

    Just as a rough idea, without checking your specific needs.

×