Leaderboard

If that's aimed my way, I'll gladly take it. I had more days than I can count starting at 8am and leaving work the next afternoon without sleep due to some crisis. CTO for 22 years at a highly active software company where we were always under-staffed, over-promised, and working on a shoe string budget (privately held, one man owner for much of that time until I became a minority owner.) I don't miss it, much. (My wife certainly doesn't.) The cool thing - we had 11 Delphi developers at one point and I was trying to hire another when the VC people showed up and bought us out. But even with that many developers I left the place with 5,000 open tickets on the tech side of the house, after spending a solid year concentrating on getting it down from a much higher number. (My custom built trouble-ticket system had 500,000+ tickets in its mid-2004 to late 2018 history.) But my history suggests - take the walks. There's always a crisis. And if you want some useless code tested for fun, send it my way. I may just do it.

C# compilation is pretty darn fast. Delphi compilation for 64 bit on Windows is not exactly fast. I'm sure that a first pass to define record type layouts followed by a second pass for everything else would not be costly. This isn't going to be about compilation speedy. It's about the pain of refactoring the front end.

I wish I had that amount of spare time. I would enjoy more walks in the sun. *sigh*

Yes, because the reference to tPolar2D is only inside tPoint2D, which still has to be declared after tPolar2D. The benefit of the operators is the ease of conversion by assignment. This is the (corrected) declaration with some example assignments (TBD: calculations): type tPolar2D = record Radius: Double; azimuth: Double; end; type tPoint2D = record x: Double; y: Double; public class operator Implicit(A: tPoint2D): tPolar2d; overload; class operator Implicit(A: tPolar2D): tPoint2D; overload; end; class operator tPoint2D.Implicit(A: tPoint2D): tPolar2d; begin Result.Radius := ... Result.azimuth := ... end; class operator tPoint2D.Implicit(A: tPolar2D): tPoint2D; begin Result.x := ... Result.y := ... end; var cart: tPoint2D; pol: tPolar2D; begin cart := pol; pol := cart; end.

@Darian Millerhas published a very nice article about the state of TThreadedQueue and TMonitor in Delphi. He has also published at Github a stress test that shows how TThreadQueue still fails under stress. I have played with his stress test and concluded that the problem is almost certainly in TMonitor. TMonitor implements a lock-free stack to recycle events created with the CreateEvent function. The relevant code in SysUtils is var EventCache: PEventItemHolder; EventItemHolders: PEventItemHolder; procedure Push(var Stack: PEventItemHolder; EventItem: PEventItemHolder); var LStack: PEventItemHolder; begin repeat LStack := Stack; EventItem.Next := LStack; until AtomicCmpExchange(Pointer(Stack), EventItem, LStack) = LStack; end; function Pop(var Stack: PEventItemHolder): PEventItemHolder; begin repeat Result := Stack; if Result = nil then Exit; until AtomicCmpExchange(Pointer(Stack), Result.Next, Result) = Result; end; This lock-free stack is used by NewWaitObj and FreeWaitObj which are part of the Monitor support protocol and used by TMonitor. This works reasonably well, but under stress it fails. The reason it fails is known as the ABA problem and is discussed in a similar context by a series of excellent blog posts by @Primož Gabrijelčič: blog post 1, blog post 2, blog post 3. His OmniThreadLibrary contains the following routine that he uses to deal with this problem. /either 8-byte or 16-byte CAS, depending on the platform; destination must be propely aligned (8- or 16-byte) function CAS(const oldData: pointer; oldReference: NativeInt; newData: pointer; newReference: NativeInt; var destination): boolean; asm {$IFNDEF CPUX64} push edi push ebx mov ebx, newData mov ecx, newReference mov edi, destination lock cmpxchg8b qword ptr [edi] pop ebx pop edi {$ELSE CPUX64} .noframe push rbx //rsp := rsp - 8 ! mov rax, oldData mov rbx, newData mov rcx, newReference mov r8, [destination + 8] //+8 with respect to .noframe lock cmpxchg16b [r8] pop rbx {$ENDIF CPUX64} setz al end; { CAS } I have tried to use this function to provide a solution for TMonitor similar to the one in OmniThreadLibrary. (see attached iaStressTest.TThreadedQueue.PopItem that can be used with the original stress test). Whilst still not perfect it helps a lot in 32 bits with say up to 100 threads. However it crashes in 64bits and I do not know why. I am posting this here in case anyone with better knowledge than mine of assembler and thread programming can help with the challenge of fixing TMonitor. It would be nice to try and get a fix included in 10.4. And even if it is not included, it can be easily used as a patch in the same way as in the attached code. iaStressTest.TThreadedQueue.PopItem.pas

Not sure it's relevant but that x64 should use .PUSHNV to preserve rbx. And I think that also makes .NOFRAME incorrect.

The FMX bitmap that you save is a compressed bitmap. The VCL bitmap is a Windows bitmap, uncompressed.

It is not ideal, but it is not a problem, since the server will just ignore the 'Content-Type' request header in a GET request. 'application/x-www-webform-urlencoded' would not be a valid media type for an 'Accept' request header.

There are numerous examples and tutorials online for how to work with webcams using the Win32 API. That information is accessible via webcam APIs. You don't need VCL or FMX for that. Or, you could simply take the screenshot using an in-memory GDI bitmap, and then copy the raw pixel data from that bitmap into an FMX TBitmap as needed. Look at CreateCompatibleDC(), CreateCompatibleBitmap(), GetObject(), and TBitmap.Canvas.MapBitmap()/UnmapBitmap().

With over a million lines of code, it's an epic task to migrate. I can't believe that the increase in compiler time would be significant.

A second rate language that compiles fast as hell...at least for Windows. Now I wonder why 😉

The implementations can also vary between the different platforms. You cannot rely that one element is accessible in same way under all platforms. This is one of the biggest drawbacks of FMX styles IMHO.

Bloody annoying that this can't be done