Leaderboard

My comment under the QP request that explains my stance on the matter. I don't want to enter into endless discussion there because it is ultimately the wrong place. @Marco Cantu enabling access to compiler (or any other sources) and allowing community contributions does not mean giving it for free. You can put up any license terms you want. I know that enforcing license is harder than having closed source, but people that will violate such licenses will just use cracked versions anyway - that is far simpler that rebuilding compiler on their own, only handful of developers would go that route. While Delphi compiler code might be worth studying for those interested in compilers, I highly doubt there is any ground breaking technology there worth stealing nowadays. From that perspective opening compiler (or other sources) does not seem like showstopper. @All however, open sourcing (I will use that term, regardless of what the actual licensing model would be) is not as simple as mere dumping source on GitHub. Somebody (Embarcadero employee), extremely knowledgeable in particular codebase would have to be gatekeeper - managing pull requests and communicating with community in general. In order to open sourcing to be successful endeavor there must be significant number of contributions made, without that - the whole thing makes no sense for Embarcadero (and for the community as well - beyond satisfying everyone's curiosity). In that case gatekeeper(s) will have their hands full. Not to mention that for every successful contribution, there will be countess others that will have to be reviewed and rejected for various reasons. That part introduces additional cost to Embarcadero and ability to develop code on their own, because part of the resources that would be used to developing in house will have to be spent for community interaction. Eventually, gains from community code can outweigh the costs, but that would take some time. Also, in code base that large, it may take years for community to start contributing in meaningful manner. And gate keeping would have to start immediately. There will be developers that will jump in from the start trying to fix their pet pevee without looking at bigger picture (breaking things like bull in a china shop). Now, that might look like - it it would take long time, let's start early then... but like I said, initial cost in terms of resources might be too high. Especially, now when there is a lot of work to do on various compilers - new ones (Android and macOS 64bit), including introducing some new features that are already in the works. From that perspective, open sourcing compiler in general... yes, but I don't think now (or any time soon) would be the right time. Right now (or soon enough), opening up sources to RTL/VCL/FMX would be much better move - we already have the sources, we already know our way around them. Community at large can more successfully contribute to those sources than to the compiler. Again, that kind of project would also have some initial cost, but I believe it could pay off much sooner. Open sourcing is the double edged sword - in order to be successful it takes resources that would otherwise be spent on in house development (with much higher initial progress rate). But the push for open sourcing (because, of the illusion that community can fix things faster and better) is greater in times when internal resources are spread thin, than in the times when everything works peachy. So it is kind of damned if you do damned if you don't situation.

It could be an option to have a (restricted access) repository somewere with the RTL/VCL code where "the community" collects patches for everybody to use. But that poses several questions: Which versions of the RTL/VCL are maintained there? Only ever the latest one? But what about people who are stuck with older versions for whatever reason? What about forward- and backporting fixes if multple RTL/VCL versions are maintained? Who maintains it? This/ese person(s) would be the gate keeper(s) to proposed patches. Who grants / revokes access and on which criteria? Is every Delphi customer allowed access, even if he only ever bought Delphi 1? Or is it restricted to the version(s) he bought? How does he prove that? Even if only the latest RTL/VCL is maintained, what about the .x.y Delphi releases? These are of lately only available to customers with subscription. I think that could be quickly become a nightmare for the maintainer(s), not just the technical issues, but even more the legal issues.

I know that, but how many successful pull requests have you gotten into RTL/VCL/FMX so far?

Hi All! The NexusDB Easter Bunny has gone off the deep end and is having a 40% sales on all new licenses from now until the 26th of April. Yes, that is 40% off our NexusDB database products, and our Nexus Quality Suite! Hurry and secure your licenses before the Easter Bunny hops, skips and jumps into never ever land. To get the rebate, make sure to enter the coupon code 2019EASTER during checkout. Our Web Store: https://www.nexusdb.com/support/index.php?q=pricing regards, The NexusDB Team

You shouldn't put checks for parameter validity in every method. Your code will just be full of that and you will drown in clutter.

Yes, but sometimes it takes several iterations for some fix, or needed feature to end up in release. And patching on your own takes time. If everyone has to do it that is huge waste of time.

The sources of the libraries are already "visible" for customers.

Very insightful and concise @Dalija Prasnikar. I would even go so far as to say: The compiler is not the issue, it's the libs (RTL/VCL/FMX) as you said, but also the IDE that might profit of opening up, and still there would have to be a team of code reviewers that would do nothing but prevent crap faulty/low quality code from getting into the base. Not sure if Embarcadero would want to make that investment.

GExperts adds a button which opens an explorer window. You still can't copy the full file name though, just the directory. But adding a read only edit field would be possible too...

New version 13.3.0 released! + TMiTeC_Startup entries extended to full version info + TMiTeC_SMBIOS tables 16,22,39,41,43,204,219,221 detection added + SMBIOS 3.2 compliance added + TProcListMonThread process priority class and affinity added + TProcMonThread process priority class and affinity added + ROM BIOS Explorer enhanced (version 2.0) + Device monitor volume connect/disconnect event now correctly returns multiple drives For more information about the library, download locations and documentation, see the MiTeC System Information Component Suite Home Page

Note that C++11 addes the 'override' keyword to the language, and its use is highly recommended to discover typos at compile-time. If a derived class method wants to override a base class virtual method, an explicit 'override' allows the compiler to validate that the overriding method actually matches the signature of an available base virtual method, if not the compile fails. Without the explicit 'override', a mistyped overriding method would be an overload instead, which can lead to logic errors not detectable until run-time.

Thanks for the link to the article, but it does not answer this question, as the results from this search field are completely UNRELATED to this dialog: In fact, the hints popping up from this search field are related to other IDE dialogs. So this search field seems clearly a colossal BUG. Having a search field in this dialog searching e.g. for options is more or less useless as there are only a few options in this dialog: Much more useful in this dialog would be searching/filtering the package names in the current list. I cannot imagine the kind of deep mental confusion which obviously led to this particular BUG and UI disaster.