Joseph MItzen

This isn't the first time it included Delphi. After a lot of pressure one year they opened a lot of questions up with write-in options and in spite of a promotional campaign from Marco, David I., etc., Delphi only scored 0.78% so it was omitted from future surveys. The most frustrating thing is that they've decided the simplest way to anonymize the raw survey data they distribute is to omit any write-in answers. 😞 That made it impossible for me to do data analysis regarding Delphi from that point forward. Being a formal choice again will be great because I know myself and a few others in the community loved to slice and dice the Delphi data.

Too bad we can't have a real set type rather than a binary array pretending to be a set type.

You left out a step... now if Embarcadero has its way it's going to be... run Delphi to call Python to call some library that will do all the work! Ironically by the way this Delphi program CoCa is simply a GUI that builds a command line to use to call a C++ program, Argyll, that indeed does all the work.

The Qt Company produces their own LGPL bindings for the Qt cross-platform GUI framework. Python also has bindings for the other major open source cross-platform frameworks, Gtk and WxWidgets, as well as bindings to native Windows and Coco libraries. Notable open source programs that use Python and Qt are the ebook management program Calibre, the Dropbox client, the OpenShot video editor, the Orange data mining suite, the Puddletag audio metadata editor, the QGIS Geographical Information System, the TortoiseHg front-end for the distributed version control system Mercurial, and the IDEs ERIC and Spyder. Have you looked at the pictures of this program? It's not much beyond some drop-downs and toggle buttons. Python has a multilingual internationalization services module in its standard library. Oh, and unlike VCL and FireMonkey, Qt supports right to left languages. 😜

Yes, better to use Delphi, where you can be sure it contains serious security issues! I don't think we're in a position to snipe... what follows is a portion of the log Core Security Technologies kept of their attempt to report the VCL Buffer Overflow vulnerability to Embarcadero. You might want to have some tissues handy.... Report Timeline 2014-05-29: Core Security Technologies attempts to contact Embarcadero. 2014-06-03: Core Security Technologies asks for a reply. 2014-06-09: Core Security Technologies attempts to contact vendor again. 2014-06-12: Core Security Technologies contacts the US-CERT for assistance in order to coordinate the "coordinated disclosure" of the advisory. 2014-06-16: US-CERT answers assigning the following tracking code to the report: VU#646748. 2014-06-30: First release date missed. 2014-07-10: US-CERT informs that they were able to contact the vendor and that a public bug tracking link was published by Embarcadero. 2014-07-10: Core Security Technologies contacts the US-CERT asking for vendor's contact information and informs them that the Embarcadero's bug tracking entry forces us to publish the advisory because the vulnerability details are now public. 2014-07-28: Core Security Technologies receives a reply from Embarcadero stating they expect to have a tentative date for a fix the week of July 28,2014. 2014-07-29: Core Security Technologies replies to Embarcadero that considering there is a public bug tracking report link, we would like to publish the advisory as soon as possible in order to help to protect the users. 2014-08-04: Embarcadero informs Core Security Technologies that they have a fix ready which is currently under internal review. They hope to give Core Security Technologies an expected release date by the end of the week. 2014-08-08: Expected release date (or reply) not received from Embarcadero, Core Security Technologies writes again asking for an update. 2014-08-11: Core Security Technologies notices the status of the public bug tracking report was changed to "fixed". Core Security Technologies emails the Embarcadero asking for clarification about the new status. Two questions are submitted to the Embarcadero (1) Core Security Technologies asks Embarcadero to confirm whether the new status means the fix was made public and (2) in case the fix is still not public, Core Security Technologies requests the tentative release date. 2014-08-11: Embarcadero informs Core Security Technologies that they are testing the fix internally and that they are planning to release it publicly on August 15, 2014. 2014-08-11: Core Security Technologies requests Embarcadero link to the fix so it can be include in the coordinated advisory report. 2014-08-11: Embarcadero replies to Core Security Technologies stating that the link will be delivered August 15, 2014. 2014-08-12: Core Security Technologies requests the estimated time when the fix will be public on August 15, 2014. 2014-08-12: Embarcadero replies that they estimate the fix will be released on August 15, 2014, at 3 p.m. PDT. 2014-08-14: Core Security Technologies requests Embarcadero to postpone the fix release day to August 18, 2014 in order to give users time to patch their software and avoid giving a two-day head start to potential malicious parties. Core Security Technologies informs Embarcadero that it will release the advisory on August 19, 2014 if they accept the postponement. Additionally, Core Security Technologies offers help in contacting third parties affected by this vulnerability. 2014-08-14: Embarcadero agrees with suggested release approach and will postpone the publishing of the fix until August 18, 2014 at 10 a.m. PDT. They also state they are internally discussing how they will notify their customers. 2014-08-15: Core Security Technologies requests Embarcadero deliver the support article and fix so it can be verified. 2014-08-15: Embarcadero sends Core Security Technologies a copy of the support article. 2014-08-15: Upon review of the proposed fix, Core Security Technologies informs Embarcadero that the fix seems incorrect. 2014-08-15: Embarcadero indicates they will investigate based on that assessment of the fix, and says they will need to delay the publishing of the fix until the issue is resolved. 2014-08-15: Embarcadero confirms a problem with the proposed fix was included in the support article and indicates they have a fixed the problem. Embarcadero requests confirmation from Core Security Technologies regarding the new article that includes the updated fix. 2014-08-18: Embarcadero informs Core Security Technologies of updated content in the article, and proposes publishing the same day. 2014-08-18: Core Security Technologies didn't reply due to a national holiday affecting their Buenos Aires offices, but Embarcadero publishes the fix and an accompanying support article. 2014-08-19: Core Security Technologies requests the fix from Embarcadero to update the advisory and verify it. 2014-08-19: Embarcadero replies sending Core Security Technologies a link to the fix. Due to the fact that the fix was released on August 18, 2014 Core Security Technologies schedules the advisory publication for August 20, 2014, leaving the fix analysis task for post-advisory release. 2014-08-20: Advisory CORE-2014-0004 published.

Python is a language that has over 360K open source libraries available in its package manager, hence there is very little need to reinvent the wheel, and the Python Package Index has over 360K wheels. Most of those 360K libraries are written in python. JP Morgan revealed they had 35 million lines of Python code when discussing porting Python 2 code to Python 3, and Dropbox has stated in interviews that it has 4 million lines of Python code. Python isn't merely a wrapper for C++. Because it can be the ultimate glue language (wrappers exist for most languages) doesn't remotely mean that's all it's good for. For instance, Python powers some of the most trafficked sites on the Internet as well, including Reddit, Instagram and Pinterest. This is simply incorrect. The language has many features that reduce the need for code (not the least of which is dynamic typing). Python guru Raymond Hettinger has said that any step that can be expressed in a single English sentence should be able to be written in a single line of Python code. I've personally ported many older Delphi programs to Python. Admittedly Delphi has added many nice things to require less code (such as type inference) since those programs were written. But using Delphi 5 to 7-era codebases as a metric, I found that the Python savings grew larger as the Delphi code size increased. The largest program I converted had the biggest line count ratio difference, with the Python program being 1/6 the number of lines of the original Delphi program. Python offers list comprehensions, a real set type (not a boolean array pretending to be a set), decorators, context managers, bigints, arbitrary precision, fractions, complex numbers, dictionary literals, default dicts, multiple inheritance, named tuples, iteration everywhere, array slicing, yield, generator expressions, a new high-powered case/switch statement dubbed 'structured pattern matching' that's one part case statement one part regex, async, a very smart string that automatically stores text as anything from UTF-8 to UTF-32 internally as needed, argument packing/unpacking, f-strings, a datetime that's both timezone and daylight savings time aware, keyword arguments, assignment expressions, try-else-finally :-), ... the list goes on and on. No magic? The only magic it doesn't have is Penn and Teller. If the benchmark question I posted here a few weeks ago is any indication, it could end up being 5X faster. It would definitely be simpler and far less verbose, especially since this is older code. And not "weak" because it would be utilizing modern, well-supported open source libraries for everything but the application-specific functionality (which should be put in its own library so others can use it in the future!). These were the top ten most downloaded Python modules in the last day: 1 boto3 9,519,635 2 requests 7,999,561 3 urllib3 7,918,776 4 setuptools 7,705,713 5 botocore 7,584,452 6 idna 6,303,478 7 s3transfer 6,256,215 8 typing-extensions 5,983,085 9 six 5,880,653 10 certifi 5,595,107 11 python-dateutil 5,563,439 12 pyyaml 5,482,592 13 charset-normalizer 5,112,908 14 click 4,330,631 15 awscli 4,317,207 16 wheel 4,218,955 17 numpy 4,078,225 18 pyparsing 4,078,047 19 packaging 4,043,536 20 cryptography 3,917,836 In the last day, the least-downloaded package on that list was downloaded about 8X more than the number of Delphi users on Earth. If Linus' Law, "Given enough eyeballs, all bugs are shallow" holds, that's a lot of eyeballs. (In the last month, the #1 package on that list was downloaded 253 million times!!!). With that level of usage, and the fact that the source is open, this greatly diminishes the odds of encountering a "corner case" bug in a popular package, or of bugs going unfixed for years as in certain, um, other libraries. I don't see how this type of usage and visibility would render things less, as opposed to more, secure. I'm not going to weigh all the pros and cons of porting code, especially without examining the code first, but you neglect to mention that porting to Python will open up a much larger pool of potential contributors than sticking with Delphi, which for a potential open source project would be a major factor. Python is also popular among digital studios (Disney was a major sponsor of one of the PyCon events for this reason), the open source 3D modeling software Blender and the open source image editing program GIMP both offer support for plugins written in Python, openCV maintains its own Python wrapper, and the Python package Pillow is very popular for scripted/automated image manipulation. There are also plenty of articles like the below (as well as podcast episodes with similar topics) floating around: https://blog.matthewgove.com/2021/02/06/photographers-heres-how-to-boost-your-income-with-python-automation/ Heck, they're even offering the same idea to KIDS today.... https://kidscodecs.com/python-photo-editing-pilow/ In short, you're likely to find more serious photographers have already been exposed to Python than to Delphi. Many also use Macs, which means that the old Delphi program would need to be ported anyway to FireMonkey if it wanted to reach that sizable base of users (Python, of course, supports all major and minor operating systems). Finally, open source enthusiasts are unlikely to warm to the idea of needing to use a proprietary language, IDE and framework to contribute to the project. Even taking into account the monetarily free version, they're unlikely to treasure needing to give personal info to Embarcadero, the stream of emails (and sometimes phone calls!), etc. And needing to develop on Windows? That might be the final straw. The 2021 Stack Overflow Survey shows that 45.33% of developers do their work in Windows, with 25.32% in Linux, 25.19% in OS X, 3.29% in Windows Subsystem for Linux, and 0.18% in BSD. You shrink the potential contributor pool by more than half by limiting developers to Windows. I have no numbers for this, but my instinct suggests the biggest enthusiasts for open source contribution are probably disproportionately found in that 25.32% who are using Linux as well. There are a lot of factors to consider, but with all due respect I hardly consider the option to port the project to Python "nonsense". Attached to the bottom are two images; one is from an article on a programming competition website discussing whether Python should be an allowable language and the second is from an old Paypal Engineers' blog entry called "10 Myths Of Enterprise Python" comparing their ASF XML Serialization library written in C++ to the version they rewrote with Python (1580 lines vs. 130!).

While I don't have numbers for you, I do have this perspective - Interbase's encryption is effectively useless. People have occasionally proposed the same feature for PostgreSQL, and every time there's both little interest and sound arguments about why it's useless. If you want to protect your data if someone walks off with a server hard drive, you have OS-level or hardware level full-disk encryption available. Embarcadero would argue that this doesn't protect anyone from snooping while the system is running, since the encryption in this case is transparent to the running OS. That's true, but Interbase's solution won't help you here either. Here's why: On a typical server, the database is given its own user account and is the only application running as this user. All the files are set to belong to the database only. This makes sense as nothing else should be touching the raw database files. So in this case there would be a user "interbase" that owns all of Interbase's files and the Interbase executable is the only application that should be able to touch the raw database files. All well and good. Data is encrypted within the Interbase database to protect it from someone who manages to gain access to the raw database files anyway. But here you're not helped. The encryption key is stored on the server. The "interbase" user owns the key file. If anyone has gained sufficient access rights to read the raw database file, they also have the right to read the key file, since it's going to have the same access privileges. Now if you have the raw database file and the encryption key you can decrypt the encrypted data and the Interbase encryption was useless in protecting your data. Some would argue it's better to do encryption on the client end and store the encrypted data in the database. Now if someone gains access to the server and the database file they still need to also gain access to the client to get the encryption key. This is more secure, but if encryption happens on the client end the database can't read the unencrypted data and hence indexes won't work on those columns. So IMHO neither of these solutions accomplish much and in most instances aren't worth the hassle.

That happens during the convention too? Dang. I signed up for one of their "TCoffee and Code" sessions a while back with the topic of "Real-Time Financial Software Development with Delphi". I'd been talking to someone about possibly working with them on some financial software to test some investing ideas they had and I was curious what the state of financial libraries for Delphi was. I wasn't aware of any, so I thought this would be interesting. I set aside my lunch time to watch. Jim McKeith had decided to try hosting the webinar via YouTube and it was not going well. Jim struggled to get everyone's audio working. I suggested the next event be moved to OnlyFans, but he and the guests decided against that idea. What followed was half an hour of the attendees offering advice to Jim to try to fix the problems. If you've ever wanted to see Jim McKeith's head shrink and fly around your screen (and who hasn't?) feel free to click here. The next half hour saw the guest tell war stories about what it was like trying to create financial software in the 1980s. Now I enjoy 80's tech nostalgia as much as anyone, but this wasn't exactly what I'd expected to get out of this webinar. About 1 hour 10 minutes in my lunch time was past done and I had to log out, never actually learning anything about financial software development with Delphi, real-time or not (guest was still talking about Turbo Pascal). The final cut of the video on YouTube shows the talk ran just shy of two and a half hours! (Coffee must have gotten cold). Sadly I never made the time to watch the remaining hour and a half to see if it got better. And now I'm hearing that even CodeRage or DelphiCon or whatever it is nowadays has the same kind of issues, even after staging it all these years. Shame.

Meanwhile, I got lost when BASIC dropped the line numbers....

The sum of the values is 233,333,334,166,666,668 which would overflow a 32bit Integer. I tried changing the loop counter to Integer, but that didn't produce any change in the time.

I just installed the Delphi Community 10.4 version into a 64-bit Windows 11 VM. I only installed the Windows target. When I create a project; the only target option presented is Windows 32-bit.When I select the "managing platforms" option, the only Windows option is "Delphi Windows Community". I seem to recall that the standard options here used to include Windows 32-bit and 64-bit listed separately. Have they removed the ability to create 64-bit targets in the Community Edition or am I missing something?

Thank you! This worked, but I must say I'd probably have never figured it out in a million years on my own. Interface-wise, it makes no sense at all.

Thanks! This worked!

To be fair, the Nick Hodges of today isn't like that anymore. I think once he stopped posting in the old forum he became a much happier person. Even he admitted that that environment tended to bring out the worst in people. Apparently he's now the developer advocate at Rollbar, so he's no longer employed working with Delphi either. I rather like New Nick.

If you're MVP Bruce McGee, getting yourself appointed a moderator of the Delphi subreddit and then deleting or shadowbanning even mildly critical posts, or warning posters to "watch themselves".

Jeroen Wiert-Pluimers lost his MVP status because he kept posting articles about the security flaws on Embarcadero's website that he repeatedly informed them of and they declined to fix. Joanna Carter believed she lost her MVP status when she posted about the cost of Delphi being too high. About ten years ago there was a discussion in the comment section of a blog post from Jolyon Duranko-Smith and Joanna Carter, David Intersimone and Nick Hodges all ended up taking part. Joanna mentioned her belief about losing her MVP status. Hodges and Intersimone kept insisting this wasn't the reason. When Carter asked why then, the response was "You know why!" She insisted she didn't. They said they couldn't say because of privacy issues. She said she'd waive any privacy issues and post the reason. They refused again and continued to decline to tell her why she was removed as an MVP. It was rather bizarre.

You joke about this, but they really think that way! Several years ago when Google Plus still existed, someone in the Delphi group (it wasn't you, was it?) posted a graph they'd made showing bugs closed over time... or maybe it was showing how long until bugs were closed; I forget which. Marco Cantu made a rather aggressive reply to the post that the chart was all wrong because of something (I don't remember), and he was going to post the real graph on his blog. The original poster was very gracious, apologizing for their mistake and looking forward to Marco's blog post. A blog post shows up from Marco purporting to show bugs closed over time and the trend for how long bugs stay open, each looking really nice for Embarcadero. I realize that his chart is conflating actual bugs with bugs closed because of duplicate, feature request, won't fix, can't reproduce, etc. I (and some others) used the blog commenting option to explain this to Marco. Marco declined to approve any of these comments. Instead, he appended a few sentences claiming to summarize what some people had written about the subject. At least in my case, I felt his summary was inadequate and skipped several problems I'd pointed out. His only "fix" was to keep the chart up and just change the word "Bugs" to "Issues" in the title. Now, I was working in data analysis at that time. I was able to back into the actual closed bug counts based on information from his blog post (but not the correct data for average time to close a bug). I made my own chart with the revised numbers; the trend was the opposite from the one on Marco's blog. I shared a link to that chart for him; of course he never approved that comment either and his summary didn't mention that when you took the other non-bugs out the chart trended in the exact opposite direction as the one he posted. Ironically, he claimed to be showing a more accurate version of the data than the chart on Google Plus but his was far less so. Ultimately I realized the purpose of his blog wasn't to actually determine the trend regarding bugs and bug fixes in Delphi over time but to perform damage control over the chart presented in Google Plus. 😞 There's no other explanation for leaving his charts after being made aware of why they were inaccurate and how they skewed the results.

Is that the new Like a Blank Book license?

Scream, cry, beat their fists against their desks in impotent rage?

What the...? It's looking for Python 2.7. Python 2.7 reached end-of-life status Jan. 1 2020! And Python 3.0 came out at the end of 2008. How old are these LLDB binaries?

You're just trying to induce a tear in the fabric of spacetime, aren't you?

There was, but they eliminated the position by firing the VP of Developer Relations and never replacing him.

I think my view of the landscape is 32 bits less limited than your view.

Nice! I'm reminded a bit of the cppyy package for Python, which solved some of the same types of problems by the unorthodox method of embedding cling, a C++ interpreter built on top of clang.

It's 2022. Why does anyone need 32 bit? Windows isn't even available in 32bit anymore starting with Windows 11.