Anders Melander

How?

Hmmm. Could it be that you have two different versions of the Graphics32 run-time package in your path? Using the debugger, are you able to step into the call to Image321->Bitmap->LoadFromFile ?

Place a breakpoint on that line and inspect the value of Image321 and Image321->Bitmap. They should both be non-nil. If Image321 is nil then the control wasn't instantiated when the form was created. Since you appear to be using run-time packages then that will probably have something to do with it. I still need the call stack when the exception is raised. If C++ Builder is like Delphi then you can select all the lines of the IDE's Call Stack window and copy them with Ctrl+Ins (or Ctrl+C).

I don't use C++ Builder so probably not. Do you get errors at design-time or only at run-time? If you get run-time errors then what's the call stack when the exception occurs?

Stop being lazy. Properties are not there to make your job easier or make you code faster. They're there to make your code better. They enable you to better express the API of your code by encapsulating and hiding the internals of objects. It's true that they're just syntactic sugar, if we disregard the design time aspect then everything a property can do can also be done with functions and procedure, but so what? That doesn't take anything away from the cases where properties have justification.

That really depends on what you're doing. If you at least start by finding out what's in the SDK (you can probably do that online) then you will know it's there when the need arises.

If you're exclusively a high level application developer then you probably don't need the SDK, but if you plan to do anything close to the OS then you should install and familiarize yourself with the development tools that comes with the OS. Imagine if your Lamborghini mechanic didn't have the official Lamborghini tools... Would you let him/her mess with your Countach?

Unless you actually understand what and why the Windows thread scheduler does it's generally better to leave that stuff alone. It's a classic newbie mistake to think that one can make a thread run faster/better by raising its priority. https://blog.codinghorror.com/thread-priorities-are-evil/

Yeah. It's good to get a reminder of this problem once in a while since it probably won't get fixed.

Resolved. You can download the new version here: http://melander.dk/download/amTranslationManagerInstall-1.3.8055.21506.exe

Reproduced. https://bitbucket.org/anders_melander/better-translation-manager/issues/24 Reproduced. https://bitbucket.org/anders_melander/better-translation-manager/issues/23

I found this in my usenet archives about the evaluation order:

The algorithms in that link are okay. It's your implementation of them that's a problem. Just get rid of all the HSL stuff and you should be fine. The formula you call "luminosity" is using the Rec 709 coefficients for "luminance" used in HDTV video. I recommend you read these two sections: https://en.wikipedia.org/wiki/HSL_and_HSV#Lightness https://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages

You haven't shown how you're handling the bitmap returned from ConvertToGrayscale but besides that your exception handling is wrong. Use this pattern instead: begin Source := TBitmap.Create; try Result := TBitmap.Create(...); try ... except Result.Free; Result := nil; end; finally Source.Free; end; end; Apart from that your grayscale algorithm is horribly inefficient (and wrong). Why use HSLToRGB when you know that for grayscale R=G=B and why use RGBToHSL when you already operate directly on the RGB values...?

https://web.archive.org/web/20000620192211/http://www.totalqa.com/products/qtime.asp

I'm pretty sure it was the other way round. AFAIK it's still written in Delphi.

Aren't you using map2pdb with VTune?

It works fine but it's nowhere near as comprehensive as VTune. One advantage is that it works on both AMD and Intel platforms. I have AMD uProf version 3.2.449 installed and that works fine on my system.

And you're looking at the main thread? This is probably the COM apartment threading in play. If so, one of the other threads will most likely be running code in MSXML.

I'm on Windows 7 (on my main dev system) so no 😕 The latest version that works on Windows 7 is VTune Amplifier 2019. I guess I should give it a spin on my laptop (Windows 10 something something) instead before I judge it. That said, the version of msdia140.dll (which is Microsoft's interface to the pdb file) I'm using is the latest one and as far as I can see msdia140.dll is the bottleneck. Of course it might be that my version of VTune isn't using it correctly. I was just considering writing a replacement for msdia140.dll but it would be great if I don't have to go down that rabbit hole.

I dunno. Don't you find VTune's poor performance to be a problem? Personally I either need to be really desperate before I resort to VTune or I must have a very good idea about what I'm looking for (like, I need *this* exact function to be faster but I don't exactly know how to make it so). I have had successes with VTune in cases where I needed to optimize some SSE code but that's about it. On the project I'm working on right now (pure Pascal) it takes VTune over an hour to load the pdb file and so far it hasn't told me anything I didn't already know (from pausing in the debugger).

François, for something like this you probably don't need a profiler at all. Especially not an instrumenting profiler (more on that later). What I always do, before resorting to profilers, is to simply run the code in the IDE and pause the execution in the debugger when the time critical code is executing. Statistics dictate that the current call stack will show you exactly where your hot spot is. Repeat a few times to verify. Basically this is the same approach a sampling profiler uses. The problem with instrumenting profilers is that the overhead of the instrumentation code affect the timing results so much that you can't really rely on it. They're great at determining call graphs and identifying the relative call frequency of different methods, but in my experience you can't use the timing for much.

It's not "clever". If real problems gets too hard to solve just invent some easy ones.

You misspelled Obfuscation.

Very nice. That actually makes it very clear what the problem is - but isn't there something missing? You've declared Child but not actually referenced it anywhere. Maybe you meant to write: Y<T: Child> = class(X<T>) ...