Leaderboard

I don't really understand this. I always write the try/finally immediately after the construction, and always bang the Free in immediately. Then I fill out the body. It's just a habit that you form so that you don't make such mistakes. And honestly, this is never one that is hard to debug because you just have a leak. And presumably you use leak detection tools so that you'd always find them immediately. I don't really understand this scenario either. If you have a reference to something that may or may not exist, you would test Assigned() before using it. And when you were finished, you'd set the reference back to nil once you'd destroyed it. The scenario that is tricky is when you have multiple references to an object.

Do you really want your code to be generated based on fuzzy statistics? How do you even verify the correctness of the results? I'd like mine to be based on strict patterns and known deterministic properties of those patterns. I think trying to solve these problems with AI is a bit like when some companies moves their stuff to the cloud; They don't understand how it works or know what is going on but now it's somebody else's problem.

It's odd you say that, but I never have to debug issues like this. There are two simple patterns for lifetime and they are so ingrained, nobody ever makes a mistake in my team.

Consequent use of interface references (with rerf counting for lifetime control) instead of object references avoids that problem completely.

If you really need to have multiple references to an object, then use interfaces and ARC to manage lifetime. If not, then you will have to invent similar mechanism for managing the lifetime.

Ah, yes I see your point. Interesting. A bit labor intensive though, having to vet all the different solutions. Personally, I use another approach 🙂

That is not what I intended to say. I was wondering if someone had tried to apply LLM for finding even better patterns for optimization than those that are currently implemented. Naturally, such improved patterns would be made into new deterministic rules in the compiler after being properly vetted. I agree that todays AI output has to be treated as indicative at best, and as bullshit at worst.

Could be related to String with non-ASCII characters directly attached to a #xx or #$xx literal corrupts the final string Current workaround is to use a + operator to concatenate the parts.

Perhaps this did the trick: https://en.delphipraxis.net/topic/11151-delphi-and-use-only-memory-safe-languages/?page=5&tab=comments#comment-90366

The quantizer and dithering in GifImg isn't tied the GIF format; It's completely independent. It is limited to max 256 colors though (AFAIR). I don't think you should start by inventing your own quantization algorithm. Start with one of the known ones so you at least can learn the problem space first (and avoid the usual mistakes). Here's a few links to get you started: RgbQuant.js: color quantization lib https://github.com/leeoniya/RgbQuant.js nQuantCpp: top 6 color quantization algorithms https://github.com/mcychan/nQuantCpp/ Top 3 color quantization algorithms (same author as above, older article) https://www.blackslate.io/articles/color-quantization-algorithm A good one to start with is Xialoin Wu's algorithm (https://www.ece.mcmaster.ca/~xwu/cq.c) It performs well, with good results, and the algorithm is fairly simple. I think that is also the one I will implement next (when I get time; there's far to many interesting projects to work on). This one is also a good read: https://bottosson.github.io/posts/colorwrong/ I will see if I can find time to wrap some code up for you. It's a pluggable framework so you can extend it with new quantization, dithering, and color lookup algorithms, and color spaces. As far as I remember there are no dependencies on Graphics32. Here it is in action (using Linear RGB color space AFAIR):

GPT and other AI services aren't capable of thinking. They only "know" what has been trained or other resources to use as a reference (ie code online that a human originally wrote). If I wrote some assembly code that I posted online somewhere and GPT used my code as a reference point, any code that GPT generated would blow big time.

Hasn't this already been demonstrated with "smart pointers"?

Yeah, you are wrong. Such people exist. I am one. Not necessarily. No reason why pointer arithmetic should be faster than, for example, plain indexing of arrays. Again, good compilers are often better than humans. I don't think pointers are used in the RTL especially more than other libraries, and I don't think pointers are used there fore for optimisation and performance. As far as this whole memory safety debate goes, you can't exclude the RTL from it. That code executes in the code that is subject to attack.

I am afraid so, even if it probably is somewhat outdated by now, in the light of new CPUs.

Hackers Delight?

Dang, watching this led me to buy yet another book 🤖

Oy, that's a really open-ended subject. The RAD approach (using data-aware controls and connection/query components you create and configure at design-time) gets you results (= working application) fast but it tends to get messy fast as well, with business logic mixed into form and data moduls, poor reuse of code (unless you plan well ahead). This approach makes proper separation of application layers harder and is excellent at producing apps that are a nightmare to maintain and document. Code can be written to be self-documenting and serve as source for project documentation as well, but how do you deal with all the stuff set at designtime and scattered across dozens or even hundreds of dfm files? In my opinion RAD is workable for smaller projects with a few database tables and a few forms as well. For anything more complex and expected to have a lifetime of many years with frequent updates it pays to use a proper layered approach (e.g. model-view-controller or similar), with a object-relational mapper (ORM) as interface to the database and a client UI that works with data objects instead of directly talking to database tables, queries, or stored procedures. All the FireDac stuff would be hidden inside the ORM. Unfortunately Delphi does not come with an ORM, but there are some 3rd-party offerings in that area, including open-source projects like MORMOT. The learning curve can be steep if you have never dealt with such a design before, but it is worth it IMO. I wrote my own ORM for a larger project at work 20 years ago, took about half a year (part time, programming was not my main task) since nothing suitable was available at that time. It has served me well and some of the programs are still in some use... As for partitioning the app into modules that can be maintained independently: that is what packages are for, but it is not as straightforward as one would hope. It's DLL hell in disguise and you have to invest some serious though into how you partition your application. Packages are all or nothing, every unit used can only be contained in one single package. All other units requiring such a unit have to get it from the (shared) package, so you have to deploy not only your own packages but also all used RTL and VCL (or FMX) and 3rd-party packages. As long as you do not change anything in the interface part of a packaged unit you can replace the build package in the production app with an updated package. If you change an interface you have to rebuild all packages using the modified one, plus the host app. Since forms etc. are declared in a unit interface that severely limits what you can change in such a form unit without major hassle. Note that this applies to units you want to use from other packages directly. It does not apply to units only used internally by a package. So it is possible to achieve a better isolation of modules if the only exposed part is a factory function for an interface the host app then uses to talk to the internal stuff of the package. In this scenario you can get away with only building with the core RTL and VCL packages and one shared package declaring the interface types used, and actually you can use DLLs (build with packages) instead of full-fledged packages. But this can still degenerate into a maintenance nightmare if you are nor careful...

The Zeos Team is proud to announce the availability of Zeos 8.0.0 as a stable release. This is the newest stable version of Zeos. It deprecates Zeos 7.2, and any previous version of Zeos. We urge all people still using older versions of Zeos to upgrade. If you have any problems with Zeos 8.0, please get in contact with us on the forums or on the bugtracker. The most outstanding changes in Zeos 8.0 are Support for Delphi NextGen compilers to support Android, iOS and Mac OS X Two new bridge drivers for OleDB and ODBC A new driver that uses the Firebird interface based API for accessing Firebird versions 2.5 and above A special proxy server and an according driver that can be used to access any Zeos supported database using SOAP over HTTP(S) from (mobile) clients. Propper support for numeic and decimal fields by using TBCDField and TFMTBCDField Nested transactions using savepoints Two new components: TZTransaction and TZMemTable better overall performance and smaller memory footprint Besides these improvements Zeos has seen a ton of other additions and improvements. For an overview of the changes in Zeos 8.0 see the release notes. To download, the new version of Zeos please use this link.

Reproduced in Delphi 12.1 here - turned on hints and see the same thing. The hint window has broken positioning - the bottom of the hint window is where the top should be. Usually run with scale 125%, switched to 100% and the improper positioning is still there and looks the same. In addition the hint window should be moved further away or the drop shadow removed as it will obscure text.

That's what I am going to do. Before doing that, I always ask other people whether they can confirm the issue. So much wasted time because the Embarcadero developers obviously didn't care.

Nice list, thanks 👍 You missed these few, probably: https://rosettacode.org/wiki/Parse_command-line_arguments#Delphi https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.SysUtils.FindCmdLineSwitch https://github.com/exilon/QuickLib/blob/d085aa28e5fd65bae766446f5355ec4dc80fae9e/Quick.Commons.pas#L1292 https://wiert.me/2015/05/13/on-the-delphi-tcommandparser-class-for-parsing-command-lines-and-arguments-via-suggestions-for-how-to-define-command-line-parameters-stack-overflow/ https://github.com/jackdp/JPLib/blob/master/Base/JPL.CmdLineParser.pas https://github.com/tokibito/delphi-argparse

Before anyone gets too upset, my perspective is based on dealing with legacy code you have come into. There are numerous advantages to encapsulating global variables. Not only do you establish a measure of access control, but if you expose them as properties with getters and setters, you can easily set breakpoints to discover points of interaction. Equally, you could introduce logging. But even without those benefits, you will be altering the calling code to reference MyGlobals.SomeState, rather than simply SomeState. Once you have accomplished that tedious task, it is also a simple matter to search for all such references by searching on MyGlobals. Other benefits will become apparent as you work through things.

I came across this interesting comparison yesterday between Goroutines and C# async/await (part of a group of articles comparing the languages). https://alexyakunin.medium.com/go-vs-c-part-1-goroutines-vs-async-await-ac909c651c11 Well worth a read. TLDR - Goroutines are faster, easier to use than async await (async everywhere is a pain), stack sizes matter and Go runs out of memory long before C# - in the benchmarks at least.

People like Gor would call the majority of the Delphi RTL and alike "not an appropriate solution for writing scalable concurrent software" so we have to be a bit reasonable when putting this statement into context.

Well, you have been given some examples, but my question is: WHY do you want to know this? The whole point of polymorphism is that in the base class you do not need to know whether a descendant has overriden the method or not. In fact the base class does not even know whether there are descendents of it, and neither should it care. If you think you need to know whether a method has been overridden in descendents something is wrong with your class design, IMO.