Rollo62

This is of coarse a question of personal naming preferences. "Common" and "Implementation" sounds to me too much like implementation details. Thats why I personally like MyTask and all other related details are defined after, like MyTask.Types MyTask.Intf MyTask.Impl MyTask.Factory My goal is, that when using MyTask, I would never consider anything of the "details" above, in the best case. Thats also why its the shortest name and only talking about the task itself. And yes, there surely can be different naming variants too, like MyTask.Utils, wherever this makes sense to use them separately.

In general you are right, but maybe I have not explained the setup good enough. I want to define a sub-system, which might be a little more complex, so that I can divide it into several sub-units, to modularize the whole task and to avoid monolithic classes. The main "access" unit shall only provide access to this sub-system, but of coarse the main purpose is to avoid any circular references in the first place. The modularization helps to separate concerns only needed within this sub-system and improves testability. You are right that code tends to get entangled over the years, but to entangle and repair only this "one" sub-system is much easier IMHO, than to entangle these main separate sub-units, which are maybe cluttered wildly all over the project. I use also a clear naming convention that supports the whole context, for example like: MyTask.Types MyTask.Main.Interfaces MyTask.Main.Implementations MyTask.Sub.Interfaces MyTask.Sub.Implementations MyTask <= I use this as the main accessor unit containing type ETypes = MyTask.Types.ETypes; TTypes = MyTask.Types.TTypes; IMain = MyTask.Main.Interfaces.IMain; ISub = MyTask.Main.Interfaces.ISub; TMyMain_Factory = class function New_Main : IMain; function New_Sub : ISub; end; .... This way, I only need MyMain unit to handle the tasks from outside. When I just need lightweight access to the types or interfaces in other classes, I still can use MyTask.Types, MyTask.Sub.Interfaces or MyTask.Main.Interfaces without any harm. Not sure if this would make any big benefit. The whole implementation details shall be well hidden behind the MyTask unit. Just roughly throw the code in here, to get a better picture of what I meant. The whole thing needs of coarse strict discipline too, not to use side-effects, which is probably the weak point. My argument is, if you use this approach it shall be guaranteed that you never get any circular reference issues. While using loosely couples units, you're never sure if you see any circular or other side-effects.

I like to use such an approach especially if a topic is divided into a set of several related units, which tend to rely on or build a common type system. In my opinion this helps to point out the internal relations, to better organize the units and to avoid circular references. In that case I have defined one main "access" unit, which works as a fascade to cover a few closely related internal units, while in the other sub-units different implementation details are encapsuled. The idea is, that the main "access" unit provides all necessary classes and types in one single unit, with no need to include many other sub-units. This helps to separate various sub-concerns nicely, and bring the complete functionality in one place. That way, of course I still can use the sub-units separately, if there is any need. Perhaps this is another philosophical question, or is there another rule of programming that speaks hardly against this?

Thanks for pointing to this, there I also find the link to Darian Miller's great version list https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List Thanks for that great summary. Which makes me reconsider my simplified, internal nomenclature, which also uses 3 elements Major, Minor, Update. Nevertheless, I think this list is perhaps not 100% clear regarding the patch nomenclature, or I miss something, for example. VER360 D29.ATHENS. 12.1.0.1 12.1 Patch 1 VER360 D29.ATHENS. 12.1.0.0 RAD Studio 12 Athens Release 1 VER360 D29.ATHENS. 12.0.0.2 12 Inline Release VER360 D29.ATHENS. 12.0.0.1 12.0 Patch 1 VER360 D29.ATHENS. 12.0.0.0 RAD Studio 12 Athens VER350 D28.ALEXANDRIA.11.3.0.0 RAD Studio 11 Alexandria Release 3 VER350 D28.ALEXANDRIA.11.2.0.1 11.2 Patch 1 VER350 D28.ALEXANDRIA.11.2.0.0 RAD Studio 11 Alexandria Release 2 VER350 D28.ALEXANDRIA.11.1.0.2 11.1 Patch 2 VER350 D28.ALEXANDRIA.11.1.0.1 11.1 Patch 1 VER350 D28.ALEXANDRIA.11.1.0.0 RAD Studio 11 Alexandria Release 1 VER350 D28.ALEXANDRIA.11.0.0.4 11.0 January PAServer Patch VER350 D28.ALEXANDRIA.11.0.0.3 11.0 November Patch VER350 D28.ALEXANDRIA.11.0.0.2 11.0 PA Server Patch for iOS VER350 D28.ALEXANDRIA.11.0.0.1 11.0 Patch 1 VER350 D28.ALEXANDRIA.11.0.0.0 RAD Studio 11 Alexandria VER340 D27.SYDNEY. 10.4.2.3 10.4.2 RTL Patch 1 VER340 D27.SYDNEY. 10.4.2.2 10.4.2 General Patch 1 VER340 D27.SYDNEY. 10.4.2.1 10.4.2 Compiler Patch 1 VER340 D27.SYDNEY. 10.4.2.0 10.4.2 RAD Studio Sydney Update 2 VER340 D27.SYDNEY. 10.4.1.4 10.4.1 Sydney Patch 4 VER340 D27.SYDNEY. 10.4.1.3 10.4.1 Sydney Patch 3 VER340 D27.SYDNEY. 10.4.1.2 10.4.1 Sydney Patch 2 VER340 D27.SYDNEY. 10.4.1.1 10.4.1 Sydney Patch 1 VER340 D27.SYDNEY. 10.4.1.0 10.4.1 RAD Studio Sydney Update 1 VER340 D27.SYDNEY. 10.4.0.0 RAD Studio 10.4 Sydney ... This leads me to the rule for versioning: Major Release Update Patch version version version version 10. 4. 2. 2 Where the 4 elements have the meaning: Major = is the major version Release = is a kind of Minor version Update = is a kind of kumulative, big Patch or Build Patch = is a kind of Build, as small patch, or inline release, or maybe build, where the numbering and naming can be not very consistent. Patch can be a running number, no matter if the original patch number may differ. VERnn0 = A combination of relocated running Major and Release, with the options to have a 3rd number for exotic reasons (not happened in the near past). Is my understanding of the everchanging naming wilderness correct, to get a more consistent view about this? At least for future releases. The question will be, how to detect the Update and Patch parts by runtime correctly? I think this is not consistently possible at all, and always will be a manual process, or a lot of hardcore trickery, by checking DLL versions or the like.

Nope. This link works https://www.cravencountync.gov/263/GIS-Mapping but clicking from there into https://gis.cravencountync.gov/ doesn't work on Windows 11. Ok, I'm not living in USA, so maybe some kind of IP-blocking? Edit: Yes, after VPN I can reach this from Windows. https://gis.cravencountync.gov/images/activebookings.html

Have you set the NSAppTransportSecurity and other Flags in the info.plist, according to your needs? Here is a sample, for various settings: <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <!-- Example for >= iOS 9 --> <key>NSExceptionDomains</key> <dict> <key>example.com</key> <dict> <key>NSIncludesSubdomains</key> <true/> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSExceptionRequiresForwardSecrecy</key> <false/> </dict> </dict> </dict>

Is this something that could match your needs? (untested) type QCL_WORD = SmallInt; t_bus_flags_w4 = record private data: QCL_WORD; function GetBit(Index: Integer): Boolean; procedure SetBit(Index: Integer; Value: Boolean); public property AlarmState: Boolean index 0 read GetBit write SetBit; property AlignmentState: Boolean index 1 read GetBit write SetBit; property InversionWait: Boolean index 2 read GetBit write SetBit; property OutOfMinBound: Boolean index 3 read GetBit write SetBit; property OutOfMaxBound: Boolean index 4 read GetBit write SetBit; property BelowSafetyHeight: Boolean index 5 read GetBit write SetBit; property InWorkingPos: Boolean index 6 read GetBit write SetBit; property LockingLatchState: Boolean index 7 read GetBit write SetBit; property BatteryWarning: Boolean index 8 read GetBit write SetBit; property BatteryAlarm: Boolean index 9 read GetBit write SetBit; property EVRState: Boolean index 10 read GetBit write SetBit; property LoadWeightZone: Byte index 11 read GetBit write SetBit; // 2 Bits property ColumnIsConsistent: Boolean index 13 read GetBit write SetBit; property LiftSetAcquireReq: Boolean index 14 read GetBit write SetBit; property MovementModeAbsolute: Boolean index 15 read GetBit write SetBit; end; implementation function t_bus_flags_w4.GetBit(Index: Integer): Boolean; begin Result := (data and (1 shl Index)) <> 0; end; procedure t_bus_flags_w4.SetBit(Index: Integer; Value: Boolean); begin if Value then data := data or (1 shl Index) else data := data and not (1 shl Index); end; // For 2-Bit-Property LoadWeightZone we need some special Getter and Setter function t_bus_flags_w4.GetLoadWeightZone: Byte; begin Result := (data shr 11) and 3; // Extract 2 Bits at Position 11 end; procedure t_bus_flags_w4.SetLoadWeightZone(Value: Byte); begin data := (data and not ($3 shl 11)) or ((Value and $3) shl 11); // Set 2 Bits at Position 11 end;

No nooo, its just like in the Jurassic Park: The strange AI animals can be nice to watch and study, but be very sure to keep the cage door closed

Maybe you could vote for an extension of @Jim McKeeth nice ColorPicker here.

Yeah, it should look like this, originally. But unfortunately the AI refuses to reproduce logos, socks, styles and so on, in the right way. Nevertheless, I'm sure this is quite the right picture of a messy programmer, at least as I am If anybody will tell you that AI ist not ruling the word yet, this proofs him work. AI already dictates how the the political correct content shall look like and refuses to produce anything else you ask for.

b51995d0-8bea-4723-8cf8-ced1a256af59.webp

I still have not a smooth workflow under iOS, as before. With the injection of the current lldb SymLink into the PAServer package, I could at least start an app on a device. It behaves as follows: Compile and RunNoDebug - Deploy and Launch after compile - iOS app gets loaded - After deployment, the app tries to start but immediately fails (due to missing debug support) - The app pops up shortly, then crashes immediately - At least I can start the app manually Compile and RunWithDebug - Deploy and Launch after compile - After deployment, the process stucks (due to missing lldb), PaServer messages look as below - The problem is, that the IDE crashes too and must be restarted, same as PaServer. The PaServer process seems to continue even after close. - I used to kill all PaServer processes ( can be more than one ), by shell command, but thats an ugly solution. - I've found a possible solution by PaServer command s ( stop server = kill the process ) and restart PaServer again - But that doesn't prevent the IDE crash. It is really a messy workflow now, if pressing the wrong button it crashes, debugging is no longer possible. XCode_1540, RadStudio 12.1 Upd 1 Does this behave now same on all machines, or is it only here? I really hope for a fix, that bring back normal debugging soon, I hope by patch of IDE & PaServer. Is there anything I still can improve by myself?

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

Great, nothing is overengineered here at all. I was looking for something like that for a long time, already wanted to design my own, used MustangPeak under VCL in some projects. Color theory is a science on its own. Solving any task completly without leaving out necessary parts in the first place is NOT a definition of Overengineering, IMHO In case of someone is overwhelmend from reality, you could consider to introduce several "dummy-mode levels", to hide any frightening complexity from the more sensitive users.

See also here https://www.thedelphigeek.com/2021/02/readers-writ-47358-48721-45511-46172.html

Yees, thats a nasty bug. Thats why I had choosen long time ago, to always add a proper scope around even the simplest lines. if FWorkOrderManager.GetWorkOrderDataByIndex(WorkOrdersSelectedRow - 1, Data) then begin // evaluates file index FileIndex := ARow - 1; end; IMHO that increases readability and avoid a lot of such hard to see errors. You're lucky here, that the compiler throwed a warning 🙂

I was trying to find some more insights, since my debugging at XCode 15.4 is currently broken. Here is what I have found so far, perhaps there are more tips to workaround somehow. Due to the fact that it worked for a while at least release & run from the IDE, but now suddenly seems to be broken for no reason, I had to look into this again. My setup: Macbook Intel Macos Sonoma 14.4.1 (23E224) XCode 15.4 (15F31d) - Multiple installations XCode 14.3.1, but the XCode 15.4 is the active selected, by xcode-select - All tools running Delphi RAD Studio 12.1 Patch 1 PAServer 14.1.14.0 Situation: Compile & Linking OK Run & Debug on device: Not OK ( Please do not propose using simulators, I'm looking for a workaround on device level ) XCode 15.4 - Seems to have only Python3.9 shipped within its PackageContent "/Applications/Xcode_1540.app/Contents/Developer/usr/bin" Python3.10 - Has to be installed manually, will land into User folders: /usr/local/bin/python@3.10 and /usr/local/opt/python@3.10/bin - Can be linked by SymLinks to PAServer PAServer - Seems to use Python3.10 internally - Seems to use llvm, lldb internally LLVM ( seems to be required by PAServer - iosinstall) - When installed by bew, it seems to depend on Python3.12, installs Python3.12 too. - Can be linked by SymLinks to be globally available Python3.12 ( seems to be required by llvm ) - Can be linked by SymLinks to be globally available ( but this is maybe the issue in PAServer, linking to Py3.10 and Py3.12 at the same time ) Problem: Signing: Seems OK via PAServer so far Launching: Seems not possible to launch the app via Delphi - Launch by: ""/Applications/PAServer-23.0.app/Contents/MacOS/iosinstall" -W -i bba94cfcbb26d9ff31774ac97d06e929f954993d0 -L -z "/usr/local/bin/lldb" -q -b "/Users/currentuser/PAServer/scratch-dir/currentuser-MB02_Rx1200_Athens/MyApp.app" Deployment - The app can be deleted, this commands seems to deploy and try to run it. - The app runs shortly, then crashes - When running the same, uploaded app manually, by double-click: The add starts and runs fine, only the iosinstall crashes Log and Eventlog - The command above returns like this - The Eventlog looks like this So the root cause seems to be the "iosinstall" command, IMHO. Maybe more specifically the usage of Python3.10 and Python3.12 within the same PAServer package, calling iosinstall and lldb and others. I have tried a few tests and still I'm not really clear why this not simply runs, no matter what Python library involved. Why does XCode 154. only include Python3.12? Why does llvm depends on Python3.12 (there seems no easy way to downfrade this, ate least not with brew and pip3) Is there any known workaround at the time now, what needs to be done? Apple development again causes my days or fumbling, instead of easy click-and-run. Why seems Python stuff so sensitive on versioning, are these known issues? Mybe some Python experts may lead to some easy tools or ideas to solve it.

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

Yes, you name it. Thats why I use portable, non-service tools wherever I can, looks like Awake plays in that category too, have not tested yet. I cannot understand this permanent services and processes bloat also, which only brings performance and reliability to the ground level.

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.

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?

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 🙂

CrossPost

Do you mean something like this, for reverse GeoCoding? https://nominatim.openstreetmap.org/search?q="Köln, Heumarkt"&format=json