Leaderboard

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.

That's Bubble Sort you are using, which is not renowned for speed but mostly for the funny name. Maybe it would help to use something faster?

Nobody can diagnose the problem without seeing your code. Once you show us a minimal complete reproduction then it will be straightforward to explain the behaviour of your program.

Like so many projects people post on github these days, the README seems to cover everything EXCEPT: "What IS glad?" People are just supposed to know this stuff, or search around the internet to find out. Or, you don't care if anybody who doesn't already know what it is learns about it from your post -- IOW, you're basically just "preaching to a choir" and everybody else can just mosey along. Sorry, I'm just exhausted dealing with lack of comments and descriptions of stuff the previous people who maintained the code apparently just kept in their heads. When I ask for help or explanations, I'm told, "Just fire up the debugger and step through the code..."

If a mutex is not working you are probably doing something wrong.

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.

There's an underlying assumption in most communications that requires you know your audience. People who do not fall into that assumed group won't follow what you're saying. It's like listening to a bunch of "inside jokes". How fun is that when you're not privy to what's happening "inside"? If this were a PRIVATE library and this were a PRIVATE discussion between two people, that's fine. In that case, 100% of the participants know the background context. The "open source" part is irrelevant. The fact is, it's taking place in a PUBLIC LIBRARY. There can be hundreds of people looking at it from all around the world, at different times and with completely different backgrounds and perspectives. Adding a simple line at the top that answers the question "What is this about?" and maybe a link (as was offered above, independently of the content in the library) so people at least know what to look for would really be sufficient. As a participant, if you think it's a private discussion, you're going to think it's implied, so why bother stating the obvious? But everything in github is PUBLIC! In general, that's not a valid assumption for over 99% of the people who might view it other than the one or two others you're communicating with. Making a practice of adding a one-line description that answers the most obvious question everybody new to the page will have, "What is this about?", with maybe a link for more info, hardly requires a doctoral thesis. What it DOES ENABLE is MORE INCLUSION AND PARTICIPATION BY OTHERS, which is supposedly the whole goal of the Open Source movement. You don't need to write a damn book! It's a simple one-line description that answers the question, "What is this about?" and a link to learn more. Otherwise, you're simply having a private conversation in a public forum that very few other people are able to follow. And just to be clear, I'm not saying there's anything wrong with that! But the OP posted a message here ANNOUNCING this open-source project and when I went to look, the first question I had -- "What is this about?" -- was not addressed anywhere! All I saw was bits of a private conversation between two people who knew exactly what each other was talking about, and everybody else was relegated to evesdropping. The popular retort is, "Well Google is your friend!" Hey, this is YOUR announcement! Why do you then say to ask Google if I want more information? Why did you bother to make the announcement in the first place? It's like getting in front of a group of several hundred people and announcing, "Hey, we're having a party!" and someone asks "When?" and you say, "ask Google!" and you walk away. I don't know about you, but I'm not wasting another second thinking about it. And I'm not asking Google because adding the Who, Where, and When part is too much trouble for you to mention after the What. I'm guessing the OP posted that here because he wants people to look at the work, maybe see some value in it, perhaps get involved. But if it cannot answer the basic question, "What is this about?" then what's the point of making the announcement? Ask Google? Really? Why bother making the announcement? No, if you CHOOSE to make a public announcement about something, you owe it to your visitors to have at least one line at the beginning that answers the most obvious question every single one of them is going to have: WHAT IS THIS ABOUT? How much time do you expect others to spend trying to answer that most fundamental question before they just turn and walk away? This is a basic building block of how you include others in conversations or not. It happens at parties and social gatherings all the time -- you wander around, listening in on conversations here and there, to see if there's something interesting to follow or jump in on. If you're like most people, you wander around sampling lots of different conversations, and don't spend much time if you cannot get your bearings on what they're discussing. It's no different in public forums online.

That's a way to do. I always prefer using the events for connection and disconnection.

I suggest to first extract all strings used as key from the grid along with their index and move them in a single buffer (Avoid numerous memory allocation), keeping the pointers into an array (of pointers). Then use a fast algorithm to sort the array of pointers by dereferencing the pointers to access the strings for comparison. Moving only the pointers is the key to fast operation. Once the array is sorted, use the index part to move the grid rows. This will be efficient for a large grid because strings are moved only once to create the array of pointers

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.

It is also known as "stupid sort". Best algorithm name ever.

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;

I have tried several components over many years, and the only one that has proved simple and reliable under all circumstances is JclAppinst.pas in the JCL. Many options if you need them but for simply checking that there there is only one instance you need only two lines of code added to your DPR: one supplying a GUID and then a call to JclAppInstances.CheckSingleInstance.

Much annoying. Very bug. 😛 https://quality.embarcadero.com/browse/RSP-30576