Anders Melander

Do you mean this one?: https://github.com/project-jedi/jcl/blob/master/jcl/source/common/JclMath.pas If the file is not in the Github repo then I think it's safe to assume it's unmaintained (or even more unmaintained than the files in the repo).

You don't need to uninstall it; Just disable it for the project (i.e. uncheck the "enable madExcept" checkbox). It doesn't do anything and there's no overhead when it isn't enabled for the project. A significant overhead is expected, both in terms of performance and memory usage, when resource tracking is enabled and it's even worse when buffer overrun detection is enabled. So you should only enable these two features during debug, either to track down a suspected leak/overwrite or to occasionally verify that there aren't any once you get there. The core functionality, which is exception handling/stack tracing, doesn't cause any performance overhead. Those are almost certainly errors in your code. madExcept should produce a call stack that points to the origin of the exception. If it doesn't (i.e. the exception is only visible in the debugger) then it's because the code is actively swallowing the exception. A practice that unfortunately is quite common in legacy code: try ...lots and lots of code here... except // I can't figure out why the code above fails occasionally // so let's just pretend there's no problem :-/ end; No. New version are backward compatible; You don't need to install an older version.

The suitability of TMultiReadExclusiveWriteSynchronizer depends on how you use it and what your needs are and only you know the answer to that. There's a more lightweight and faster alternative available in the RTL of recent Delphi versions. Google, or the help, will find the name for you. TMultiReadExclusiveWriteSynchronizer got broken when Danny Thorpe rewrote it for D6. I believe it was fixed in D7. Before the rewrite it supported lock promotion which opened up for deadlocks in some usage patterns - not because it was buggy but because people didn't know what they were doing.

Search broken again? https://en.delphipraxis.net/search/?q=TMultiReadExclusiveWriteSynchronizer https://www.google.com/search?q=TMultiReadExclusiveWriteSynchronizer

I can relate to that. I've used a Gnome Sort from time to time when performance wasn't critical. Simply because it looks nice. var i := 0; while (i < High(Values)) do if (i = 0) or (Values[i] >= Values[i-1]) then begin Inc(i); end else begin Swap(Values[i], Values[i-1]); Dec(i); end;

Nicely avoids the problem of integrating with the IDE help system - by not integrating with the IDE help system 🙂 Also contains the only instance of a cocktail shaker bubble sort that I've seen used in practice. "Outdated help is better than no help" - apparently.

I have an IDE wizard lying around somewhere on my HD that AFAIR will can redirect the help request to an URL if the other help providers fail to resolve it. It was made for Delphi 5 or 6 (so it's 20-25 years old) and from back when the MSDN help was distributed on CDs. I'll see if I can locate it and get it to compile with a newer Delphi... Yup it works; I just had to update the default search URL. However, for some reason it only works if I search on a keyword the standard help doesn't resolve. Otherwise the IDE help lookup fails with an exception. I can post the source if anyone wants to have a go at it.

Give madExcept a try again; It's much easier.

I have migrated countless JIRA instances from server to cloud and it has never been "a significant effort". The only problem I can think of is if they had modified their server so much that it couldn't be migrated automatically. Indeed. Normally this wouldn't be that big of an issue as lack of features and bug are to be expected, this being a relatively new product. But the problem with Atlassian is that the suckage only ever increases. I think they hate their users. Eventually Github will eat their lunch.

A single item for me so YMMV on the "essentialness".

A google search would have told you that. Or the IDE insight: or the help... Command line. Replace <map-filename> with the name of your map file. Run VTune, configure your project there, launch the application from within VTune. But before you do anything, please read some VTune documentation. You don't need to post anything to get notifications. Just click the Following dropdown.

I think not...

source\Property Editors\FmxStyleLookup.pas

Maybe ask yourself that question from time to time. These threads aren't really improving the SNR here.

Let me look it up in the help for you...

I think you missed my point: Backward compatibility. While we can agree on the pitfalls of the current declarations and on how the types could have been declared, I have to take the users' existing code into account before I change something that have worked for over 20 years. Again you missed the point. It was just an example of how changing a publicly declared array type can break user code.

I started to make this change for all the publicly declared array[0..0] types (there's more than a few) but then I realized that this will probably break existing code. For example if a user of Graphics32 has the following declaration: type TMyStuff = record FirstPixel: TColor32; TheRestOfThePixels: TColor32Array; end; PMyStuff = ^TMyStuff; Then the compiler will refuse to compile it because the size of the structure exceeds the max allowed: Given that the [0..0] declaration is a very common technique and the problem here really is that range checking has been enabled for a corpus of code that wasn't written with that in mind (and I'm speaking of *Lemmix here) I think I'll leave it be. My recommendation to get around this for now is to search for PColor32Array and then surround the code with {$RANGECHECKS OFF}...{$RANGECHECKS ON} - or simply declare a new type and cast to it as @Kas Ob. has suggested. Give it a neutral name like TPixelArray/PPixelArray or something like that though; It's not really a hack.

Excuse me but why the hell would you ask ChatGPT about that? It knows nothing about coding; It's a linguistic AI. Also, no amount of googling will help you solve that particular problem. First you need to understand what the error means (what is a range check error), then you must understand what the code does. Pick the code apart and comment it along the way. Run it in the debugger, examine the values passed to the method, validate that they are within the expected bounds, etc. etc. Continue until you completely understand what is going on.

It sounds like you haven't realized why the overflow occurs. That would have been step 1; Understand the problem before you try to fix it. The problem is that GetTickCount wraps around every 49.7 days. The documentation for GetTickCount would have told you that. If you reboot Windows the problem "goes away" since GetTickCount will start from zero again. When GetTickCount wraps around the start time becomes "later" than the current time so the delta time becomes negative. Since we are operating on Cardinals (an unsigned type) you get an integer overflow error. The solution is one of the following: Use another algorithm Use GetTickCount64 and Int64 Use signed integers and cast the cardinal result to integer. Disable overflow checks locally for that particular code. In this particular case I would probably go for 3 or 4. It should be noted that this isn't really a bug. It only turned into a bug when you enabled overflow checks. You could have solved this problem on your own if you wanted to. It wasn't a difficult one. It might seem easier to ask somebody else for the solution to a problem, and sure it might even solve that particular problem, but what it doesn't do is give you the ability to solve future problems on your own. How do you suppose the "experienced programmers" acquired their knowledge? They didn't get it by asking for solutions. They got it by analyzing, doing research and experimenting.

That's a bug. Right now XE2 and later should be supported. I will probably soon change that to XE7 or something in that neighborhood - so a support window of approximately 10 years. The inline vars is something I keep introducing by accident simply because I've gotten so used to them that I don't even consciously notice when I use them. I'm not aware of any compatibility problems with the use of generics. I remember that generics was bugged to various degree in some of the early versions but I'm not going to work around that if that's the problem. I'm also not aware of any problems with Delphi 10; I'm using D10.3, D11.2, and D12 myself.

That's a classic - with an easy fix. Try Googling it and see if you can't fix it yourself; You'll learn more from that.

No and it isn't needed in this particular case. How about you have a peek at the code before you continue?

Okay but lack of imagination isn't a reason to eliminate it 🙂 The use of Sleep in OnIdle is definitely a problem but that doesn't mean that all use of Sleep in the main thread is bad. For example, the fade in/out code is a time limited (sub-second duration) loop containing a Sleep. While the fade in/out is in progress nothing else happens and nothing else should happen. It would be silly to complicate this with threads or timers.

It would probably be best if you had looked at the code before making such a broad recommendation... I haven't looked through all the code but I'm certain there at least some cases where it would make no sense to replace Sleep. I know because I wrote that code.