The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,860 other followers

[RSP-10484] GetIt shouldn’t block the IDE – Embarcadero Technologies

Posted by jpluimers on 2019/01/24

I was amazed that this was marked as “Closed; won’t fix” as every respectable IDE I use but Delphi has a package manager that by now can download and update packages in the background without blocking the IDE [RSP-10484] GetIt shouldn’t block the IDE – Embarcadero Technologies.


PS: First comment at G+ [WayBack] I was amazed that this was marked as “Closed; won’t fix” as every respectable…:

Getit is pretty useless as a package manager.

One Response to “[RSP-10484] GetIt shouldn’t block the IDE – Embarcadero Technologies”

  1. Peter Wright said

    Ooh – advocating changes in Delphi. Such heresy.

    Change-control procedures that I’ve experienced roughly follows the procedure – proposal, implementation, testing, sign-off, publication. It’s really impossible to FORCE the proposer to sign-off the change, so it can be closed by the implementor as an escape.

    EMBT’s version, in the rare circumstance that they react positively to a proposal, appears to be implementation, implementor-signoff, publication. More often, it’s deny, baulk, delay, close and ignore.

    I asked for some support from ADUG (Australian Delphi Users’ Group) for a number of proposed changes (RSP-13776 – RSP13781). The only response I received was from two correspondents who actually took time out from their busy days to reply that they WOULDN’T be voting for these changes as they are “really non events”.

    Now they could have just ignored my post as did everyone else – but “non events?” Well – trivial changes. Easy-to-implement. Having no great impact. And deliberately so. It’s clearing the decks for the grand plan.

    And support? Let’s take 13777 as an example. Despite the generally positive responses after Vincent Parret’s post and on the Wiert Corner, the proposal has gathered a grand total of FIVE votes in three years.

    And 13781 – extending CASE. “Closed”. 0 votes. Yet one of the items suggested as a development in EMBT’s surveys at some point. And making it case-insensitive is as simple as CASE uppercase(stringname) of…

    The criticism? “Impossible. You can’t compare floats with discrete values”. That opens a can of worms. RSP-13792. Resolved “Won’t fix”. Closed. 0 votes. Root cause: The Delphi implementation of a floating-point comparison is faulty as it always compares against an EXTENDED constant, regardless of the type of the variable. Fix that (RSP-19169 – 0 votes) and case-on-floating-point becomes possible to implement.

    And BTW – case var of 3.069..3.071 would happily detect var=3.07 which should take care of the accumulated approximations.

    Arguments about the philosophy of comparing floating-point values to constants assume that the programmer is still wet behind the ears and have no place in the implementation of the language. Sure – produce a warning or help message if it makes you feel better. RSP-13780 (0 votes) may assist. And perhaps develop that into {$WARN W1057 OFF METHOD} to turn the warning off temporarily (for the duration of the method) – Oh – and I’m using “method” here in the light of RSP-13776 (1 vote).

    RSP-13780 “{$WARN IMPLICIT_STRING_CAST OFF}” you should also be able to use “{$WARN W1057 OFF}”. I’m talking to myself – no reaction. In private correspondence, Marco Cantu rejected this suggestion claiming it was not a language-independent solution. So – W1057 is NOT language-independent, but IMPLICIT_STRING_CAST OFF is?

    So – why all the trivial changes? Because if I was to reveal my grand plan – the deprecation of the interface section (and with it, the parallel-maintenance chore with the implementation section) well, that would enough to give the doubting Thomases mass heart attacks.

    And when? Well – the sooner, the better. The more development that takes place in deviant platforms like OSX and Android, the bigger the job will be.

    I had considered presenting my proposals for a revised Delphi syntax at the ADUG symposium, in late May 2018 in Perth (and Melbourne). No keynote speaker had been announced and unfortunately, without the attendance of a receptive EMBT representative, all of the preparation work for such an event would be wasted as it would have as much impact on the Delphi world as our monthly usergroup meetings.

    Receiving JIRA notifications of closure activity seems to be symptomatic of an upcoming release. Well-overdue IMHO given the problems reported with Rio, but now 3 months on – dead silence.

    I received a couple of emails about RSP-21734 (IDE splashscreen fails to report installed packages). Not particularly important, but some assuranece that expected packages have been located. I actually reported this in October, 2015 but was told by “Developer Support” that his new machine is so fast the splashscreen just “zips by.” This was of course despite my having told him that I’d found a way to switch the appearance of the splash-screen on and off. Same person (an EMBT MVP) also claimed that the component toolbar was “deprecated” (IOW, he prefers to use the new pallette).

    So the response I received to 21734 was “No, a package can register itself with an interface to display data in the splash screen, but there is no list of all packages automatically there” – my complaint was that the installed packages (I didn’t explicitly say FastReports, Indy and others I use like Nexus) were not being shown, not that “ALL PACKAGES” should be shown. Marked as “Resolved” (No it isn’t) and “Works as expected” (No, it doesn’t.)

    And furthermore, the missing splash-screen items magically re-appeared after I’d added a few more packages.

    Well – I’ve had enough. I’m simply not going to go on paying $500 per year for this kind of treatment. I’m not using Delphi commercially any more anyway – it’s just another example of a product that could have been so good if only it was handled properly. Not the first time I’ve encountered this, and unlikely to be the last.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: