Lars Fosdal

Have you tried using an XML lint tool or validator to check the integrity of the XML file? The MS Word Error is inconclusive to whether it is a structural error, character set error, or logical error in the XML.

Dependency Injection. Works like charm unless you need absolute raw performance. I use that quite a bit for pluggable capabilities. I am not a fan of .inc files at all. I use platform specific units and ifdef the uses statements. I do have a xplatform unit that ifdefs the various implementations - many of who simply raise Exception.Create('Not implemented'); 😛

I am not confused. I am frustrated. I want both. Most of all, I want 64-bit debuggers that understand threads and make it easy and robust to focus debugging on specific threads, and that doesn't suddenly stop breaking on breakpoints or break on "invisible" breakpoints in Indy, or just purely stop responding completely. I'd love to be able to "disable" exception breaks for specific threads and only for those threads. I want the broken HighDPI properly and finally fixed. I want the code generation significantly improved for 64-bit. I want RTL, VCL and FireMonkey to be rock solid and efficient. But - also ... I want Generics constraints for enumerated types so that I can use enumerated type and set type operators. I want proper nullable type support, including the relevant operators. I want ARM support for Windows. I want ARM/Linux support for Raspberry PI. I want the static code analysis capabilities of FixInsight and similar, to be built into the DSP. I want a package manager that really works, unlike GetIt which is just a glorified downloader and installer. I want Swagger support for APIs.

If a column is nullable, it is a good practice (for T-SQL) to use stuff like ISNULL(MyString, '') or ISNULL(MyInt, 0) in queries, particularly if there are totals or min/max operators in the query or view.

The link appears to work for me.

If you avoid this, one of the branches will be left unfixed. You always must fix it in both places. The question really boils down to which model you use.

I guess it is because conceptual explanations tend to look at time starting from the top, going down - while actual systems tend to show recent events on top, going back in time as you move downwards. Ref. email inboxes, Windows Event Viewer, GitKraken, etc 😉 For the graphical view, it also makes sense to have the main branch + longest living branches on the left, since the number of branches varies.

The RFC describes four variant formats, and the MS GUID is variant 2. I am simply wondering if there is another implementation than the MS one available to me in case the MS one is not compatible with IBMs requirements. uses System.SysUtils; var guid: TGuid; sguid: string; begin if CreateGUID(guid) = S_OK then sguid := 'urn:uuid:' + guid.ToString.ToLower;

As long as what you push to the shared repository, compiles 🙂 It is very annoying if teammates commit code that doesn't compile.

Correct. Most UIs for git visualize branches and merges.

They are. GitKraken supports implements the GitFlow convention, simplifying the execution of that workflow.

Ref the chart I posted. That patch or hotfix if you like can be spun off the release branch and committed and merged back into the release branch and the development branch. I am fond of GitKraken here, because it supports GitFlow which simplify doing these things.

They are similar, but not identical it seems - judging by this: https://github.com/stettberger/git-external

Ref. https://nvie.com/posts/a-successful-git-branching-model/ We came from SVN, so we had to rework our mental SVN model for git, but once we learned the mechanisms, none of us miss SVN at all. One of the hurdles was not thinking about master/main as trunk, but as the release branch, and that you did all the work you used to put in SVN trunk, into a develop branch. Feature branches are really, really helpful - but don't let them drag out too long, or you will likely be facing merge conflicts if you are multiple people working in the same repository.

TBH, I don't know for sure since I've never used that feature myself since we always use the same version of the shared code for all our projects. I'd have to read up on sub-modules and externals to find out, but perhaps somebody else here is using this?

As we've touched on before, @Uwe Raabe , the "fun" starts with 3rd party design time components. Maintaining projects that use two different versions of f.x. TMS components is something I really want to avoid if I can.

Pinning a version means that you pull from a specific version instead of the HEAD version (i.e. latest)

We use this model. Works quite well. https://nvie.com/posts/a-successful-git-branching-model/

We do that, but we can do that because our projects are inhouse and closely related, and we have control over the release and upgrade cycles, and we always upgrade all apps to using the latest 3rd party libs. But - if there are 10+ projects that are not really related, they would need repositories of their own, and the shared code would need to have a repository of its own. The question remains whether the shared code should always follow the latest version, or if you pin a version per project and upgrade on need only. The third party libs dependencies will be a challenge here - especially if there is a difference of version of the libs between the projects.

That I did not know. Thank you, Uwe!

As I understand, the APIs are bound at runtime, or am I mistaken? Can it be that your application tries to use an API that doesn't exist in a compatible form on SDK14 / S3? Edit: OR - the API is access restricted and you are not checking for the rights to access the API before use? Edit 2: I want to point out that all of the above are pure speculations on my part.

I agree. NULL = There is no list. Empty = There is a list, but it is empty.

One thing about component names is that you f.x. cannot dynamically add multiple identical frames to a form at runtime unless you ensure a unique name by doing something like this: type TOurFrameBase = class(TFrame) constructor Create(const AOwner: TWinControl); reintroduce; end; constructor TOurFrameBase.Create(const AOwner: TWinControl); begin inherited Create(TComponent(AOwner)); FPanel := AOwner; Parent := AOwner; Align := alClient; Name := ClassName + '_' + Seed.Next.ToString; // Ensure that every frame created gets a unique name I.e. we ensure a unique name for the frame instance. (Seed is a singleton for the class that delivers a unique (incrementing) cardinal (per app life time)). If you don't do this - you will run into duplicate name errors.

I don't mind the braces, TBH - but some of the expression operators still irk me, probably because I don't use them all day.

Sure, that and array[0..n] of Byte; are pretty common. Still, Byte sized variables and constants are used a lot in various APIs. Even nuggets like SizeOf(Byte); can be found sprinkled around the RTL and VCL, although I believe the universal result of that is 1.