Leaderboard

Hi everyone, more than twenty-one years ago, I started the German-language part of this forum and could not even begin to imagine what it would become. Thanks to the tireless support of many moderators as well as your thirst for knowledge and willingness to answer other people's questions, it has become a pillar of the virtual Delphi community - even far beyond the German-speaking world. Since 2018, this English-language part of the forum has also been available, with considerable support from Lars. With an online presence of this size comes the obligation to take proper care of it. I have always been very happy to do this, but over twenty-one years is a very long time and life and its priorities change. I can't help but realize that my daily/weekly time has become less available and the time has come for me to hand over the management of the forum to someone else. Thankfully, Thomas B. ("TBx") has agreed to take over the Delphi-PRAXiS and continue it in good hands - together with Lars, of course. You know Thomas as a longtime moderator of this forum and now he will take over my previous role. I myself will of course remain part of the Delphi community - not least because I continue to work a lot with Delphi in my job. I will also remain a part of this forum. Thank you all for over 21 great years!

I don't need any new features. I just need that the existing features work as intended. And there are many areas where existing features need to be made usable again (e.g. refactoring, code formatting, HighDPI). OK, one new feature would be nice: compiling for Raspberry Pi. But fixing the existing features needs to be done first.

The only self explanatory code is the trivial one. In other situations there is no such thing as self explanatory code, especially if it also needs to be performant and thread-safe. I have written tons of self explanatory code, for which now I don't know what was I smoking at the time. Sometimes, after a lot of digging I can remember why it was written like that and why it should stay that way, but mostly no. So I am not sure if it was just crappy code from the times I didn't know better, or there are valid reasons behind the awkward design choices.

https://firebirdsql.org/en/firebird-5-0/ New In Firebird 5.0 Summary of New Features Firebird 5.0 introduces many improvements without any changes in architecture or operation, the most important are: Parallel (multi-threaded) operation for backup/restore, sweep and index creation; Partial indices; SKIP LOCKED clause for SELECT WITH LOCK, UPDATE and DELETE statements; Inline minor ODS upgrade; Compiled statement cache; PSQL and SQL profiler; Support for WHEN NOT MATCHED BY SOURCE for MERGE statement; Support multiple rows for DML RETURNING; New built-in functions and packages; Denser record-level compression; Network support for scrollable cursors;

Today, almost all computer security relies on asymmetric cryptography and X.509 certificates as file or hardware modules. And the RSA algorithm is still used to sign the vast majority of those certificates. Even if there are better options (like ECC-256), RSA-2048 seems the actual standard, at least still allowed for a few years. So we added pure pascal RSA cryptography and X.509 certificates support in mORMot 2. Last but not least, we also added Hardware Security Modules support via the PKCS#11 standard. Until now, we were mostly relying on OpenSSL, but a native embedded solution would be smaller in code size, better for reducing dependencies, and easier to work with (especially for HSM). The main idea is to offer only safe algorithms and methods, so that you can write reliable software, even if you are no cryptographic expert. 😉 More information in our blog article about this almost unique features set in Delphi (and FPC): https://blog.synopse.info/?post/2023/12/09/Native-X.509-and-RSA-Support

Then please stop using it. Referring to a release by name instead of the version number which everybody recognizes, is just confusing, and everyone, Embarcadero in particular, should just stop doing it. It's pretty annoying having to Google it when someone refers to the name instead of the version number. I haven't bothered with the names since Ivory (see what I mean?). It's bad enough that the version number and build number haven't been in sync since marketing took over and made the numbers "hip" with D2xxx and later XE*

Please note: Only the 12.0 Athens GetIt server has been restored at this point in time (Feb. 7th). https://blogs.embarcadero.com/getit-update-additional-rad-studio-12-getit-packages-are-now-available/ https://blogs.embarcadero.com/rad-studio-12-athens-patch-1-available/ List of QP issues addressed in the patch: RSP-44063 Bug in MOD operation for Win64 Release configuration RSP-43656 [REGRESSION] Wrong codegen when passing empty open array to operator overload RSP-43568 Issue with TURI.Query Changed adding an equal sign to the URL ends with ?WSDL RSP-43551 When MDI form & Custom Styles are used together, the Process cannot be terminated. RSP-43547 New VisualManager feature causes crash in TCustomForm.WndProc() with Action=caFree RSP-43515 No event OnCameraDidFinishTaking for TTakePhotoFromCameraAction RSP-43494 Event OnValidate fails when the DBGrid is full - AGAIN! RSP-43463 JSON serialization error with scientific double notation RSP-43459 TEdit.FilterChar crash app on Android RSP-43422 NetHttpClient parsing URL parameters is incorrect RSP-43418 Wrong Delphi code optimization for integer div/mod RSP-43407 The Delphi compiler in RAD Studio 12 is no longer able to resolve standard types by their aliases when generates HPP files for a BPL package with components if the referenced types are declared in other units RSP-43383 Delphi 12 Android TEdit error RSP-43362 [iOS] TListView set search visible to True, the system will crash when clicking into the search area. RSP-43326 Blob reading is broken for 64-bit platforms in dbExpress RSP-43318 Incorrect ShortCut in TActionList RSP-43311 TSQLTimeStampOffset problems with Firebird 4 RSP-43299 TFlowLayout exception when all its elements are set to invisible RSP-43274 Arithmetic operations on record fields return incorrect results in certain cases if the "Optimization" compiler option is enabled RSP-43235 Structure view and Search for a method box no longer populated RSP-43007 Internal compiler error F2084 RSP-42860 FMX TListBox List Index Out OF Bounds RSP-42692 Ctrl-j - invoke template don’t work RSP-42682 TreeView crash RSP-42657 TTreeview crashes when scrolling in iOS RSP-42634 QBE component causes fatal IDE crash when removed from form RSP-42616 FMX: Key Handling different behavior in Delphi 12 RSP-42601 TURI with encoded Params are mangled when initialized

Since years, our Open Source mORMot framework offers several ways to work with any kind of runtime arrays/objects documents defined, e.g. via JSON, with a lot of features, and very high performance. Our TDocVariant custom variant type is a powerful way of working with such schema-less data, but it was found confusing by some users. So we developed a new set of interface definitions around it, to ease its usage, without sacrificing its power. We modelized them around Python Lists and Dictionaries, which is proven ground - with some extensions of course. Two one-liners may show how our mORMot library is quite unique in the forest/jungle of JSON libraries for Delphi (and FPC): +] assert(DocList('[{ab:1,cd:{ef:"two"}}]')[0].cd.ef = 'two'); assert(DocList('[{ab:1,cd:{ef:"two"}}]').First('ab<>0').cd.ef = 'two'); Yes, this code compiles and run on Delphi - even the antique Delphi 7. 😆 If you compare e.g. to how the standard JSON library works in the RTL, with all its per-node classes, you may find quite a difference! And there is no secret in regard to performance, that our JSON processing is fast. More info: https://blog.synopse.info/?post/2024/02/01/Easy-JSON-with-Delphi-and-FPC

We are pleased to announce the release of SonarDelphi v1.0.0. SonarDelphi is a free and open-source Delphi language plugin for the SonarQube code quality platform. GitHub: https://github.com/integrated-application-development/sonar-delphi Release: https://github.com/integrated-application-development/sonar-delphi/releases/tag/v1.0.0 Background If you're thinking "I've seen this before", you're probably right! SonarDelphi was originally open-sourced by Sabre Airline Solutions in 2012. It's bounced from maintainer to maintainer on GitHub (including Embarcadero). This project is a greatly improved version that has been actively developed (and extensively rewritten) by IntegraDev for the last 4 years. Features Powerful semantic analysis 120+ analysis rules Custom rules via templates or a programmatic java API Import NUnit test reports (compatible with DUnitX) Import test coverage reports (compatible with DelphiCodeCoverage) Feedback and contributions are welcome!

I think it could have been better worded - it's not that there are different levels of beta testers as such. It's more that the betas are released to a progressively wider audience. Early betas are generally released to a hand-picked cadre of users who either have a very specific situation which has a significant bearing on elements of the beta or are long-term 'advanced' users such as MVPs along with key tech partners. As the betas become more stable that audience is widened to more people who can receive value from a beta which while useful might still have potential instabilities which some could find challenging. This iterates with a wider and widening group until we begin to roll out to a broader general audience such as key accounts and known large projects, culminating in a general beta which goes out to people who have a maintenance subscription. There are different types of forums where the level of engagement is tempered to suit the type of beta customer. For example, MVPs often discuss things of a very esoteric technical nature with a more profoundly explicit type of conversation which, while entirely professional, might be more akin to a collection of colleagues and friends discussing a SNAFU in a particularly blunt way. These kinds of conversations don't sit so well among conversations with, perhaps, a 'regular' customer who is merely trying to see if the new beta solves an issue they have had with their project. I want to emphasize that this is not to bring about a kind of elitism and I try *really* hard for Embarcadero to be approachable by anyone - and I do get emails from all sorts of people, so I think that message is starting to be understood. I am here, I am listening. We are listening. The differentiation is more to ensure the level of interaction is appropriate for the expectations of the persons participating. MVPs are chosen for a multitude of reasons. Tech Partners are also the same - and some MVPs work for Tech Partners, but many Tech Partners do not have that kind of relationship with us. The same is true of customers who are neither MVPs or TPs and are trying out the beta thanks to their maintenance subscription. Administering the betas such as managing the beta keys and validating the requests to join the beta can be an intensely onerous experience which can place demands on internal staff at a time when they are already working close to capacity preparing for the eventual full release. Because of that, and in recognition that a valid premium or maintenance subscription should bring additional benefits such as access to betas, our current preference is not to simply push out a beta to one and all. We are also constrained by legalities such as getting sign-off on sub-licensed materials, EULAs, ensuring any OSS is properly credited and made available. That's not even an exhaustive list of what has to be done. We obviously want to ensure that as many people as practical can participate in the beta because the more that try it the more likely we are to shake out bugs or other issues before we release to GA - but we also do not have unlimited resources and we simply cannot currently let everyone on the planet join the beta. I know not everyone agrees. We are trying to listen more and more to your feedback, good or bad - we want to know the whole truth - because that's the best way to give you what you want and to make RAD Studio a product you love, and which genuinely adds value to your work. I promise you that everyone I work with is remarkably passionate about creating and sustaining a quality product that you will keep on choosing to create applications that help you achieve your goals and successes too. Ian.

I have created a unit, that is similar to String Interpolation. Of course real Interpolation would be a compiler feature. TStr('Hello, {0}! Today is {1:ddd}, it's {1:HH:mm} now.').Params(name, date); // Hello, Mark! Today is Wednesday, it's 19:40 now. Variables where automaticly detected and converted (automatic type inferrence via Generics), so no need for IntToStr, FloatToStrF... Here a short Description of the Format. It is similar to the Format Specifier of .Net. The Date Format is almost the same like in Delphi, but the other Specifier are different. but i think its a way better than the sprintf Convention that Delphi uses: Integer and Float where automaticly converted and formatted as needed: C for Currency (Number for Decimal Places) D for Integer (Number for prefixed Zeros) F for Double (Number for Decimal Places) Date can formatted with: dd = Day, MM=Month, yyyy=Year HH=Hour, mm=Minute, ss=Seconds there are further possibilities in the readme Readme: https://github.com/VoSs2o0o/NetFormat/blob/master/readme.md Code: https://github.com/VoSs2o0o/NetFormat/ Download: https://github.com/VoSs2o0o/NetFormat/releases Website in German with descriptive Content about the Code: https://www.cloud-9.de/entwicklung/delphi-besserer-format-befehl

Neat: https://www.idera.com/ppc/uptime-infrastructure-monitor/it-performance-monitoring

Maybe if they just built the web servers with Delphi and use the Delphi philosophy, they'd work

I have a client who wants to use DWScript to do structural load analysis of large models (thousands to millions of nodes). Since DWScript compiles to an AST (Abstract Syntax Tree) and then executes the objects in that tree, he was a bit concerned about performance. He had tried various other scripting systems and they were just too slow. So we did some benchmarking of a sequence of typical calculations in Delphi vs DWScript. As expected the Delphi compiled code was about 4 times faster than DWScript. The client thought that that was acceptable but I decided to try out the DWScript jitter anyway... As it turns out there might just be something to David's complaints about Delphi's math performance 😉 because with the jitter enabled DWScript was now more than twice as fast as the native Delphi code. Also, Delphi 64-bit was about 25% slower than 32-bit and 64-bit "optimized" was slower than "unoptimized". Not to take anything away from Eric Grange's amazing work on DWScript, but I would be embarrassed if my native code compiler was outperformed by a scripting system.

There have been a large number of new features and enhancements implemented in the P4D library recently . This discussion document provides an overview of these developments.

Even at work, where we have DevExpress and a number of other, chunky components installed the IDE loads our big legacy project up in less than 20 seconds. Add 10-15 more seconds of compiling and I am in debugging. Compare that with VS2019, which needs ~1min until IntelliSense kicks in, 1,5 min of compiling, 10 seconds of after-compilation-thinking and finally the project launches. I'm sure there are faster IDEs out there, but Delphi really isn't that bad from startup perspective.

Sounds like it were a religion...

I've never understood why anyone would use getit over the main source repo for open source projects

Due to the supply chain disturbances, we had a 5 month delivery wait for servers and parts for a while, so I can relate to delays. The problems here are: - Lack of proper communication. "No news. Next update at ..." is better than silence! - Insufficient contingency planning? - Insufficient backup and recovery plans? - No plan B? There are many capable cloud hosting services that doesn't take forever to spin up a pack of servers. The cost might be high, sure - but so is the cost of losing the trust of your customers.

Did you know that LEGO and Michelin are competitors? They both manufacture tires...

I don't know what to think after reading that article. Here are my comments on it: - the classic way of truncating the last 2 digits with div and mod 10 (or 100) does not involve a costly div or mod instruction on modern compilers (*cough* even Delphi 12 now does it - apart from the bugs that came with it) - I think C++ compilers would detect doing a div and a mod instruction and the code they emit would be further optimized so it does not require the "workaround" that the Delphi RTL uses by calculating the modulo by subtracting the div result times 100 from the original value. - the pseudo-code he shows for detecting the number of digits is correct but this is never what gets executed - and you either rewrite this into a few branches (as you can see in the RTL), a C++ compiler might unroll the loop or some other trickery is applied The DivBy100 function was introduced by me in RSP-36119 and I already notified them that DivBy100 can be removed in 12 because now it properly optimizes a div by 100 - however, that affects performance only by like 0.5% or so. As David correctly pointed out the real bottleneck is the heap allocation - and not only a single one when you just turn an integer into a string and display that one but when you concat strings and numbers the "classic" way because then it produces a ton of small temporary strings. That issue even exists when using TStringBuilder where one might think that this was built for optimization. If you look into some overloads of Append you will see that it naively calls into IntToStr and passes that down to the overload that takes string. This is completely insane as the conversion should be done directly in place into the internal buffer that TStringBuilder already uses instead of creating a temporary string, convert the integer into that one, pass that to Append to copy its content into the buffer. This will likely be my next contribution as part of my "Better RTL" series of JIRA entries.

I don't care that much about the IDE. It's the compiler and the language that matters more to me.

I have just released version 3.1.2 with the following changes since 3.0.1: map2pdb can now consume JEDI jdbg-files. A rare overflow bug in the MSF writer has been fixed. The map parser can now handle the slightly different files produced by beta versions of Delphi. The big change here is the ability to create pdb-files from jdbg-files. You can thank Stefan for being so annoying that I finally caved in and implemented it to get him to shut up about it. This means that it is now possible to profile Delphi's run-time packages by converting the jdbg-files bundled with Delphi and binding the produced pdb-files to the bpl-files. It's as easy as map2pdb -bind:rtl290.bpl rtl290.jdbg Because of a bug in the JEDI tool Embarcadero uses to convert from map to jdbg, some symbol names produced from Embarcadero's jdbg-files may look a bit strange. It's a minor issue that has no impact on the functionality and there's nothing I can do about it since the original map files aren't available. Get it while it's hot: https://bitbucket.org/anders_melander/map2pdb/downloads/ Here's an example from Stefan showing an application using the rtl290.bpl run-time package being profiled with VTune:

And makes your app a target for anti virus products. And what what gain? You end up with the same executable loaded in memory. I've never understood the point of this tool.

I have a project that I originally started for a presentation at the ADUG 2023 Symposium, which was on AI and ChatGPT. Since then I have continued to improve it and added more features to it. One of the goals of this project is to provide a library to Delphi Developers that enables them to easily use various AI models / engines that are currently available. Currently this is mostly done through calling various different REST API's that different companies provide, although another goal is to enable models to be used locally where practical. Features include: - Voice Recognition - Text to Speech - Image Generation - Face Detection - Large Language Models (LLM) like GPT. I have created various example programs that exercise the different API's as well. Today, OpenAI released some new features and API's. I have since added support for Dall-e-3 and the Text to Speech engine so far. To find out more have a look at https://github.com/geoffsmith82/Symposium2023