What decides where GetIt places the stuff it installs?

What decides where GetIt places the stuff it installs?

It seems that the files are placed under current user, even if Delphi is installed for “all users”. How do you get around that for a build server where the build process is running under a system account? This is kinda ridiculous.

Quote from Vincent Parrett: “Umm.. don’t use getit.. its a toy not a real package manager. Seriously why tf would it place libraries under the user profile.”

I have to agree. GetIt appears like a really trivial download/installer, than an actual package installer.

I guess it would be better to install the libs locally, then copy them to VCS managed folders, and check out those on the build server.

Originally shared by Lars Fosdal

GetIt, FinalBuilder and Continua Build Server

We are having some issues with the OmniThreadLibrary not being found when FinalBuilder is invoked from Continua.

GetIt places OTL under

C:UsersDocumentsEmbarcaderoStudio19.0CatalogRepositoryOmniThreadLibrary_3.07.4-Tokyo

and when I am logged on to the server, the FB projects build fine. When the Continua service user executes, it is a different user than my UI login – so naturally, the installation is not there.

What is the recommended way to get around this?

QC now forwards to QP and it is no longer possible to see your older open QC posts.

QC now forwards to QP and it is no longer possible to see your older open QC posts. Since the RAD Studio IDE still appear to report issues to QC – how can we now keep track of our submitted issues?

When will the internal error reporting in RAD Studio file reports to QP instead of QC?

Jim McKeeth Marco Cantù Nick Hodges

https://community.embarcadero.com/blogs/entry/quality-keeps-moving-forward

Generics.Collections – TList / TListHelper grows list size too aggressively

Generics.Collections – TList / TListHelper grows list size too aggressively

The current code will double the size of the list, regardless of it’s current size. This is fine for smaller sizes – but very wasteful when growing a large list.

Due to the design having ListHelper as a record which have an instance inside the class – it is not possible to simply make ListHelper.InternalGrow method virtual.

I am not sure what will be the better way to do this. Calling a plugin method (anonymous function) might be too costly and slow down the list at smaller sizes.

Perhaps have a growth strategy setting: Exponential (default), Percentage, Linear – and a growth factor field – which would be the percentage or number of items, depending on the strategy?

Anyways – just doubling a 128K, 256K, 512K, 1M list is not a good strategy – at least not if you are not able to override it.

https://quality.embarcadero.com/browse/RSP-17767

A Seattle Runaway

A Seattle Runaway

My colleague was just doing the normal edit, F9, break, edit, F9, etc – when this happened.  The compiler went runaway and found a lot of errors! In fact, it didn’t run out of errors – but kept finding them until

he killed  #10Seattle . 

  

After a restart and a F9 – no errors and ran as expected.

Naturally, it is impossible to reproduce on demand.

Cosmic ray bit flipping? Random data in uninitialized buffers? Aliens?

I disputed the most recent of these issues with the following comment: “Works as expected?

I disputed the most recent of these issues with the following comment: “Works as expected? Are you kidding me?  That navigation bar is a mouse centric waste of space and there needs to be a setting to remove it! “

Yeah – because I ran out of PC politeness … although I did remove one word from the initial draft – that word was “useless”.

Nav bar: Two drop down button menus, and two combo boxes and a search button – all operable by mouse only – because that is how a coder works… with a mouse… and not keyboard short cuts… …sheesh…

Originally shared by Achim Kalwa

There are some entries in Quality Portal about enabling/disabling the Code Navigation toolbar:

https://quality.embarcadero.com/browse/RSP-12398

https://quality.embarcadero.com/browse/RSP-12511

And guess what:

“Closed”, “Works As Expected”.

Comment from internal system: Yes in XE8 the Editor Navigator Toolbar should be visible or hidden, but it has been changed. It works as expected now in Seatle 10. It will work in this way in the next versions

English is not my native language, so perhaps I don’t understand that comment. In XE8 there was a working option to enable or disable that toolbar; that option was removed in D10, and it will not come back with an update? 

And BTW:

Even Embarcadero stuff has problems with the product name “Seattle”. See quote above.

Problems with #10Seattle registration?

Problems with  #10Seattle  registration?

Did anybody else see any problems with the registration of their RAD Studio or Delphi installation?

I just discovered that it has registered my installation to a different email address than my EMBT registered one.  It seems it has used my MS Outlook email address, which is the one that my Windows installation is linked with.  

Does any of you see a “wrong” email address on Help|About?