Several F2084 Internal Error on Delphi 10.4.2

[Dalija Prasnikar 1396]

39 minutes ago, mvanrijnen said:

Would like to join the Beta, but can find not one usable link, searched for 15minutes.  Website is one big commercial shit.

We are on subscription license.

One would think that something like this is available from "The New Customer Portal".

You can join the beta if you are on active subscription. Most recently, betas were announced on Embarcadero blog posts like this one https://blogs.embarcadero.com/delphi-and-cbuilder-10-4-2-beta-invite-for-update-subscription-customers/ Invitation is also probably sent or announced through marketing emails. You will have to sign NDA and you are not allowed to discuss participating in the beta nor about any features, fixes or bugs.

 

Above is valid for major release beta cycles and updated. Patches and hotfixes are commonly tested by smaller number of people because testing cycle is shorted and focus is on particular bugs. If you have some particular reason for testing some hotfix or you have some major issues using latest release, you can always try going through official channels and present your case. However, there is a catch-22 because you will never know whether some testing is in progress or not, and even when there is, you might not get answer to that question even when you ask directly (not in public).

 

Next major release will be 10.5 and at some point you can expect posts (unless policy changes) inviting subscribers to participate for that beta. When will that be, nobody knows. For now you can just wait.

[Lajos Juhász 293]

7 hours ago, Günther Schoch said:

where exactly is the problem (use cases affected)

We know that a bug in the compiler has been detected that affects several reported QC issues and with a help of a couple of developer the hotfix was tested a month ago. Unfortunately it's a top secret information what delayed the hotfix. 

[Darian Miller 361]

8 hours ago, Dalija Prasnikar said:

I am afraid that list might be too long... and it would require input from large number of developers. It all depends on code you have and what kind of workflow you have at any given moment and for which platforms you develop. What is good version for some people, might be utmost nightmare for others.  And besides stability, there might be other reasons and bugs in the core frameworks which makes some versions unsuitable for some developers. Workarounds were usually move to another version and hope for the best. Without actually trying on your own code and working with some version, one can never know.

I agree that it's not doable to be fully comprehensive, but there are some major issues people should be aware of for each version.  What might be useful is a list of major function topics and warnings next to each.  For example, inline variables were introduced in 10.3 but should still be avoided as their usage breaks tooling. (32507, 33176, 33365, 22089)   Another issue for those that rely on IDE Fix Pack would be a warning that's its not available for 10.4 but by 10.4.2 many features have been implemented.  I remember being stuck at XE2, but I no longer recall what was broken in XE3 which preventing me from upgrading.  

 

We are currently in the seemingly never-ending chase of requiring to use the latest version for bug fixes, but the latest version always adds new issues.  We end up with developers 'stranded' at particular versions because of major issues that they are waiting to be resolved.  Eventually the perceived pain of upgrading accumulates until such time as someone decides to 'abandon ship' and switch to a different solution.  This thread is an example - 10.4.2 follows with even more bug fixes than the 'quality' focused release of 10.4.1 and yet, two months after release, some people cannot use the product due to internal errors.  I wonder how many developers thought that their specific pain points were finally addressed and they would upgrade to 10.4.2 and then got smacked in the face with this particular issue and finally raised the white flag (especially after waiting for months now.)

 

For me 10.4.2 is their best release in a long while.  But I'm also no longer managing complex projects with many millions of lines of code so I'm not running into this particular showstopper.  However, I would really like to use inline variables, but until they fix the issues surrounding them (including the code formatter) then I refuse to use them.  I assume the code formatter might be upgraded in the 10.5 release cycle and it'll take until sometime into 10.6 before it's solid so I assume inline variables are dead to me until sometime in 2023, or later.  That's not intended as a slam, it's simply a reasoned forecast.  Therefore it comes down to a new language feature being introduced in 2018 and forecasted to be potentially usable in 2023.  Saying that out loud makes me sad and question my life choices...

 

[Anders Melander 1783]

51 minutes ago, Darian Miller said:

I assume inline variables are dead to me until sometime in 2023, or later.

Sounds like that code formatter is really important to you.

[Stefan Glienke 2002]

27 minutes ago, Anders Melander said:

Sounds like that code formatter is really important to you.

Or he just wants to see the correct values when inspecting them while debugging?

[Darian Miller 361]

2 hours ago, Anders Melander said:

Sounds like that code formatter is really important to you.

I listed 4 separate QC issues (32507, 33176, 33365, 22089) and there are likely a number more.  And yes, refactoring and code navigation is important.   And of course, code formatting is also very important.  CTRL-D needs to work so you can write code while in the groove and let it flow and then standardize/clean-up as needed during a break.  I don't want to waste brain cycles on mundane tasks like fixing the spacing and alignment after editing / refactoring but I do want to try to have standardized code.  CTRL-D mostly works great for my uses- but it simply cannot handle inline variables.  (CTRL-D is broken for other reasons, but none that affect me as much.)

 

 

 

[Vandrovnik 214]

3 hours ago, Darian Miller said:

Saying that out loud makes me sad and question my life choices...

Yes, the situation with severe bugs is strange and I wonder, if other software have similar problems. When paying customer is not able to work with big projects more then two months, it is like if he buys a new car with six-speed gearbox, but could use only speeds 1-4 with the information, that speeds 5-6 will be repaired sometime in the future, without any specific date.

[Darian Miller 361]

1 hour ago, Stefan Glienke said:

Or he just wants to see the correct values when inspecting them while debugging?

 

Its kinda sad that there aren't even any notes on that particular issue...which was opened in 2018.  The problem is too deep into their legacy code to even attempt a fix.

 

I don't come up against that particular issue as I wouldn't re-use the same variable name within the same routine.  It's definitely a cost-benefit question on fixing it...how many people care about this particular issue, or say formatting the code or extracting a method which is likely done multiple times per coding session.  

 

But thanks, I'll add it to my list of reasons why not to use inline variables.  https://github.com/radprogrammer/radteam/wiki/RADProgrammer-Style-Guide-Other-Guidance#Assume-These-Items-Are-Deprecated

 

[Darian Miller 361]

And now a patch for 10.4.2 is released!

 

[Anders Melander 1783]

2 hours ago, Stefan Glienke said:

Or he just wants to see the correct values when inspecting them while debugging?

Yes, there is that. Definitely.

When it's bad I usually have to convert the inline vars back to traditional local vars while debugging a difficult problem and then back again when I'm done. Not ideal to say the least but it's not enough to have me give up the convenience and improved readability of inline vars.

 

26 minutes ago, Darian Miller said:

say formatting the code or extracting a method which is likely done multiple times per coding session.  

I never use the formatter and I don't believe any of my colleagues use it either. I can't see why we would. We very seldom use the rename refactoring (mostly because it's unreliable).

You apparently have a different workflow. Nothing wrong with that. The feature is there so of course it should work.

[FredS 138]

1 hour ago, Darian Miller said:

And now a patch for 10.4.2 is released!

And the sheer number of bug fixes since Feb 24th shows we are nearly caught up 🤣 

[Lajos Juhász 293]

The patch is looking good after 3 minutes of testing 🙂

[Stefan Glienke 2002]

8 minutes ago, Lajos Juhász said:

The patch is looking good after 3 minutes of testing 🙂

That's what QA said before 10.4.2 released 

[Vincent Parrett 750]

So far so good. I turned LSP back on, was able to do a full build (100+ projects in the group) - then debug the main project, exit, change some code, compile and debug again. The IDE is using a lot of memory though.

 

Code navigation between projects is still broken for LSP (when only referencing dcp's) - so back to classic code insight it is. 

[Dalija Prasnikar 1396]

For anyone interested in try...finally patch... it is still broken. 

 

I guess those "3 minutes" tests strike again...

[Stano 143]

Um, there are two patches. No. 4 and 5. First I installed no. 5. Maybe it won't matter.

[Lajos Juhász 293]

1 hour ago, Dalija Prasnikar said:

For anyone interested in try...finally patch... it is still broken. 

 

I guess those "3 minutes" tests strike again...

 

If I remember correctly try ... finally was not effecting windows. I am using VCL for Windows so I could be still fine of course since I am enjoying my 2020 vacation I will test it in more details when I return to work.

[Dalija Prasnikar 1396]

17 minutes ago, Lajos Juhász said:

 

If I remember correctly try ... finally was not effecting windows. I am using VCL for Windows so I could be still fine of course since I am enjoying my 2020 vacation I will test it in more details when I return to work.

You are correct. On Windows platform try...finally works fine.

[Vandrovnik 214]

Patch for the patch has been released.

[Dalija Prasnikar 1396]

Just now, Vandrovnik said:

Patch for the patch has been released.

And this time it is fixed, finally. At least on Android... I didn't test other platforms.

[Lars Fosdal 1792]

I assume order of installation is not important.

 

[FPiette 383]

28 minutes ago, Lars Fosdal said:

I assume order of installation is not important. 

I would add patches in the order of publication date.

 

[Lars Fosdal 1792]

In that case, it is silly that the patches are not in order, and that two of them have the same date.

IMO, the description should have contained the patch number.

[Rollo62 536]

12 minutes ago, FPiette said:

I would add patches in the order of publication date.

 

Thats the best way.

Anyway, I have checked whats in the ZIP file, it seems that there is no overlapping somewhere in this case.

After install I doublechecked that all IDE folders match the patch.ZIP files 1:1, to be sure.

 

I also would recommend NOT to install patch from IDE with "Close IDE and install YES/NO", and to select "NO".

When "YES" is selected, the IDE closes and installs immediately, and also restart the IDE after installation is done.

I have seen some kind of 2nd run of install, but it was too fast to see anything.

What I prefer is that the IDE does not auto-restart, so that I have time to check what was changed first.

 

[Rollo62 536]

Regarding the sources, I only find these changes under rtl

 

What is strange is that the AppGlue.pas file shows as equal, since the new file has UTF8+BOM and the old file has UTF8.

But when compared binary, it looks as if there were more (invisible) code changes in the source file.

 

Left new file,   right old file

 

So technically the old and the new file is 1:1 same, only the new contains UTF8+BOM,

and I would say it makes not any difference.
 

But why is the new file in the patch then at all, if it doesn't have relevant changes ?

Is there any possibility that the "invisible" changes in the file could have an influence on the compiled output ?

I have no tool that is really finding the difference well, BeyondCompare lite shows always that its 1:1 same.