Joseph MItzen

Aren't they all just random bunches of alphanumeric characters?

To lower the temperature. It may be better to load up a few cores with processes and run the rest at their minimum speed than to have processes spread across all cores. This was actually a problem with Windows and some of the very early multicore AMD CPUs. Those CPUs had to run all cores at the same clock speed. Windows, which at that time was designed when multiple cores meant multiple CPUs, would move processes onto fewer cores because in a multi-CPU system this would reduce noise and heat. On these early AMD processors that resulted in, say, one core running at maximum speed, which would then require all the remaining cores to run at maximum clock speed as well. Microsoft had to put out a patch to change this behavior. This has become an issue again because now Intel has CPUs where some cores are high-powered and others are lower-powered but more efficient. OS schedulers now need to take this into account; I know the Linux kernel just received patches for dealing with this type of CPU more efficiently. And that's not even getting into issues with some AMD CPUs and memory, such as their X3D CPUs that have on-CPU memory. In the 16 core models (7950X3D) only 8 cores have access to the extra cache memory. Also, "AMD Ryzen has separate L3 for each quad-core cluster, so data transfer between core-clusters is slower than within a single core cluster. (And if all the cores are working on the same data, it will end up replicated in the L3 of each cluster.)" Scheduling is much more complicated nowadays in OSes! I think this lead to benchmark issues with the first of the latest gen AMD chips. Linux review sites gave rave reviews while Windows-oriented review sites gave poor reviews. Turns out there were issues with the Microsoft Windows scheduler that were affecting the performance which improved significantly on Windows after patching.

I'll bite... what other programming languages don't raise an exception when you divide by zero?

Who do they feel the need to keep the details secret from? All 27 other commercial Pascal IDE vendors?

The moral here is that private variables are almost as evil as threads. No one knows, forever and for all time, what anyone else might need to access in the future.

It all depends on the implementation. I believe JetBrains is offering their own LLM service in their IDEs now, but they've also added a completely local LLM that can perform whole-line auto completion. If hypothetically Embarcadero was offering their own LLM service, it could be turned on by default and people might not be happy about that. But I agree, as an excuse it seems a bit flimsy. I'm not sure why waiting longer would somehow lead to anything being more secure by design.

Apparently not. After just checking out their SQL Server update policies, I'm flabbergasted. This... this is not right. It's a nightmare. I remember when Oracle had a vulnerability where someone could log into a certain Oracle account without a password. I had an Internet-facing system set up at the time (fortunately not running Oracle). I checked the log the same day the Oracle vulnerability was revealed and there were at least 15 attempts to log in via that Oracle user account. THAT'S why you don't mix new features and updates. No one should have to choose between potentially introducing new bugs, vulnerabilities or incompatibilities and leaving a system vulnerable while a patch is tested. I remember a Delphi user (David Erbas-White?) running into this problem with Delphi. A new Delphi release came out that fixed a show-stopping bug he was experiencing. However, code that used to compile no longer did. Barry used to say that "If it compiles, it's valid Delphi". Marco said to David "This never should have compiled in the first place". Now David was faced with the choice of either getting his bug fixed at the price of breaking his code and requiring some redesign and rewriting, or having his current code compile but still be buggy. That's not a choice anyone should have to make. It's especially bad if the bug fixes are bundled with changes that break compatibility. As for the Windows OS, there's a reason the professional server space belongs to Linux of various flavors. Windows still hasn't figured out updating while Linux is moving to "atomic" updating for secure servers. In this setup, the file system is a read-only copy-on-write file system. This makes the system secure against malware. The update process is applied to a new file system snapshot. If it is successful, the OS is told to use the new snapshot on its next reboot (which will then be read-only as well). If for some reason this doesn't work right the system can always boot back into the previous snapshot. Security and ease of updating with minimal downtime (all the updating can be done while the system is still running). In this design the applications are installed via a container system, allowing installation without reboot, enhanced security, isolation of the application from the OS, atomic updating, etc.

That's what the word "amnesty" is supposed to mean in this instance - a waving of penalties. I'm very surprised to discover it was just another sale. They're out and out telling you something that's not so to get you to call up a sales representative. A former 20-year employee of Borland/Embarcadero's Delphi support once shared that they start having these sales whenever the sales team isn't making its target sales numbers for the quarter. It seems like that's a constant state now.

This isn't correct. Microsoft's tools division is not a loss leader (it currently supplies 23% of MS' revenue). Jetbrains doesn't charge for bug fixes and they're not Microsoft. They're also not a random assemblage of different software products glued together into one company. Embarcadero struggles to make a profit on Delphi because the user numbers are so much smaller and an accumulation of missteps that long predate their purchasing the product. Embarcadero can't attract new users so they have to find more and more ways to squeeze money from the existing ones. It's also hard to upsell to existing customers since most of its products aren't for developers. That's the honest truth no one likes to say out loud. I can't find more current numbers right now, but from 2013: "Microsoft also today announced that Visual Studio 2013 has sold over 3.7 million copies since its release less than five months ago." Prices then ranged from $1,000 to $13,000. They're obviously making a lot of money on Visual Studio! A publicly traded company doesn't choose to continue divisions that lose money (otherwise there would still be Windows phones and Zunes).

OK, first, this reminds me of an observation Jolyon Duranko-Smith once made. He observed that if anyone complained about something Embarcadero did as opposed to another major company, a defender would say it's not fair to compare them to Microsoft/whomever because those companies are much bigger. And if you counter by observing that a company like RemObjects does something that Embarcadero doesn't, the reply will be that that's because RemObjects is a much smaller company and can be more nimble. Every company ever compared to Embarcadero is always bigger or smaller; none of them are ever considered a fair comparison. 🙂 We learned during the sale to Idera that Embarcadero's bottom line is NOT based on the success of its development tools and Interbase. It paid only $30M or so for those, but was purchased by Idera for about $425 million a few years later. The bulk of Embarcadero's value is based on its database tools, not its development tools and especially not Interbase, whose market share is negligible (Enlyft estimates it at 0.13%). So Embarcadero could afford to give away Delphi... oh wait, it actually DOES give away a community version of Delphi, just as Microsoft gives away a version of Visual Studio (although MS' terms are more generous). I guess the comparison is apt after all. Finally, here's the terms from JetBrains, which only sells development tools, most of them being IDEs (but unlike Embarcadero, they've expanded to cover everything a developer could need, such as continuous integration software, bug tracking software, etc.): So Jetbrains doesn't charge you for bug fixes and IDEs are their core business. It's not normal to charge people for bug fixes. In fact, it's not normal to mix bug fixes and new features in the same update, something I argued with David Millington about in vain. Bug fixes need to be separate so they don't need extensive testing before application. This is how all major enterprise software works.

This is absolutely the case. A while back before the Idera acquisition I was using the GlassDoor website which lets people rate their employers. I decided while there to see what Embarcadero employees were saying. There was a very unhappy Delphi sales employee talking about the unrealistic target numbers and that the CEO was willing to do anything to hit target numbers because even they could lose their job if they didn't (this was when the previous owner was trying to pump up numbers so they could sell it for a profit). They said that management had told them they were setting up webinars to generate sales leads for them, but the salesperson complained that the only people who signed up for them were existing customers so they were useless for lead generation.

Just spam? You're lucky. A while back they made a big deal about giving away a 32-bit, command line-only version of their C++ compiler. I was curious what other restrictions were in place, given anyone could just download clang for free without any significant restrictions. There was no way to read the license without first installing the product, so I filled out a form to be able to download the compiler, supplying name, address, phone number, etc. A few days later I got a phone call from an unrecognized number and as I was busy I didn't answer. There was a voice mail message left - from an Embarcadero salesperson! They were trying to sell me a full C++ compiler (I don't code in C++ and don't code on Windows anymore, and already had GCC on my system anyway). They kept calling me back for about two weeks to the point I would never answer the phone if I didn't know who it was. They were emailing me, too, weird personalized messages wanting to talk to me and get to now my needs rather than forwarding me generic marketing department emails. I joked at the time I wasn't sure if they were trying to sell me something or ask me out. Finally almost three weeks in they gave up.

It's a privately held company; they don't have to answer to shareholders. By saying it didn't work out for them, that really means that most current users would be happy with having less features for a lower price, but this would not attract sufficient new users to make up the difference. So current users have to spend more than they want for things they don't use. There's a difference between a change and a bug fix. A bug means you paid for something that actually wasn't delivered as promised. In no circumstances should someone be able to deliver a product that doesn't work correctly and then offer to fix it for an additional fee.

If the only motivation was saving some money they could use an open source alternative, such as https://www.openproject.org/blog/open-source-jira-alternative/ or the brand new https://plane.so/

About a month ago I was doing some benchmarks of FreePascal under Linux and got an unexpected result. Thanks to some help here I was able to get Delphi Community Edition installed yesterday and found the same anomaly with Delphi targeting Windows. I was wondering if I'm missing something in the below benchmark or something has changed with the new compiler and there's something I'm doing I'm not aware of that significantly impacts performance. The benchmark consists of summing the total of all the numbers between 1 and 1 billion which are evenly divisible by 3 or 5 and printing the total. It seems to me that it's a short, simple and straightforward test that should have one simple, obvious way to implement it in Pascal: program numtest8; Var total, num : Int64; begin total := 0; for num := 1 to 1000000000 Do if (num mod 3 = 0) or (num mod 5 = 0) Then total := total + num; WriteLn(total); end. Compiled with maximum performance under FreePascal (I tried other O settings; they didn't make any difference) these are the results I get on a Ryzen 2700 8 core CPU with stock cooler, best of 3: 64bit, Linux: 11.36 seconds, 99% CPU 64bit, Windows 11 VM, 11.43 seconds (PowerShell doesn't report CPU usage with the timing information) This is the figure for Delphi: 64bit, Windows 11 VM: 11.38 seconds Those figures seem rather consistent across two compilers, two operating systems, a VM and bare metal, so nothing weird. But here's the weird part (cue spooky music): I was also performing the benchmark across other languages, single core vs. parallel, etc. One language tested was Python. I was able to create a single-threaded Python version that beat a multicore version, but that's a weird result for another forum. It's this that has me stumped. What follows is a test with PyPy, a JIT-enabled version of the Python runtime. Here's the source code: total = 0 for x in range(1, 1_000_000_001): if x % 3 == 0 or x % 5 == 0: total = total + x print(total) Note: if I were performing the benchmark this way in regular Python, it'd still be running; loops kill Python performance. The best way of writing this code in regular Python gives a result of 1 minute, 15 seconds (!!!). But PyPy was much better... too much better: PyPy3.9 v7.3.8, 64bit, Linux: 3.34 seconds, 99% CPU PyPy3.9 V7.3.8 64bit, Windows VM: 3.41 seconds PyPy performed over 3X faster than Delphi / FreePascal, and that's including the time it takes to compile on the fly! The CPU data from the Linux run proves what I already knew about PyPy, that it doesn't do any automatic parallelization that might explain this result. Is there some fancy new CPU instruction it could be using that the Pascal compilers aren't? I seem to recall that at least the Delphi 32bit compiler didn't perform bit-shifting to do division; could that still be the case and the divisions are killing the performance? I decided to test another JIT option for Python, Numba. Numba is intended to JIT mathematical operations only. It's not a Python runtime, but a regular library that takes Python functions and compiles them. It also has a cache function and a pre-compile option. I was lazy and since I didn't know how the pre-compile function worked I just used the cache option and ran it once to cache the compiled function then performed benchmarks. The code: from numba import jit @jit(nopython=True, cache=True, fastmath=True) def test(): total = 0 for num in range(1, 1_000_000_001): if num % 3 == 0 or num % 5 == 0: total = total + num return total answer = test() print(answer) Python3.10.2 + Numba, 64bit, Linux: 2.07 seconds, 158% CPU Python3.10.2 + Numba, 64bit, Windows VM: 2.49 seconds I can't really explain the 158% CPU figure, as I know that numba can do some parallelization but a debug run suggested it couldn't find anything to parallelize. Regardless, it knocked almost a second off the PyPy time, probably due to caching the compiled function. I could tell Numba to explicitly parallelize: from numba import jit, prange @jit(nopython=True, cache=True, parallel=True, fastmath=True) def test(): total = 0 for num in prange(1, 1_000_000_001): if num % 3 == 0 or num % 5 == 0: total = total + num return total answer = test() print(answer) And now we get: Python3.10.2 + Numba, 64bit, Linux: 0.84 seconds, 743% CPU Python3.10.2 + Numba, 64bit, Windows VM: 1.20 seconds Clearly here the CPU results under Linux are consistent with an 8-core CPU. So the mystery is: With a statically typed, compiled language, we get circa 11.4 seconds across OSes and compilers. With a dynamically typed language with its own runtime VM, and one notoriously slow at that, we get 3.4 seconds at worst including JIT compile time, , 2.0 - 2.5 seconds pre-compiled with some possible automatic optimization, and 0.8 - 1.2 seconds with explicitly requesting the loop be parallelized. Those results are... unexpected. Now I honestly thought that JITted Python could match or ever-so-slightly beat FreePascal, because I've seen that happen before several years ago. But at least 3X faster to 10X faster? That was a shock. I'm half hoping someone will tell me I'm an idiot and I should never write Pascal code like that and if I just do X it'll speed up 300%. If not, my best guess after days of thought is that vague memory about bit-shifting. I remember when I read that Delphi didn't do that because Tiny C, a C compiler so tiny it fits on a 3.5" floppy disk - with operating system! - only has three optimizations, but one of them is bit-shifting. That would seem to imply it's rather useful. I'd be interested if anyone has any insight into why Delphi and FreePascal performed so poorly in this benchmark. I'd really like to rule out any mistakes on my end. If we can figure out what's killing the Delphi performance - and it's not me - these results should make for a very, very interesting QC feature request.

I would think delivering software and information to customers would be mission-critical infrastructure. Honestly, if you're in charge of a data center, redundancy and failover are basic elements of the job, like making sure a bank account isn't overdrawn is to accounting. Netflix periodically shuts down 10% of its infrastructure to be sure their system is resistant to failure! Just like the old forum used to be made of custom code held together with wire and chewing gum and managed by a volunteer employee in their spare time, it sounds like Embarcadero has one on-premises server for all the Delphi stuff with no failover, geographically-separated redundancy, etc. Given the rock-bottom price of hardware today in addition to the ready availability of cloud virtualization, there's no excuse for not having a physical or virtual standby. On top of that, server problems aren't a sudden development like your severed cable example. Drawing upon what Uwe said, it seems reasonable to conclude they just kept ignoring recurring problems or beating it with a stick until a component failed completely, at which point they ordered a replacement.

Like a lot of stuff at this company, things are probably done a certain way just because they've always been done a certain way by the same people who have worked there since the 80s or 90s.

Don't worry; I figured out where they can get a replacement server!

If they're not going to have any internal redundancy then they should just move to cloud servers.

They did, and Larry Ellison said to try turning the servers off and back on again.

Well, some of us like to feel fancy when we code!

He just got 11.3 running; don't frighten him further.

Now the next step is to get escape characters like \n for a line break!

Quite possibly. But triple quotes for multiline strings are also in Python. Python gained multiline strings with triple quotes in 2001.

Playwright and Playwright-Python (there are playright bindings for several languages) is fantastic! I believe Microsoft wrote the puppeteer library that automated Edge; the folks who wrote it left that to create playwright, which works with all the major HTML engines and incorporates some nifty features such as automatic waiting for elements. It's well-documented, too. Lots of nice features, including being able to save and load context (to preserve things such as login cookies). Some sample code from a program I wrote that needed to automate some actions with the Internet Archive: Logging in and saving context so I never have to do it again: browser = playwright.firefox.launch() context = browser.new_context() page = context.new_page() page.goto("https://archive.org/") page.get_by_role("link", name="Log in").click() page.get_by_label("Email address").fill("jgm@myself.com") page.get_by_label("Password").fill("**********") page.get_by_role("button", name="Log in").click() context.storage_state(path=STATE_FILE) There's an expect function with optional timeout that can be used to wait for things: page.goto(url) borrow_button = page.get_by_role("button", name="Borrow for 1 hour") expect(borrow_button).to_be_visible(timeout=60000) borrow_button.click() return_button = page.get_by_role("button", name="Return now") expect(return_button).to_be_visible(timeout=60000) And I forgot one of the coolest things - it can run visible or headless. There's a mode you can start it in so that the browser is visible, along with another editing window. Then you can just click and type in the browser window, and the code it would take to replicate those actions appears in the editing window! This is a super-quick way to start a project - no need to start searching through the HTML looking for object names, etc. Just start interacting with the website and all the appropriate code is determined and generated for you. Copy and paste that into your project source code and then tweak as appropriate and you're good to go. There are lots of other nice features including being able to emulate mobile browsers,.