Darian Miller

If you run that build manually, does it work? Is your CI work being done on a machine that Delphi was installed on? (Or are files just copied to a build server?)

There are a few major reasons: - Peganza is the number one expert at static code analysis of Delphi code. They have been doing it for over 20 years now. - FixInsight just cannot match Pascal Expert's (PEX) depth of coverage. Compare the number of flags for each and you'll find a very large difference. - FixInsight is part of Peganza's main toolset and is very actively maintained. Simply compare PEX version history: https://peganza.com/history_pex.html to FixInisight: https://www.tmssoftware.com/site/fixinsight.asp?s=history - PEX is $89 and FixInsight is about $115. If you want to dig deeper, get Peganza's free "Pascal Analyzer Lite" product. And if you want the widest available static source analysis of your Delphi code, get Peganza's "Pascal Analyzer" product as it has more info that you'd probably ever actually fully utilize. The one downside for the PEX vs Fix Insight comparison is a command line option, which is available in the more expensive "Fix Insight Pro" product but not in Pascal Expert. However, it is available in Pascal Analyzer so if that's a requirement then I'd get Pascal Analyzer + Pascal Expert in their bundled offering. I had an All-Access subscription to TMS for the last few years I have used both products and while they are both nice tools, Pascal Expert just seems to be a very large step ahead of Fix Insight in all ways except the command-line option (but I also have Pascal Analyzer so it wasn't an issue for me.) But, they had a huge head-start as they are using the 20+ year old heavily improved/tweaked Pascal Analyzer engine to generate their warnings. In my opinion, every Delphi developer should use the stand alone and command-line driven "Pascal Analyzer" tool in their development process. In addition, to help reduce introducing new issues, everyone should utilize either of these IDE plugin: Pascal Expert or Fix Insight. I would also highly suggest purchasing the All Access subscription from TMS as they are probably the number one component developer for Delphi and they have been pushing out an enormous amount of updates for all their products (seemingly excluding Fix Insight but I assume that is because it was a purchased product.) The amount of code you get from their All Access subscription is amazing. While other component developers have went idle or closed, TMS seems to have hit the accelerator lately. For a little more info, here's my review of Pascal Expert https://ideasawakened.com/post/product-review-pascal-expert

For myself, if I use that new feature it will only be used spargingly because, as usual, new language features break tooling. Here are a few QP issues added on multi-line strings: RSP-43420 multiline string literal class const breaks syncing between IDE form designer and editor RSP-43408 Multiline string literal containing reserved word breaks down navigation RSP-43380 Multiline string literals breaks code formatter Given that the inline vars feature was added 5 years ago and the IDE tooling still doesn't fully support it... you really have to wonder when the tooling will properly handle multi-line strings.

Peganza's tools are much better than Fix Inisight. You can start with their Expert but expand into their Pascal Analyzer product which is very in-depth.

Well, this is actually Delphi major version number 29. But if you use Compiler or RTL versions, then its number 36. Delphi 2009 was actually the 12th release so this new Delphi 12 is a 14-year late-comer. Instead of just skipping Delphi 13 to go to Delphi 14, let's go directly to Delphi 37 and sync all the versions for a brief moment in time until some marketing guy wants to switch to MPDS 1.0 (Multi-Platform Dev Studio) or other such thing.

Very nice!

It's finally back online for me.

That same DocWiki page stated "The default linkage mode is static with SQLite version 3.31.1 with FDE." so I would assume it would be backwards compatible.

After switching to major versions at 11, we now have 12 but will they skip 13 or not?

Correct It doesn't work well with new language features and there's no desire to put any effort into the old DotNet based implementation. They have yet to announce when a replacement will be available.

Yes, I was referring to IDE, not 3rd party components. 3rd party parsing of Delphi code may be improved with an official language definition perhaps.

I don't buy that it is 'always the case'. The way to avoid that is to develop the IDE support with the new language feature at the same time so they are released at the same time. The IDE is obviously there to assist the user with the language - if the language outpaces the IDE, then the user cannot properly utilize the IDE. It is a self-defeating scenario. And when the IDE support is many years behind language features it also becomes a real credibility problem. There can be some excuse to release experimental language features without full IDE support - but the gap between language feature release and IDE support should not be measured in 5 to 10 year spans (unless it is a special/edge case that hardly anyone utilizes.)

Profilers measure application execution. Two main types are Sampling and Instrumenting profilers. You run the application and the profiler measures times for code to complete. It sounds like what you want is some sort of AI to read/parse your code and suggest improvements. You could try feeding pieces to ChatGPT and see how well that performs... Or, perhaps you want a static code analyzer, like Pascal Analyzer from Peganza....https://www.peganza.com/products_pal.html it will parse your code and provide reports of things that could be improved. (They offer a free, limited feature version to try....Pascal Analyzer Lite: https://www.peganza.com/download.html)

Did you get your Linux debugging issues figured out?

There was a note somewhere about using a custom launcher. Try clicking the "Use launcher application" option and use this command line to see if you see any change in behavior. /usr/bin/gnome-terminal -- "%debuggee%"

What do you use for Spell Checking VCL apps on Windows made by Delphi? There seems to be two commercial options left: https://www.devexpress.com/products/vcl/spell_checker/ Included in their $1500 subscription. Don't think I want to pay $1500 for a spellchecker. https://www.tmssoftware.com/site/tmsspellcheck.asp Available alone or in their subscriptions. I'm trying to get this to work now. The old standby hasn't been updated since 2015 and forums are overrun by spam. I assume these guys are no longer around? http://www.addictivesoftware.com/

3 Million. Check out Embarcaero's home page... Of course, sales & marketing's number might be based on fuzzy math. 🤠 I know it's likely a lot bigger than most people think.

I was digging into some code that leverages a custom AssertErrorProc to handle some unique errors in an app and I examined the help page (https://docwiki.embarcadero.com/CodeExamples/en/AssertErrorProc_(Delphi)) which states in a code comment: { No local variables. Not compiler generated temporary variables. } { Using the call stack here will cause Access Violation errors. The routine I'm looking at uses a local variable...so the question is what is the downside of doing so? I couldn't find much info on this - few blog entries. http://www.blong.com/Conferences/BorCon2002/Debugging/3188.htm http://www.blong.com/Conferences/DCon99/VCLSourcery/VCLSourcery.htm https://blog.matthewskelton.net/2012/01/29/assert-based-error-reporting-in-delphi/ I asked ChatGPT "In Delphi, you can reassign the default error handler for assertions by leveraging the AssertErrorProc system variable. In the help file it is stated not to use local variables within this custom error procedure. Why would that be a problem?" Which responded: "The reason for not using local variables within the custom error procedure assigned to the AssertErrorProc variable in Delphi is that the procedure is called at a very low-level when an assertion fails. When an assertion fails, Delphi's runtime system calls the custom error procedure pointed to by AssertErrorProc. At this point, the program is in an unknown state, and the system stack may be corrupted. In this situation, local variables may not behave as expected, leading to unpredictable results or even crashes. To avoid this problem, it is recommended to keep the custom error procedure as simple as possible and avoid using local variables or other resources that may rely on a stable system state. It's also a good idea to log any relevant information about the error before attempting to handle it, as the program's behavior may be unpredictable after an assertion failure." Does anyone have further insight? Currently it's just a matter of curiousity and I'm not tracking down a specific error.

At least in the U.S., the market has been drying up for many years. In some companies, they take forever to hire replacement Delphi developers because they get no responses to their ad, or they are overwhelmed by inexperienced foreign developers. Many experienced Delphi developers have been in the same job for years and it takes a lot of effort to get one to leave the safety of their current position. Eventually they leave when the project is rewritten, or they participate in the rewrite and migrate to the new team and the Delphi team is dissolved. I usually re-post open Delphi positions when I stumbled across them but I only see a few new Delphi job ads a month. I keep waiting for the next revival of Delphi as it's still a powerful tool, but Embarcadero seems happy with its current growth in Brazil and doesn't seem too focused on U.S. other than keeping the renewals flowing.

Here's a quick blog post about some options. https://blogs.embarcadero.com/ultimate-web-frameworks-for-ultra-fast-web-application-development-using-delphi-c-builder/

Check out https://www.tmssoftware.com/site/tmswebcoreintro.asp

It gets rewritten in C# or otherwise moved to the cloud.

Or they are unemployed living in their Mom's basement.

Not currently. I advertised a few times for my current workplace and we hired two devs in the last year or so. Our small dev team has 3 Delphi MVPs on it, which is nice.

I'd agree that contributes to the problem of hiring Delphi developers. I was in my last position for over 20 years. Most of the developers that worked with me were there for 10+ years. The younger ones last 12-18 months and move on.