Lars Fosdal

It depends on the parser. Sometimes it can be just "can this string be recognized as a valid representation of a value?", other times you could parse a generated artifact, or a predefined artifact.

It would be natural that the test cases also contain negative tests - i.e. stuff that is supposed to fail. Only testing happy path = recipe for disaster. You want to know that if you get garbage in, at least your code can recognize that it is garbage, report the problem, and move on.

Dictionary and anonymous methods. Link the method to the keyword. Look up via the keyword and execute the code.

The X is for eXcellent 🙂 Edit: On the serious side, we chose DUnitX because the use of attributes allowed us to do more testing with less code. Also, it is super easy to integrate with Continua CI. Many of the tests are there to verify that we f.x. have working FromString/ToString methods for all our enumerated types, validation of algorithms, and such - but a lot of the tests are actually closer to integration tests than to unit tests. F.x. there are a large number of tests that do CRUD testing for our database objects. We should add more tests, to be honest - but so much to do, so little time, so the Pareto rule, rules.

All our apps, including our services, are self-upgrading/restarting. It has worked flawlessly for years. We set up the relaunch to be executed in the finalize statement of our upgrader unit, so we know the application has actually exited when we relaunch.

I just installed FMXLinux 1.68 which required a restart. No lingering BDS.exes for me. I keep Process Hacker running most of the time, and I can't recall seeing multiple BDS processes after a GetIt install.

How about testing for 'FOR SELECT' first? Then again - what if there are two spaces between FOR and SELECT ? If you want to "trim" all spaces, you still have to avoid doing so inside string literals. Parsing can be complicated. I hope you don't plan to expose this to users, because they could wreak havoc on your database.

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.