Lars Fosdal

I haven't seen a GetIt induced restart fail yet - but now I am suddenly expecting it to fail...

It has been too long since the last "Clan of Kahn" "Sons of Kahn" post 🙂

The Register is definitively one of the more interesting and accurate sites on all things IT these days. Very little fluff and rumors. Edit: Here is the "wrong thing" article: https://www.theregister.com/2021/10/22/microsoft_net_hot_reload_visual_studio/ Also, the BOFH posts usually are good for a laugh and a nod.

The "wrong thing" was to first introduce it to the open source libs, then pull it back - instead of keeping it private, and adding it to the open source lib later.

Most of my code involves a multitude of objects in various containers and their interactions. I've never dragged the exe pointer or set the execution point during debugging, as it would most likely create conflicting data.

It would be a nice feature, but it is pretty unlikely to ever happen. The .NET platform is very, very different from Win32 on Intel. The ancient Borland Pascal DOS debugger had backstep, where you could single-step backwards from a breakpoint. Also not quite as easy in the multithreaded, asynchronous world of Windows.

They could have made the "Patch available" a little more prominent, as well as putting it in the "New in GetIt" and "Promoted in GetIt" panes.

If the values are in an int array, would it be possible to use a different kind of operation than a loop + comparison, f.x. the SIMD instructions?

Mostly, yes.

It's a nightmare when you have 350+ frames and forms that may need a touch-up, and you still can't be sure they won't be f'd up if two people with different DPI settings edit them.

@pyscripter - A char in a Unicode string is a word, not a byte. The old set operator is useless for Scandinavian chars, as well as German umlauts, etc., unless you convert to ANSI - and that is not desirable.

That is what I meant, and you are right - how could it...

Does CharInSet support multi-byte Unicode characters?

I see minimized / background UAC dialogs from time to time, and it is annoying as heck. I can't really see a pattern, though - and I can't say 100% for sure, but I don't think our own app that requires elevation have behaved like this for me. Mostly, it seems to be installers, or apps launched by installers?

Danny Thorpe was one of the pillars that Delphi is founded on. A giant among giants. His legacy is solid and we will remember him with love and respect, and send our condolences to his family.

We have multiple sites that are development sites, test/qa sites or production sites. Each site can have one of three build tracks: Development, Pilot or Live. Update model can be automatic or manual. The config is kept in a database. The Continua CI will push new builds automatically to the dev/test/qa sites that have been configured as automatic, only if the automated unit tests was a success, and uses the same PowerShell scripts that are used when pushing out a new version manually. This saves a lot of time during test/qa, when fixes are more frequent than for a live site. The manual part consists of using a UI to select which site(s) that will get which executable(s), and db schema updates from the relevant build track. Scripting based on a stored config minimizes the chance of pushing the wrong version to the wrong site.

I just discovered a very weird bug. We have a build server running FinalBuilder og Continua CI, and the build process executes a DUnit test app. This week, two of the 600+ tests failed with the error: So, we thought- Developer error - perhaps we have a mismatch between the Delphi code stuffing parameters and the parameters of the stored procedure? Nope - that was not the reason. So we checked the source code, deleted all logs, deleted all .exe files, delete all 13k .dcu files that Continua had cached, and ran it again. Still the same error. Recompiled the DB stored proc. Rebooted the app server. Rebooted the DB server. Still the same error. I ran the app manually from a PowerShell prompt, and to my surprise, it did NOT report an error. The unit test used the DUnitX stage action in Continua - and invoked a .cmd file that just launched the test app with some command line params. So - I modified the action to be a .ps1 script and changed the action to run the .ps1 script instead of the .cmd script- and No Errors. I then modified the DUnitX action to directly invoke the exe and pass the params, and No Errors. So - why does the same 32-bit application apparently use different ODBC drivers when run from a cmd prompt, vs run from a powershell prompt?

Ref . https://newbedev.com/is-there-any-difference-between-a-guid-and-a-uuid it seems that all UUIDs can be GUIDs, but not the opposite.

I'd go for the second alternative, but I'd do it as a function returning a boolean for found/not found and an optional boolean flag on whether to raise an exception or not.

I "need" one too. If it can't run Windows, I'd still be able to make music with it. But - it will run the Windows 11 for ARM preview... https://www.parallels.com/blogs/windows-11-tpm/

Does the program itself append to its own .exe ? Antivirus software may take offence.

Overpriced and underfeatured. Stay away.

Considering TShiftState is declared in System.Classes in both 10.4.2 and 11, that is strange. Also, TMouseButton is declared in System.UITypes in both versions.

How much semi-circular unit references do you guys have?

Servers down for maintenance or otherwise unreachable? Cleaning lady pulled the plug? Same old, same old...