Leaderboard

Hi there, some of you wanted to ignore specific topics. Well - we are testing this functionality right now. Next to the button "Reply to this topic" you find a new link "Ignore this topic": If you ignore a topic, it will not be listed in any activity-streams. But it will still be included in search-results. An ignored topic is marked with a badge: If you want to "un-ignore" a topic, you will find a link for this: You can manage your ignored topics in your account.settings: For now this should work. Please consider this function more as a "mute topic for _X_ days". Because of the architecture of this plugin, it will not be able to handle hundreds or thousands of ignored topics. So there will be some sort of cleanup - but this part is not active yet. Butf this should be acceptable for us, because older topics will not get that much new content - so they will not disturb you anyway. Let's see how it works. 🙂

Luck, you are not Stefan or Sigmund..

That reminds me of googling for PosEx without adding Delphi to put it into context...

I'm just curious. Do either of you have a stopping condition?

I do have my own clinic, and I could call myself CEO, but not, not in the business. And 10 grand is nothing. The "fixer" would have to try to understand the complete source code, would have to find a solution without rewriting the entire compiler and without breaking anything. Think of a few zeroes more left of the decimal point, and not a few weeks, but a few years. And if things go wrong, he would face a lot of criticims and would probably have to fight for his fees too. And what makes you think you can find someone capable of doing or willing to do it at all? Sorry, I have no idea what you want or mean with the above pseudo-code, or with your "ARC = shared pointers backed by compiler magic". Makes no sense. It may dampen your enthusiasm, but you may want to think about that a little longer. I know what I have said. I don't care about your "ARC but not ARC" ("dead ARC"). I do care about better code generation, but not about laming ARC by not properly counting. I personally find it a pity that they are phasing out ARC instead of improving upon it. But you will not see non-ARC code peacefully coexist with ARC. Your kind of "dead ARC" may coexist with proper (live) ARC (although I even doubt that), but what would be the advantage of carrying along that much dea weight? That would not be an improvement. And of course the compiler/runtime can be made thus that they can be useful. They were almost there, but there were some issues. I'm sure these could have been solved, had there been enough time. And the main advantage would not have been shared pointers, it would have been the opportunity to manually tune records with methods and operators to make them much more lightweight and performant. Shared pointers and some other scenarios would have been a nice side effect. You could write your own refcounted types, including optimized dynamic arrays (these also suffer from the runtime typeinfo/RTTI slowdown). You could have dynarrays with COW without havin to use interfaces. etc.etc. But that is off-topic. Again: there is no indication that an open source team, well paid or not, could or would do better. FPC is already well on the way, so why didn't anyone create a new team, fork FPC, concentrate on the few platforms that make sense and make that great language you want? Because no one wants to pay for it, or has so much enthusiasm he will do it for free or is capable enough. If opensourcing had been a viable alternative, someone would have improved FPC, or a fork, well beyond Delphi already (either by a team of highly motivated and capable enthusiasts, or a team of capable paid developers). And if Embarcadero can build a great IDE and debugger, what makes you think an icnlined team of developers couldn't do the same? So there would be a better Lazarus with a proper debugger, and there would be an incredibly cool compiler and runtime. But obviously that didn't happen yet. Guess why.

I would really appreciate the possibility to not having already read posts that I did subscribe or comment on to pop up again whenever there is a new comment. I know this is how forum software usually works however it gets very distracting if content that I decided is uninteresting to me keeps popping up again.

Does anyone know what does "G" in GExperts mean?

FileExists() has not relied on file ages for many years. The original version of FileExists() did, but it proved to be buggy and gave wrong results at times due to errors while calculating the age, so it was rewritten to rely on file attributes instead (see Why is GetFileAttributes the way old-timers test file existence?), and later to include some permission checks, too (can't access the attributes? If it is because the file is locked or access is denied, the file exists).

Goes to show that I spend a lot of time working with old Delphi versions.

Actually, I had a case where FileExists took more time than I wanted it to because I was processing a huge number of files (the record was 70000 files in 8000 folders. It took forever (about 60 seconds) the first time. See my question here: I managed to cut the original time into a quarter by in addition to finding out if the file exists also getting its file age (which FileExists already retrieves and which I needed later on anyway) and caching it myself. Now the time is down to about 10 seconds on the first call which still sometimes feels like eternity. But as you already said: Every additional call just hits the file system cache and is done in no time.

Not really since TLinkLabel was introduced as a standard VCL control in Delphi XE2.

The Windows file system segments get cached. The first time you call FileExists, it might take a little bit of time to load the segment from disk if it's not cached already. But after that it would run very fast unless you loaded so much stuff to memory in between that it got flushed out of cache. It's not something I'd even worry about. In fact, unless your files are really huge relative to free memory, they'd be cached as well. I don't know if the underlying Windows logic would load them in segment-sized buffers (4k or whatever) or try to suck the entire file into memory at once if it detects that there's sufficient free memory. Windows has gotten pretty darn good at managing its virtual memory. Way back in DOS days, we worried about this stuff. But when you've got gigabytes of free memory and you're loading up files smaller than 1MB or so, it's mostly irrelevant. I've got an app I built a few months ago that loads up all of the *.pas and *.dfm files it finds in an entire file tree ... several hundreds of them. Some are over a MB in size, but the average size is around 80KB. It takes less than a second to load them all from my SSD into memory streams and attach them to the .Data property on a TTreeview. Then it takes 30 seconds or so to parse them all looking for whatever stuff I want using regular expressions. RE's aren't the fastest things to use for parsing data; they're just a heck of lot easier to use than building a dedicated parser. Needless to say, as far as I can tell, the vast majority of the run-time overhead is taken up in the memory manager allocating new objects, copying data identified by the RE parser into them, and adding them into other containers. And in most cases, the biggest delays are caused by the VCL UI components, usually because I failed to call DisableControls on visual components while I'm loading them up. When I do that, UI progress updates are STILL causing the lion's share of processing delays! I mean, I can cut my parsing time in half if I don't want to tell the user what's going on, but that's poor UX design. Most people would rather be kept updated on long-running processes than having them performed in the dark with no idea how long they should take. I cannot imagine how old and slow of a computer you'd have to be running where calls to FileExists would take a noticeable amount of overhead. Maybe a 400MHz Celeron with 256KB of RAM and a 20GB HDD or so. We're talking something from the late 90's. I know there are small SBCs like that are still being used for process-control apps, but even Raspberry Pi's have more computing power than that! I'd urge you to focus on the efficiency of the value-add you're providing, not wasting time second-guessing the imagined inefficiencies of the OS. Get your program working, then look at where it's spending the most time. Most likely, about 98% of the actual execution time is going to be spent in your code or in the UI (eg, VCL). Not the OS interfaces -- unless your app is doing a HUGE amount of interaction with the file system. Even DBMS systems exhibit amazingly low file system overhead most of the time.

Without cross-checking the actual sources to make sure: If you enable Pre-parse Project Files and Persistent Module Information, it should be sufficient to open the relevant projects once to get the necessary information. Currently there is no way to specify some directories to scan as that is most likely a per-project setting. As MMX just recently added some per-project settings stored in the dproj file, there is a good chance for such a feature to be implemented in the future.

Talking about alternative controls: There is also TStringGrid/TDrawGrid + owner drawing. There are various examples on how to add additional controls to the cells. Not sure whether it fits the bill though.

I don't remember ever hearing how the name came to be, but since Gerald was the guy who started the tool in the 1990ies, it's likely that he named it after himself. Time to call it TExperts then... (Just kidding)

Using a TFrame is fine, but you can't combine that with a VCL TListBox. Putting the TFrame objects onto a TPanel or even a TScrollBox would make more sense.

Most likely "Gerald", after Gerald Nunn: the original author

Load into memory, close, then parse is likely wasteful and risks memory exhaustion. I would urge you to choose the simplest solution that meets your needs, at every decision point.

LOL! I mean, coming from you, that is funny. <g>

No, it hasn't. This is a rhetorical technique invented by Bruce McGee to dismiss any evidence of problems in the Delphi ecosystem. It's also a logical fallacy. Whatever unnamed people may have said about Delphi in another time under different circumstances has no bearing on what actual people are saying about Delphi now under these circumstances. "They laughed at Galileo!" has no bearing on criticism that my new perpetual motion machine can't work. No, it's not "going strong". That's simply factually inaccurate. There exists no quantifiable metric that pegs Delphi as "going strong". On the other hand, every quantifiable metric indicates the opposite. Pascal has long since passed its peak of popularity and it's untenable to argue otherwise. Like Marco Cantu repeatedly stating that he disagrees that the .NET ecosystem is stronger than the Delphi ecosystem, if we don't ever acknowledge the problems we can't find the solutions. Or to quote Saul Alinsky, in order to get to where you're going, you first have to figure out where you are. If Delphi was "going strong", the current owner could just pump $100 million dollars or so into hiring new teams to completely rewrite the desktop compilers, buy JetBrains to get their IDE technology, maybe buy Digia solely to get their engineers' cross-platform GUI expertise, etc. In reality, every realistic conversation about what should be done to Delphi acknowledges they have very limited resources devoted to the product and surely not enough to work on major changes to IDE, compilers and frameworks at the same time. MVP Warren Postma, for instance, has related conversations with the Delphi team in which they privately acknowledged the problems with the IDE parser and that it needs a complete rewrite but management refuses to ok the time to do so. That's the reality we find ourselves in and the reality in which solutions must exist.

What makes you think so? I don't see why they should be ugly, limited or inefficient. They would be far more efficient than ARC. ARC routines would have to check if an object is ARCed or not, each time. Code that receives objects must know if it i must free them or not. Etc. Would be a terrible mess and you would be draggin along the refcounts. The refcounting routines might cop out early, but they would have to be called for each access. It ia also a mess for the user. He must constantly invesitage if an object must/can/should be freed or not. They would not coexist peacefully.

If it were so desirable and/or so easy to maintain the Delphi compiler, I wonder why FPC didn't make Delphi obsolete already. I guess because after all there are not so many people capable of maintaining, nor enough people inclined to do it. I also gues that the task is not so easy. I have said it before, and I'll say it again: I use a lot of open source and I love open source and I have participated in open source, but the notion of "open source it so you can always fix it yourself" is pure nonsense. Even if I suffer from some bugs (and indeed, Rio seems to have quite some new bugs and slowdowns caused by the -- incompletely -- removed mrecords, i.e. the runtime changes still affect current code, even if mrecords themselves were removed again), I am not capable nor willing to read the entire (possibly hard-to-read) source code of the entire compiler and then I'm not capable of making a decision what I can safely change without causing a multitude of other bugs. I will leave that to others. I am not so sure there are enough "others" who could or are willing to maintain the Delphi compiler. Nor am I willing to hire someone to fix them for me. People who could do that would probably require large fees too. So no, open sourcing the compiler is useless, IMO. Rather lean on Embarcadero and confront them with "love withdrawal" or other sticks behind your back and let them do it. I agree we need bug fixes and new features. But open sourcing won't provide them. Only pressue on Embarcadero can.

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.