Darian Miller

Perhaps. I'm testing this particular machine out as I could swear that I disabled it in the registry already. I know for a fact that I changed the Windows Update service in SCM to be disabled and it was running after a reboot. Microsoft is definitely getting more aggressive at ensuring updates are still occuring. Another option that I enabled is to set the network connection to be metered. That plus the registry setting should effectively kill it. If not, there are some other tricks available.

Rubber Duck Debugging: https://en.wikipedia.org/wiki/Rubber_duck_debugging

LOL. Feed that dog an extra snack.

After a little search, using a Hosts file seems like too much work given all the servers they use. I have a reg file to disable updates, which apparently wasn't executed on that particular VM: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAutoRebootWithLoggedOnUsers"=dword:00000001 "NoAutoUpdate"=dword:00000001 "AUOptions"=dword:00000002 "AUOptionsNote"="2=Notify before DL; 3=Auto DL, Notify of installation; 4=Auto DL by schedule; 1=XP Keep my computer up to date option" "UseWUServer"=dword:00000000 "MSDocLink"="https://docs.microsoft.com/en-us/windows/deployment/update/waas-wu-settings"

I handled address parsing for many years. There was one parsing routine which took a single line street address as input and chopped it into pieces. One source of input was hundreds of thousands of consumers would type their name/address into a web form every month and we imported each into a database with the street number, street name, street type, direction, PO Box, RR, Apartment... you can get it mostly correct, but perfection isn't possible. We pulled many millions of credit reports using that data, so it was pretty good and rarely completley failed. The data was also used for mailings, which we corrected with the NCOA database. We also compared to the OFAC/SDN list and some other lists... seems like every different address list has its quirks. That single routine was written in Clipper in the mid 90's, converted to XBase++ in the late 90's, and then converted to Delphi early 2000's. It's not pretty code after the conversions and many tweaks. But perfection wasn't ever the target - if they typed in a town name into the address field, then so be it. That single routine may be the cause of many Americans having an alternate address listed on their credit report. (We pulled a few hundred million credit reports with that code over the years.) But the credit agencies handling of addresses is also extremely funky since they have been dealing with this problem for decades and they get data from so many different sources. They have a specific list of street types that are supported and each agency has a slightly different list. They take your name/address/ssn inputs and do a best guess-match to which consumer files to include in the credit report output (surprisingly, all the various pieces of the credit file are mainly stored by name/address and not SSN.) You can get a slightly different credit report depending on slight variation of your inputs. I've seen that happen many times and trying to explain it to an end user is always fun. American address data sucks. Even the printed barcode id is not a permanent street address identifier. You simply have to establish your acceptable level of suckiness and stick with it.

Also, zipcodes in the U.S. change all the time. Your best bet is to standardize the address and use that. (120,N,Franklin,St,Chicago,IL,USA) The standardization doesn't have to be perfect, just consistent. Just know that it won't ever be 100% correct and you will eventually end up with duplicates with differently formatted addresses. Otherwise just create a full covering index. Have an address table with a GUID as Primary Key and your 6 address fields. Create an index on your 6 address fields as varchars. Create a values table with your source/destination address guids and then your 10 floats. To optimize have a small Source Address table, and a larger Destination Address table.

Agreed!! Even in simple usage it is unbelievably unnoying to have something running as a quick one-off on a Windows 10 system and come back the next morning to find the process was terminated and the system restarted due to a forced update. There are some options of blocking Windows 10 updates, but Microsoft seems to be actively working against those settings. Best bet is to block outgoing connections to the update servers at your firewall or simply redefine their update servers in a Hosts entry on the computer which is what I plan on doing soon as this just happened again to me yesterday.

Can you provide a small sample project that reproduces the error? My limited testing shows that it's working much better in 10.4.1. If you could reproduce the problem in a simple example project, it has a much higher chance at getting fixed.

On a diversionary whim, I tried installing 10.4 on XP and the installer presented a fatal error "This program does not support the version of Windows your computer is running." I imagine you have to unpack, tweak the installer package, and then rebuild it to get it to work on XP, correct?

Ok, I'll get the electronic version. Thanks!

Congrats! Are you working on publishing a print version?

You could check out this library: https://www.zylsoft.com/gsm.htm They appear to have recent updates, but their forums are down right now

My main point was making a case that this particular bug does not really warrant the noise. There are many other examples that you could use, and would probably garner more support. I like inline variables, and they work rather well. However, Boian stumbled across a particular set of circumstances which consistently leads to memory leaks which assumedly would have been obvious is he ran a memory leak checker before releasing his code. The simple reproducible case was posted in September. As in my hypothetical example, if it was a new language feature in VS2021 just released and you moved all your code to use it...you would not, could not, would ever expect to get an immediate fix from Microsoft so you should provide the same courtesy to Embarcadero and not demand "fair and civilized" compensation for this issue. Instead, argue for bugs that are more than 3 months old and it would be much more beneficial. And/or argue for more unit tests on the RTL, and demand they be made public. Embarcadero has acknowledged a quality issue. They have attempted to attack it in the last few releases and planned to do even more in the next release. Expecting them to immediately fix a new bug when there are plenty of bugs which are years old and affect much, much more code is just the wrong approach in my opinion. I fully support the general argument being made, but just not this specific issue.

LOL. I knew some response was bound to come in from someone. Sorry, but that is pretty weak as every piece of software has bugs. If you mentioned, say, RSP-9678 Delphi IDE is not DPI aware (from 2014 with 93 votes) then it may have been stronger. Or maybe RSP-17724 Linux x64 compiler produce very bloated code. Or perhaps this thread: Again, that's not an overly strong argument. How many one liner changes have you had to chase for hours on end, that may have not have revealed themselves as a problem for months? The key point here is tests. So you can put bugs in your code, or hair on your burgers which you serve, but they aren't allowed? I believe the major issue here is lack of tests. The main way to gain more confidence in the Delphi platform is by trumpeting, marketing, glorifying their major gains in testing over the last few years (which assumedly has been the case.) Likely one of their most dominant product features is backwards compatibility - that very valuable feature can only be assured with a huge amount of manual effort, or a very large amount of tests. Likely one of their most harshest points of criticism lately is new code is not up to the quality of old code. That also can and should be braced with an adequate amount of tests. Finally, let's state the obvious here: Boian Mitov should not have changed his core library to inline variables until he was completely satisfied that it wouldn't cause problems for his customers. Changing your legacy source code in thousands of places to utilize a new feature of Delphi seems pretty reckless without adequate testing. Yes, we should be able to trust the compiler, but how about using Microsoft as an example... They have one of the largest R&D budgets in the world and they still ship very questionable software. If they came out with Visual Studio 2021 today, would you immediately migrate all your source code to it, after changing it in thousands of places to use one of the VS 2021's newest language features, and then quickly ship your product to all of your customers with a large amount of memory leaks? Would you be out there stating that Microsoft shouldn't be able to sleep at night, or would you be rolling back your changes and provide a stable product again to your customers? I certainly don't like providing an excuse for buggy code, or lack of tests. But this particular example is certainly not the hill to die on.

30215 was reported in July. A minimal stand-alone test case to reproduce the issue was posted by Embarcadero in September. To complain that you don't have a fix by December is too much. This particular edge case issue is no where near the prime example to be complaining about long-standing bugs... to me, it considerably reduces the strength of your argument.

There are some Hunspell related items here: https://github.com/darianmiller/Delphi-Hunspell

Sorry to hear that... the classic is supposed to be backwards compatible with the prior version. I would recommend opening an issue on the quality portal.

CodeInsight was radically changed with the implemention of a Language Server Protocol host as the default Code Insight provider. You can change this in: Tools->Options->User Interface->Editor->Source->Code Insight You are able to switch back to "Delphi (Classic Code Insight)" I assume you are on an early version of 10.4 Sydney. The latest version 10.4 Sydney Update 1 and Patch #1 provide major improvements to Code Insight. You can see a list of recent updates here: https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List I suggest you update to 10.4.1 and then apply latest patches as Code Insight is much better.

Does that mean that more debugger issues will be found and fixed, or that your IDE Plugin will simply ignore more as time goes on? 😉

This was from the Q&A on the 10.4 Release Webinar back on May 27, 2020:

I believe it was stated that CE will remain one full version behind the current. So, when 10.5 gets released then CE will be upgraded to 10.4.

https://stackoverflow.com/questions/156767/whats-the-difference-between-an-argument-and-a-parameter

https://www.ideasawakened.com/post/delphi-programming-how-it-started-how-it-s-going

I'll need some more mushrooms to fully decipher that.

I've tried a few times to write a decent reply... I'll just leave it at: Whatever dude.