Jump to content
Marco Cantu

Patch 2 for RAD Studio 10.4 now available

Recommended Posts

26 minutes ago, Vincent Parrett said:

ok I'm blaming @Dalija Prasnikar for logging bugs on such esoteric code that no sane person would ever use :classic_wacko: 

Are you calling me insane???? This is my actual code!!! 😜 

  • Haha 1

Share this post


Link to post

The Oracle:

 

What’s really going to bake your noodle later on is, would you still have broken it if I hadn’t said anything.

Share this post


Link to post

Following this with great interest, but the main question is "Does this mean that we should wait on installing patch 2?"  I like the idea of debugger stability fixes, etc., but if this adversely affects some of my favorite libraries (e.g. Spring4d!) then it's a show stopper.  Any thoughts?

Share this post


Link to post
47 minutes ago, MarkShark said:

"Does this mean that we should wait on installing patch 2?"

I can't really say, I installed it, my code failed to compile and I did something else for the weekend. I would love it if the debugger was improved but haven't got to that point yet, perhaps others can chime in.

  • Like 2

Share this post


Link to post
2 hours ago, MarkShark said:

Following this with great interest, but the main question is "Does this mean that we should wait on installing patch 2?"  I like the idea of debugger stability fixes, etc., but if this adversely affects some of my favorite libraries (e.g. Spring4d!) then it's a show stopper.  Any thoughts?

 

I'd go ahead and install it, those debugger issues are a real pain. There's an uninstall for patch 2 if it does break your code.

 

So far the only patch 2 specific compiler issue reported is related to using record constraints on generics where the record contains a managed type such as a string or a dynamic array. If you don't use record constraints on your generics (and you probably don't) then you're likely fine.

 

To my knowledge the only library that's definitely broken so far is VSoft.Messaging. I haven't read anything that leads me to believe that Spring4D is broken.

  • Like 1

Share this post


Link to post

I use Spring4D extensively (but not all of it obviously) - Base and Core and Extensions compiled fine for me with Update 2.

Edited by Vincent Parrett
typo
  • Like 2

Share this post


Link to post

So much for hopeful thinking on my part!   First couple of projects compiled without issues, then I tried one with the TOmniThreadLibrary and boom.  I use TOmniValue.FromRecord() with a record with strings in it, which I believe is the issue here.  Anyone know a workaround for that?  I have to admit that its worked so well up til now that I haven't looked back at that code in while.

Share this post


Link to post
1 hour ago, MarkShark said:

I use TOmniValue.FromRecord() with a record with strings in it

Seems like the record constraint issue again. Same issue I have.

Share this post


Link to post

Thank you Stefan!   On the OmniThreadLibrary I switched from passing records to passing Objects instead.  Seems an easy-ish fix, but, of course, now I have to manage those object's lifetimes.  No biggie.

Share this post


Link to post

Just remove the : record constraint from FromRecord and it will work. Just don't pass anything but a record then :p

  • Like 1

Share this post


Link to post

Stefan, thanks for that suggestion!  I looked into removing the constraint and found that TOmniValue already has an alternate method called TOmniValue.FromRecordUnsafe that completely solves my issue. nice!

Share this post


Link to post
12 minutes ago, MarkShark said:

TOmniValue already has an alternate method called TOmniValue.FromRecordUnsafe

Primoz is psychic 😉

  • Haha 1

Share this post


Link to post
Just now, Dave Nottage said:

Primoz is psychic 😉

No kidding Dave!  When I got to that line of code and realized it's been in there for a while I was quite surprised.  Now granted, I would like the safety version, but this works for now!

Share this post


Link to post

I just try out the Patch 2:

 

From the description:

Quote

Verifying Correct Installation

To verify that the patch has been successfully installed, you can look at the timestamp of the replaced files, for example getit270.bpl under the bin folder should have a July 2020 timestamp (rather than the May 2020 one most files have).

This let me consider if one or a few files are good enough to check,

or do I better have to check all replaced files.

 

Isn't it if one file is replaced then all of them shall be OK ?

If any double on this, e.g. by hanging files in a crashed IDE, then better re-boot the PC before Patch-2,

and avoid starting the IDE before the patch.

 

Has anybody find issues with not correctly replaced files ?

 

Edit:

For example after the Patch 2

"Lib\Android\xxxx\librtlhelper.a" seems to have changed timestamp from May to June, but is identical file.

Is that good or bad :classic_biggrin:

 

And all the Include files seems replaced, but identical files

left is old, right is replaced b< Patch 2

image.thumb.png.7756019cdefca6ab13908306d8dd7c5b.png

 

Edited by Rollo62

Share this post


Link to post
3 hours ago, Rollo62 said:

If any double on thi

One has to appreciate that the DOS installation of 'Patch 2'  truly 'empowers application developers' 🙂

 

All that's missing is deployment via floppy disks..

  • Haha 1

Share this post


Link to post
Guest
3 hours ago, Rollo62 said:
Quote

Verifying Correct Installation

To verify that the patch has been successfully installed, you can look at the timestamp of the replaced files, for example getit270.bpl under the bin folder should have a July 2020 timestamp (rather than the May 2020 one most files have).

 

Such instructions make me dizzy.

 

I think it does make sense to clear things to the author of that getit and patcher, it is 2020 and there is many forums over internet full of developers who can do better than check timestamp, something like a hash or new fancy algorithm, i read somewhere that in future pathcers might do that.

Share this post


Link to post

Yes, they have a PatchTool included, which could verify its own work.

Why are so obvious features always missing, to find the failure in the picture by ourself ?

Share this post


Link to post

Am I wrong to expect that the PatchTool is simply unzipping the Patch2.zip file? On an isolated test machine with no Internet available I unzipped the patch manually and simply overwrote the files.

Patch1 worked this way. The appearance of PatchTool made me wonder...

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×