Anders Melander

You should examine the diff of your changes before you commit them instead of just committing all files that has changed. Practices differ but for example when I have made a change to a form I only commit that specific change - and directly derived changes. All the Explicit* and Original* fluff that the IDE changes are left out. Also adding a file to a project usually result in 40-50 changes (relating to platforms I haven't even installed) of which only one or two need to be committed.

We also do all work in feature branches but our branches are always pushed to remote (and for this reason alone we almost never rebase). We need to have the branches on the remote for several reasons; There are mostly more than one person working on a feature and they need to have access to each others changes. Of course it's up to the individual if they want to create local branches of the feature branches and do their work in those. Personally I just stash and only push when I have something that I know will build. We also to have the branches on the remote in order to have the build server run unit- and integration tests on them. Finally when work on a feature branch is complete we create a pull request to have it merged into the main branch. When QA have tested the build, which they've grabbed from the builder server, someone performs code review on the changes and only then is the PR allowed to be merged into the main branch.

Yeah, that one is one of the more stupid things I've encountered. But what does it have to do with the naming?

I don't think you can push unless you're on the tip of a branch. Your changes would overwrite the changes made between your current commit and the remote tip. I guess the remote could do an automatic merge but would that then be made in a new commit or would it alter the commit you made? Doesn't seem likely.

What problem is that supposed to solve?

1 bit, 2 bit, 3 bit, 4 4 bit, 3 bit, 2 bit, 1 You're bit, he's bit, no bit, none - Eminem

I think maybe she used a 3 bit computer and the "7 days" legend is just the result of the actual count overflowing. Anyway. I was referring to an actual entity, not an imaginary one.

I'm not saying "don't use string helpers". I'm saying that if they had made them 1-based like God intended then there would have been less confusion. Now we have one set of functions that are 1-based and one that is 0-based. How is that improvement? Ironically I had to look at your 1-based example to figure out what you 0-based example did. Here's a 1-based version without the bias: begin Result := Value; if Result.StartsWith(Prefix, IgnoreCase) then Delete(Result, 1, Prefix.Length); end;

In the calls to LoadFromStream set the Size parameter to 0 (zero). That resets the position to zero and copies everything in the source stream.

The manual apparently There's a string.ToLowerInvariant for that purpose. The ancient Egyptians? I think they just used a larger chisel for emphasis That also makes it easier to write the feature specification: Just copy everything that .NET does. In some cases they even copied their documentation verbatim but failed to realize that it referenced stuff that they hadn't copied. I think a big problems with the string helpers is that they operate on zero based string indices. As if we didn't have enough opportunity off-by-one errors already.

One of the first things I do after a fresh Delphi install is to mark the VCL source read-only. I don't know if that would have prevented it.

or any grid for that matter. Well I thought that was a given and that the excessive row count was just to exacerbate the poor performance for benchmark purposes.

Google doesn't have an API anymore and even if they did it wouldn't be advisable to use it. Microsoft Translator Service has a free tier with a limit of 2 million characters per month. So far I haven't hit their limit with my own personal use. Microsoft Terminology Service is free. I haven't tried DeepL but I have it on my TODO list. They don't have a free tier though so it doesn't have high priority. Of these, for "small application texts", I would recommend the Microsoft Terminology Service. I usually get very good results with it. You can try it out in my translation tool (and look at the source for inspiration): That reminds me that I need to get a new version of BTM uploaded as the current one, compiled with D10.3.3, fails to communicate with the Microsoft Terminology Service SOAP service because of a bug in Delphi's SOAP library. Should be fixed in 10.4.1 AFAIK.

Yes. You are right.

It discards changes to all tracked files. Basically it makes sure that what you have on disk matches what's in your branch. You can also do a mixed reset. That moves the index in your commit history but keeps whatever you have on disk. Then there's a soft reset but I can't remember what that does as I never use it. The reason I'm doing a reset is that otherwise pull will do a merge with whatever I have on disk and that isn't what I want. I'm not actually doing anything since my tool does all this for me, but you get the picture. Personally I prefer Atlassian SourceTree. I have Tortoise Git installed as well because there are a few things it does better (Blame for one). I've not tried any of the commercial GUI clients. There was a thread here a few weeks back where different Git clients were discussed.

If you start with i := 1 then the 0 and 1 elements will always be swapped. If you then also change the test for (i = 0) to (i = 1) then the 0 and 1 elements will never be swapped. Try to run it in your head with just three elements in reverse sort order. iteration elements 0 3 2 1 i=0: inc ^ 1 3 2 1 swap and dec ^ 2 2 3 1 i=0: inc ^ 3 2 3 1 ok: inc ^ 4 2 3 1 swap and dec ^ 5 2 1 3 swap and dec ^ 6 1 2 3 i=0: inc ^ 7 1 2 3 ok: inc ^ 8 1 2 3 ok: inc ^ 9 1 2 3 done ^

Well now that I've had my fun here's a serious suggestion: type TGridCracker = class(TCustomGrid); procedure SortGrid(Grid: TCustomGrid; ACol: integer; Ascending: boolean); begin var Rows := TList<integer>.Create; Rows.Capacity := Grid.RowCount - Grid.FixedRows; // Populate list with row indices for var i := Grid.FixedRows to Grid.RowCount-1 do Rows.Add(i); // Sort the row indices Rows.Sort(TComparer<integer>.Construct( function(const A, B: integer): integer begin Result := AnsiCompareText(Grid.Cells[ACol, A], Grid.Cells[ACol, B]); if (not Ascending) then Result := -Result; end)); // Move the rows in-place to their new position Grid.BeginUpdate; try var ToIndex := Grid.FixedRows; for var FromIndex in Rows do if (FromIndex <> ToIndex) then TGridCracker(Grid).MoveRow(FromIndex, ToIndex); finally Grid.EndUpdate; end; end; I've not used TStringGrid in decades but I think it might be fast enough if you can get it to compile (I haven't tried). I'm assuming that the protected MoveRow method does what we need (i.e. move a whole row in the grid). It might not though. A minor optimization would be to use a TArray<integer> instead of a TList<integer> but the improvement would be minimal.

That won't work. You need to start at zero. That's cheating. Then you might as well just optimize it to use TList.Sort

Yes it's horrendously slow but if performance isn't important it's nice and short and easy to implement - if you can remember the algorithm. I've used it a few times in throw away production code just because I like its simplicity. Compare to how often people get quicksort wrong when they roll their own.

I don't do these thing from the command line, so I may be wrong, but it seems to me that you're: Switching the active branch to <ticket-branch-name>. Pulling the remote master onto it. Switching to master. Pulling the remote master again. Merging <ticket-branch-name> into local master. Pushing local master to remote master. I can't understand why you're doing 1-2. In particular #2 seems wrong. I think you may be creating foxtrot merges. Did you forget to commit your changes to <ticket-branch-name> before you switched to master? You haven't specified if your local branches are setup to track the corresponding remote ones. If they're not, and you haven't adjusted your git commands for that, then you might be working with detached heads. Anyway, here's what (I think) I would do: Switch to local <ticket-branch-name>: git checkout <ticket-branch-name> Make my changes... Stage my changes: git add <files> Commit changes to local <ticket-branch-name>: git commit -m "blah blah" Fetch master from remote: git fetch (or just: git fetch --all) Note that you you might need to do git fetch origin master:master depending on if your local master is tracking the remote master or not. Switch to master: git checkout master Clear all changes from working directory: git reset --hard Pull from remote master: git pull origin Merge local <ticket-branch-name> into local master: git merge <ticket-branch-name> Push local master to remote master: git push origin master Again: I don't use the command line so the above is just my understanding of what my GUI tool does for me. If you were using a GUI Git tool it would be much more clear to you what's going on.

Funny name you say? How about he optimize it with Gnome sort instead: procedure GnomeSort(List: TList<integer>); begin var i := 0; while (i < List.Count-1) do if (i = 0) or (List[i] >= List[i-1]) then Inc(i) else begin var Swap := List[i]; List[i] := List[i-1]; List[i-1] := Swap; Dec(i); end; end;

MoveFileEx with the MOVEFILE_DELAY_UNTIL_REBOOT flag can do that already. Virtual Channel client DLLs are loaded at boot so it's pointless to try to replace the file without a reboot. That said, you could solve it with two DLLs: The Virtual Channel client DLL contains the auto-update functionality but forwards all the VirtualChannel* DLL calls to... The "other DLL" which implements the actual functionality. Of course the Virtual Channel client DLL will need to load the "other DLL" dynamically or you will have the same problem with both DLLs. When the Virtual Channel client DLL determines that it needs to update the "other DLL" it just unload the old DLL and load the new DLL. If the Virtual Channel client DLL needs to update itself it can do so with MoveFileEx (or just unregister the old DLL and register the new) and a reboot. Maybe it's enough to restart the Remote Desktop Services (the documentation just states that the DLL is loaded during Remote Desktop Services initialization), but you will need a third file, an application, that does that for you. Give it a try. Edit: I just realized that the above was basically what @Fr0sT.Brutal wrote.

Re: Plastic Merge. It appears that the free Personal Edition isn't available anymore. What you can do instead is download and install the Plastic client: https://www.plasticscm.com/download/downloadinstaller/9.0.16.4519/plasticscm/windows/client?flags=None and then just use the Diff/Merge utility: mergetool.exe I've just tried a fresh install and it worked fine.

You can republish properties: type TLabel = class(TLabel) published property Caption; property Align; end;

AFAIR you just change the order in which the properties are declared. Note though that I've seen cases where a component depended on properties being set in a specific order during load. Can't remember any specifics. You could also use a diff tool that can recognize moves. For example Plastic Merge.