Joseph MItzen

I've never encountered anyone except Delphi users who develop inside VMs. Seriously, no one else. I'm not sure why you'd want to do it either. You're going to end up with less RAM, slower CPU, slower disk access, and the need to maintain two OSes now. I can understand testing in a VM where isolation and reproducibility are important, but I don't understand the advantages of using a VM for development. Honestly, it might have something to do with how hard it's been historically to get a Delphi development environment set up (or upgraded).

On Linux with KVM one can reserve hardware for the VM to have dedicated access to. On my home desktop I finally got this set up correctly so that a Windows VM has exclusive access to an old second video card I stuck in the machine. I was able to run some 3D games in the VM essentially as well as the old card could before under native Windows. I hooked the card's output to the second input on my monitor and can toggle back and forth between fullscreen Linux and fullscreen Windows with hardware GPU. 🙂 The keyboard and mouse can be toggled between systems and the sound is virtualized although one could also dedicate these to the VM too if they have the extra hardware. I *think* it's possible to configure things under some circumstances to automatically switch graphics cards such that, say, Linux boots with the newer graphic card but when the VM runs Linux gets the old card and the VM gets the better one, but I haven't tried this yet. If possible, it's not exactly easy.

I don't believe it was about running Hyper-V on desktop Linux so much as being able to replace all but Hyper-V's micro-kernel with Linux (aka "Linux as the root partition"). It doesn't look like the user space patches have landed yet to allow actually creating virtual machines with it. https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-Linux-Root-Partition

IEEE754 dictates exceptions? <Should know better than to question David Heffernan; checks and finds out it's true.> Wow. Interesting. Apparently several other languages ignore this... Python, Ruby and Perl all raised the same exception for either case when I just tried them. PHP returned INF or NaN and only issued a warning (good old frightening PHP). I guess my hat's off to Guido Van Rossum, Yukihiro Matsumoto and Larry Wall for doing the sensible thing rather than the "right" thing. As usual, Rasmus Lerdorf manages to zig when he should zag. 🙂 Also, I now formally declare my allegiance to Unums, which only have two exception types.... https://en.wikipedia.org/wiki/Unum_(number_format)

OK, let me try this then... Vandrovnik's code example raised different exceptions depending upon whether 0 / 0 or 1 / 0 was attempted, with no exceptions masked or calls to outside libraries. MDagg seemed to be justifying this because of the two returning different results. In that context I felt that they should both have raised a "division by zero" exception since that was what was attempted in both cases, regardless of returned value. And that's all I have to say on the subject lest I start thinking that 7 * 13 = 28....

And for Ahaan Sharma it's not a problem at all.

What I meant to say was that if an exception is called "division by zero" it should be raised for any division by zero or else renamed.

Today I learned 1 / 0 is "complex infinity". Perhaps I should have written "If an exception is called 'division by zero' it should be raised for any division by zero regardless of the numerator otherwise its name is misleading." I just checked and SymPy live gives the same complex infinity symbol for 1 / 0 while CoCalc & SageCell (powered by SageMath) raises a traditional "rational division by zero" exception for each. Wolfram and SymPy seem to be more math-oriented while SageMath is more programming-oriented I guess.

Division by zero is division by zero, whether it's 0 / 0 or 1 / 0.

I never use any RegEx in my code.

If you're using the version of Python bundled with your Linux distro, you should either install NumPy from the Linux distro's package manager, use the "--user" option to install the package in the user's home directory (making sure the path is adjusted accordingly) or install into a virtual environment. Otherwise you could have problems with the distro package manager and pip conflicting. The distro package manager won't know pip installed NumPy to the system directory and could end up overwriting it in the future during an install or update.

It was like a one step forward, one step back situation: I believe they removed FireDAC from Professional at the same time they added Mobile support to it.

Honest question - you pay $500 and then $250 a year to use an open source database, with none of that money going back to the database project itself?

That depends on the database and the version. For instance, in PostgreSQL < 9.2, a count(*) query would have to perform a sequential scan through the database: MS SQL Server, and now PostgreSQL, can often do index-only scans in situations like this, for much quicker results.

They're modern classes in essentially every way except inheritance. I imagine they did this to get around the memory management issues with the standard classes. Heck, even Niklaus Wirth in the past has suggested that objects are just Pascal records with methods. 🙂