Bill Meyer

17 hours ago, Georgge Bakh said:

Again, I didn't stated that it's simple. I know that dealing with broken code is hard.

But it should be a code tools developer problem. Not users.

Refactoring is rarely simple, but it is essential. Redesign can be even more of a challenge in legacy code, as there tends to be a lack of documentation, and often poor naming practices obfuscate the purpose of the code.

I don't see any way that the IDE could be held responsible for performing to overcome the creation of developers. 

17 hours ago, mael said:

When using components or libraries, I think it is poor practice to include them in your projects, since they are shared files. They should be compiled independently to ensure you use the same version and state everywhere. All major Delphi components work this way, and you don't include the RTL or VCL units in your projects, either.

 

When placing components on the form, this should work seamlessly, and not require editing project specific library paths (or the IDE should do it automatically).

 

The IDE is just buggy regarding code completion and parsing, to more or less severe degrees depending on the version. This scenario is a very standard one, and should work.

I was not speaking of components or libraries. But all of the units you write for your application should be in the DPR. Relying on the search path does affect the IDE, whether we like it or not.

Yes, there are defects in the IDE with regard to Code Completion and Error Insight, but following lazy practices which can be shown to exacerbate the problem is just foolish.

19 hours ago, Georgge Bakh said:

I didn't say that dependency cycles are a good thing. I trying to avoid them myself. But it is not always possible due to lack of a bigger visibility scope than unit.

But I still think that code tools should not break or slow down with unit dependency cycles.

And I know what I'm talking about as writing pascal code tools is my current pet project.

I think there is never a good reason to tolerate unit dependency cycles; they are a consequence of bad design.

Again, if you do not see why unit dependency cycles should slow the tools, there is much of the internal action of the IDE which you do not appreciate. As Anders Hejlsberg said in the video I cited earlier, "...as soon as you type a character, you have broken the code." That is meant no literally, but in the sense that any new character in a code file provokes rebuilding of parse trees.

It's good that you are getting your feet wet. I have been developing tools to address these issues for the last couple of years, not as a pet project, but a part of my current employment, and I assure you, it is not nearly as simple as you seem to believe.

6 hours ago, Lars Fosdal said:

On the topic of unit dependency cycles, I tend to view them as a design weakness.  It is a quick workaround for properly designing with DI and other tools that eliminate unit inter-dependencies. Yet, working with code that has evolved over a long time, they can be hard to eliminate as they are so deeply ingrained.  We have one particular unit that causes a compiler internal error whenever we change something in its interface section and do a compile in the IDE.  At that point only a Build All resolves the problem.

There is little question that they are a design weakness. In fact, that is a gross understatement. The apparent need for such cycles is a clear indicator that some units contain things which should be separated. Often a class has become a Swiss Army knife, providing too much functionality, marginally related. That's bad design, and substantial refactoring may be needed. The same pathology can be introduced, however, in simple procedural modules, where once again, too many loosely related elements are kept together.

Unit dependency cycles:

• are multiplicative, so should be eliminated as early as possible
• exact a penalty in build times, and in one major project, I have seen exponential increase in build times as new modules are added, using the old
• render code analysis difficult, at best
• are often difficult to remove, as they usually require redesign

I have observed that unit dependency cycles are often commonplace in legacy code projects. Further challenges lurk where such tangled modules have been recycled into new projects.

51 minutes ago, Georgge Bakh said:

Honestly, I see no reason why these things should cause slowing down or breaking of code tools.

Code tools must work regardless of code style used.

As to the class constants, I must assume it is a defect in the IDE which is tied to the parser used for code completion.

In my comments, I did not say that the tools do not work; I did identify factors which affect performance. There may well be other strategies which might be applied to avoid the issue with search path, but I consider it poor practice not to name all your own units as members of the project.

Unit dependency cycles are a whole other issue. I can suggest you watch Anders Hejlsberg's video on modern compiler construction. Or just consider with a whiteboard what happens with a small collection of units (A, B, C, D) when:

A uses B, B uses C, C uses A and B uses D, but D uses A and B. It's a mess, and when you consider a larger application, the mess is multiplicative.

If you see no reason for the result, I submit you may have spent little time understanding the process. I have spent a number of years dealing with legacy code in large projects, and untangling things is a challenge.

I've read many complaints about speed and stability of the IDE. And I have made many such complaints. But in fairness, I have seen in large legacy projects that there are many things we can do which undercut the performance of the IDE. For example:

1. Leaving units out of the DPR, relying on the search path. Slows code completion.
2. Declaring const field members in a class. (D2007) Breaks code navigation below that point.
3. Accumulating unit dependency cycles. Slows IDE response, but also slows the compiler on full builds.

There are other "thoughtless coding tricks" which may also contribute to poor behaviors, but those three are big.

Also, how many third-party components have you installed? Are they all solid and stable? That has been a risk area since D1.

On 6/24/2019 at 8:23 AM, Daniel said:

Interesting. I'll look into this.

On  further experimentation, I see that the behavior is specific to Firefox, and does not happen on Chrome. Perhaps is it an effect of privacy settings?

I have updated my settings to disable notifications, yet I keep getting the dialog where I am invited to accept notifications, whenever I come to the site. It becomes annoying.

On 6/13/2019 at 12:16 PM, David Heffernan said:

Python documentation is excellent. Likewise C# documentation. And so on. Delphi is an outlier here. 

I've no doubt Delphi is an outlier. The powers that be clearly failed to recognize that the books in the box represented a significant fraction of the value of the product.

Also, there are numerous products for which "documentation" means simply a reference manual, and though such is essential, manuals discussing usage and library application are also important. Delphi once had an array of volumes, and they made it much easier for newcomers to the language to be productive quickly.

16 minutes ago, Lars Fosdal said:

I wish the various Json classes were better documented.  http://docwiki.embarcadero.com/Libraries/Rio/en/REST.JsonReflect is particularly poorly documented with regards to marshalling, interceptors and converters.

I have long been wondering if the TJson.JsonToObject<T>(aJsonString) can be made to handle mixed type arrays {"list": [5, "text", {"prop": "value"}]} by injecting converters, but it seems impossible - but then again - the above mentioned tools are undocumented.

To remember when things were documented is to be old.

15 minutes ago, Joseph MItzen said:

Embarcadero can't fire him; Idera purchased EMBT and he was the person Idera picked to oversee Delphi. I'm not sure this was his idea either. I heard it was Michael Swindell who came up with the Delphi Pro EULA change (as well as the bogus 3 million users figure) and he's not only still there, he's listed as "Senior Vice President of Marketing and Product Management".  Let's not rule him out as a suspect.

Also keep in mind that they've told us for 20 years now that we don't understand marketing. Perhaps not -- I certainly do not understand THEIR marketing. But in my career I have learned a good deal about customer retention.

According to LinkedIn, his title is now: Mergers and Acquisitions Executive Advisor at Embarcadero Technologies.

And that does not seem to be marketing.

52 minutes ago, PeterBelow said:

Keep in mind that the IDE uses a different desktop while in debug mode. Move the IDE back to the other monitor and then save the desktop and make it the default debug desktop, that should fix the problem.

Smacked myself on the forehead over that. Thanks.

Installed Delphi 10.3.1 Starter Edition the other day on my personal machine. Although the experience so far is generally positive, I note that with the IDE on my screen 2, when I run my app, the IDE moves to screen 1, and the app opens there, as well. Thoroughly unpleasant behavior, and quite unexpected after so many years of multi-screen operation in Windows. I see RSP-12271 and RSP-12956. The earlier case is now nearly 4 years old. One might think such a behavior would get quick attention.

10 hours ago, Berocoder said:

I just wonder why not people using VmWare or similar virtualisation for Delphi? Then you never have to move to a new computer and this problem is gone. A VM have also other advantages.

Many do use VMs. Many did not in the days of D5..7.

2 hours ago, Joseph MItzen said:

It's a horrible, horrible outfit that's little more than a self-publishing firm that takes a large percentage of your sales and does nothing in return.

As with most generalizations, there is probably some truth in your comments.

That said, the relatively small number of books I have acquired from Packt have been better than average. In particular, they have done a very nice job with e-books, which for code, are notoriously difficult to format well.

Very few publishers will consider a Delphi title any more, so self-published books and books from Packt or perhaps Manning are among the few available resources. Packt also publishes some very capable authors, and I certainly number @Primož Gabrijelčič among them.

Self-publishing is not a valid condemnation, either. Our own @Dalija Prasnikar published a very worthwhile volume on memory management in Delphi. (Full disclosure: I did assist with proofreading and editing on her book.) Equally, some self-published books on Delphi have been pretty disappointing.

Software development books appear most often for well marketed language tools, whether they are expensive or free. One metric I have watched is price per page. When that goes higher than five to eight cents, the book better be excellent. Sadly, that is not often the case.

Maybe. But I thought I remembered having been able to "buy" a free special at the $0.00 price in the past.

10 minutes ago, Daniel said:

😉 I am feeling a little stupid here. But how can I download this book? There is an option to *buy* the E-Book for 9,99 USD. Maybe this would be the way to go for a download?

Do you have an account registered? That may be the key to getting the free download. I've found the site a little confusing, but once you have a title, you have it registered under your login, and can access it repeatedly.

9 hours ago, Der schöne Günther said:

I still don't get quite behind that language server thing.

Worth watching for insights into the value of a language server:

3 hours ago, Uwe Raabe said:

I am not sure they would get away with that - at least here in Germany. As long as the customer actually paid for the perpetual license (this excludes the CE), the ability to use it legally cannot be prohibited just because there is no current support contract. At least a reasonable fee for the registration bump would perhaps be acceptable, but definitely not denying it completely.

The history of stupid licensing conditions in the USA is as old as shrink-wrapped EULAs. The one ray of hope was the original Borland "just like a book" policy. 

2 minutes ago, dummzeuch said:

That's one reason I have switched "my" license to using a license server. No problem with having to increase the registration count any more.

Had an unpleasant experience with the license server last year, which necessitated a new slip file. Although the license shows perpetual, there is a subscription expiration date in the license, and that seemed to be an impediment if it became necessary to install new, as in creating a new VM.

Also, the license server "solution" requires that Delphi be able to reach the server at least every 30 days.

Wow. Masterful marketing. This will make it easy for any who have considered dropping off to do so.

For years, we have  been assured that developers simply don't understand marketing. That may be true, but clearly we are not alone in that deficiency.

On 5/17/2019 at 9:11 AM, Rollo62 said:

So how to solve this paradox of the most valuable company in the world ?

"Most highly valued" is not equivalent to "most valuable."

16 minutes ago, Mike Torrettinni said:

You have a point there, but I'm a sole developer on this project, so I don't have this problem.

Coming into a project which has built for years on the philosophy that a "sole developer" could deal with things, and then success led to 10 or more developers, I have to say I think it is best to plan for success. Legacy code is too often very ugly.

On 5/4/2019 at 12:23 AM, Andrea Raimondi said:

Use RAPWare and all your nightmares will be laid to rest. 

Not an option for me at this time. The current solution seems to work correctly, but with an attachment, and where Outlook is the default client and gmail the recipient address, there is a second, phantom attachment. It proves to be 32K of memory image. Where the default client is Thunderbird, or where the destination is not gmail, we do not see the phantom attachment. Also, the phantom does not exist unless we pass a recipient address in the call to send MAPI; if we pass only the attachment name(s), then no secondary is created.

3 minutes ago, Fritzew said:

Hey, they need to earn money somewhere? Do you work for nothing?

Linux is free, not Delphi. If people want to pay for Delphi to build software for Linux, let 'em. So long as Delphi Pro is not free, I don't see that it is "work for nothing".