Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 04/27/19 in all areas

  1. Lars Fosdal

    Forked VSCode for Delphi

    Totally agree on the lure of RAD UI design and how it causes newbies to write code that is both relying on states in the UI as well as in their business model, instead of the UI reflecting states from the internal model and delivering changes to that model. As far as possible, I try to write my code without a UI, and I try to make the interfacing between the internal business logic and the UI as simple as possible, with the UI as far as possible being oblivious about why its values and settings are what they are. I often have separate reusable classes as glue between the UI and the biz objects, so that they remain isolated. The debugger is not fine when you venture past 32-bit single UI thread. The 64-bit Delphi debugger leaves so much to be desired, that it is better to do the debugging in a 32-bit version of the app. Multi-threaded debugging - combined with anonymous methods - often causes also the 32-bit debugger to stop working - such as not resuming after a break, or no longer breaking where it was supposed to. Debugging code that runs multiple identical threads is a challenge as there is no simple way to specify that you only want to debug a specific thread instance.
  2. David Heffernan

    The Android 64bit deadline warnings have started

    Sure it's down to a lack of resources. But that's a consequence of expanding to new platforms. Each additional platform comes with a maintenance cost. That cost is paid for out of revenue. The bulk of the revenue comes from customers that are using the legacy platforms. If Emba continue to neglect their core business (Windows development tools) then eventually customers will look elsewhere.
  3. Remy Lebeau

    DynArraySetLength exception

    Yes, exactly. It needs a write lock, not a read lock. Yes, you are wrong. A read lock allows multiple threads to read shared data at the same time. A write lock allows only 1 thread at a time to modify shared data. Since you are modifying data (adding a new string to the TStringList, thus modifying its internal memory array and its Count), you need a write lock. You are getting an AV because your read lock is allowing multiple threads to modify the TStringList at the same time, trampling on each other's toes, so to speak.
  4. Earlier this week a long-time customer asked me why FastMM allocates large memory blocks from the top of the memory and if that option could safely be turned off. Their reasoning was that such allocations are much slower than normal ones. The question surprised me as I didn’t know of any such difference in speed so I did what I usually do–I wrote a benchmark application and measured it. TL;DR Yes, allocating from the top is slower. No, the difference is not big and in most cases you’ll not even notice it. There were, however, other interesting results that my simple benchmark pointed out. More on that in a moment, but first… Allocating from bottom and top In Windows, the code can ask for a memory block by calling VirtualAlloc with flag MEM_COMMIT and Windows will give you a suitable chunk of memory. This memory will usually be allocated from the start of the virtual memory visible to the program. The code can, however, call VirtualAlloc with flag MEM_COMMIT OR MEM_TOP_DOWN and Windows will return a block from the end of virtual memory available to the process. In a typical 32-bit Delphi program first such memory block will have address close to $7FF00000 (but a bit lower). You may want to allocate memory “from the top” if your program has two very distinct modes of allocating memory and you don’t want to mix them. For example, a frequently reallocated memory could come “from the bottom” and large blocks that are used for long periods of time “from the top”. This can reduce memory fragmentation, but the potential advantages are specific to each program. In other words – maybe it will help, maybe it will hurt. Another good scenario for MEM_TOP_BOTTOM is testing 64-bit code ported from 32-bits. For example, a typical “from the top” allocated block in a 64-bit program will have an address like this: $7FF4FDE30000. If your code at some point stores pointers into 4-byte integers, part of the address will be lost and as soon as that integer is converted back into a pointer and the code accesses that pointer, you’ll quite probably get an access violation. If a memory comes “from the bottom”, such problems would not be so easily detected. FastMM4 allocates large blocks (with sizes greater or equal to 258.5 KB) “from the top”. If I recall correctly, this was done to prevent memory fragmentation. Additionally, it can allocate all other block “from the top” if you define conditional symbol AlwaysAllocateTopDown and rebuild. (You have to use FastMM4 from github instead of the built-in Delphi version to use this functionality.) You can use this mode to test 32-bit programs ported to 64-bit code. MEM_TOP_DOWN is slower? The article my customer pointed to claimed that allocating from the top works much slower than allocating from the bottom. Even worse, the allocation algorithm was supposed to work in O(n^2) time so each additional allocation needs more time to execute. To top that off, the official documentation for the MEM_TOP_DOWN flag mentions: This can be slower than regular allocations, especially when there are many allocations. To verify that claim, I wrote a trivial benchmarking app (download it here). It allocates from 1 to 6000 blocks of size 264752 and measures the time needed. Block size 264752 was picked because at that size FastMM4 starts allocating memory “from the top”. 6000 blocks can safely be allocated in a 32-bit application (6000 * 264752 = 1.5 GB). In my tests I could allocate 6105 such blocks before I ran “out of memory” but just to be on the safe side I reduced the number in the released application. Results, measured on my fresh new notebook with a i7-8750 processor, were much closer to my expectations than to some O(n^2) algorithm. The “Top” algorithm is slightly slower (needs more time to execute) but the difference is not drastically large. What’s going on then? Is MEM_TOP_DOWN slow or not? As it turned out, the article I was referring to was written in 2011 and Windows have improved a lot since then. I don’t know which Windows version has fixed the “top allocation” problem, but it definitely doesn’t appear in Windows 7 and 10. Another interesting result is that the first 200 MB (approximately) are almost “free”. Somewhere around that number, the execution time jumps from around 3 ms to 50 ms and then continues to grow in more-or-less linear fashion. The benchmarking program measures each test only once and is therefore very susceptible to measurement errors but the result clearly shows an O(n) algorithm. Why are allocations smaller than 200 MB so fast? I’m guessing that Windows maps such amount of physical memory into the process’ virtual space when the process is started. When you exceed that limit, the allocator needs more time to allocate physical memory and map it into the process’ virtual space. That’s, however, just a guess. If you know better, please let me know in the comments. How fast are YOUR allocations? Just for the sake of completeness I rerun tests on my main PC (HP z820 with two E5 Xeons) and the results completely surprised me. The shape of the curve is almost the same–but notice the difference in speed! On the laptop, 4000 allocations execute in 250 ms. On the Xeon machine, over 1000 ms is needed for the same job. This machine is quite old (around 4 years IIRC) and it obviously contains a much slower memory. I know that computers can have faster or slower memory chips, but I never expected to see such a big difference in VirtualAllocspeed. (And yes, both machines are running latest Windows 10.) Now the whole shebang started to interest me even more, and I did some further tests on a few PCs used by fellow programmers. All of them were running Windows 10. As you can see below, there is some difference between them but none are so slow than my main computer 😞 Maybe the time has come to upgrade… If you want to download raw data and compare it to your own results, you can access it here. MEM_TOP_DOWN or not? The difference in speed is not that big–and most programs will not notice it–but I have to agree with the customer. The time has come to remove hard-coded MEM_TOP_DOWN from FastMM4 and replace it with a conditional {$IFDEF AllocateLargeBlocksTopDown}MEM_TOP_DOWN{$ENDIF}. I have created pull request for that change: https://github.com/pleriche/FastMM4/pull/75 (Original blog post: https://www.thedelphigeek.com/2019/04/fastmm4-large-memory.html)
  5. Rudy Velthuis

    Forked VSCode for Delphi

    Most of the time you write code. But sometimes you do need a form designer, and if you don't have it, things get very, very tedious. If you want to code FMX, this gets even worse. I may be biased, because I have been using it since Delphi 1 was released, but IMO, the code editor is fine. I have used many many other editors, on different platforms (DOS, OS/2, Windows, macOS, Linux), but I don't think they are much better. Especially the Delphi editor is the best to search code, to search implementation and everything else that only can be done with a dedicated editor. Other editors may have some niceties, but in my experience, they don't weigh up against the many conveniences a dedicated editor provides. I don't care about themes or languages like python or JavaScript in the Delphi editor. And the dedicated debugger in the Delphi IDE beats all others.
  6. Stefan Glienke

    Forked VSCode for Delphi

    I guess you are a bit naive in your assumption of what it takes to get from something like VSCode to a fully featured IDE like RAD Studio or Visual Studio... Because otherwise why is there still that thing called Visual Studio that MS is putting significant resources into it if they could slap a few extensions onto VSCode?
  7. A.M. Hoornweg

    DPI-change, crashes tDrawgrid.

    I have found the core of the issue. When a form receives a wm_dpichanged message, TCustomForm.WMDpiChanged is called which scales all components on the form. But TCustomGrid does it in a terrible way; there's this simple loop that modifies the heights of the rows: [vcl.grids, TCustomGrid.ChangeScale(), line 1735] for I := 0 to RowCount -1 do RowHeights := MulDiv(RowHeights, M, D); and in the debugger I see that this loop needs a whopping 72 seconds to complete on my Core i7 notebook (for 86400 rows). The reason? It appears that the changing of a single row height triggers an InvalidateGrid() plus an update of the scroll bars (which, incidentally, is why my breakpoints kept landing in USER32.SetScrollInfo). And all of this happens inside the handling of a wm_dpichanged message, so the message queue is blocked for ages which freezes my desktop.
  8. Sherlock

    Decorating read-only controls

    Ah...beauty. That comes at the very end of the process. Usability should be main concern which will result in an overall positive UX. Beauty is just glitter and bows and ribbons. Good usability, however, is measurable. Alas this process of measuring is time and resource consuming. Not many managers are willing or even capable of spending money on this, reckoning that usability will improve itself over time. Sadly, more often than not the opposite happens.
  9. David Schwartz

    Anon methods passed as event handlers?

    In 1961, when Pres. Kennedy announced that mankind would go to the moon by the end of the decade, there wasn't a single person alive who knew how to do it. When Henry Ford told his engineers he wanted an 8-cylinder engine, there was nobody alive who believed it could be done. And here you are redoubling your efforts to explain to me in ridiculous detail why the simple thing I want to see possible at the source code level is impossible to do. The purpose of the compiler is to hide complexities like this from the user. Automatic reference counting wasn't viable ... until it was. Generics weren't considered viable ... until they were. There are so many things that people thought would be "nice to have" but weren't considered viable, and at the time there were perfectly valid technical arguments that were made about why they weren't either practical or even possible. Until they were. A lot of contemporary programming languages support stuff that Delphi could support, but there needs to be the willingness on the part of the folks who maintain the Delphi compiler to actually embrace them. Delphi was revolutionary when it launched, but within a few years, it got stale, and the language has only improved slightly (IMO) in ways designed to appease the marketplace just to keep people from bailing out to other platforms entirely. C# has so many cool language features that I doubt we'll ever see in Delphi. I don't know why, because adding new language features to a product that's supported by pretty hefty annual fees makes a lot more sense than adding features to a product that's mostly funded by other product sales (as most of Microsoft's language products are). I mean, what incentive does Microsoft have to keep adding new features to a language that generates relatively small revenues? For one thing, you can argue customer lock-in. For another, newbies want to hitch their wagon to technology that's more leading-edge rather than stuff their parents or grandparents used. I'm really not interested in the technical reasons why this suggestion isn't possible today. Just like I'm not interested in justifications why you can't use strings in case statements in Delphi while most other languages today allow it. There has to be a willingness on the part of the vendor to add these sorts of upgrades to the language instead of defending their absence, which is the normal case with Delphi. You're just defending the status quo. BTW, C++ was introduced about 10 years before Delphi. The first ANSI standards effort for C++ started about the same time Delphi was introduced. And now they just approved the 3rd iteration of the C++ standard, with work progressing on the 4th iteration. Meanwhile, Delphi has hardly had anything new added since the first C++ standard was released. People pay Embarcadero a lot of money every year to maintain and upgrade Delphi. The backlog of bugs keeps increasing, and the language enhancements progress at a snail's pace. What are we paying for exactly? Most of what we get are lots of technical arguments about why this or that language enhancement is not worth considering, while job reqs for Delphi dwindle and vendors want to hire people with experience using the latest language features that aren't even on Delphi's radar. Why in the world would anybody want to choose Delphi to develop a new product with a 10-15 year life span today? All the jobs I find advertised are for maintaining legacy apps. Where's the NEW product development happening with Delphi? Why would anybody want to hitch their wagon to an old, stale technology that's so far behind the language technology curve?
  10. Rudy Velthuis

    Forked VSCode for Delphi

    Like the late Ed Mulroy (TeamB) once wrote:
  11. Leif Uneus

    Forked VSCode for Delphi

    The code editor works for me. I still use the Wordstar keyboard shortcuts as I did in the beginning of the 80s, programming in CP/M and then the MS-DOS environment. I turn off code completion, since that slows down typing and disrupts my intention more that it helps. My fingers do the typing, while I can concentrate on the code. The form designer is ok for layout. But there is one big shortcoming with how it lures a novice programmer to make a mess of separating the GUI from business logic. I wish a more sophisticated default scheme would be introduced to handle that. The error insight function is best turned off as well, since it introduces more doubts than it really helps. Comparing code is easy with the Beyond Compare plugin. The integration with different types of code repositories could be better. The debugger is fine and with the use of FastMM memory leaks are easy to find and remove. The biggest concern for me is not the state of the IDE. Every new version introduces errors in the compilers and the RTL. Using a new version in a 24/7 application is out of the question. I wish all Embarcaderos efforts could focus on bringing out quality compilers comparable with industry standard C++ compilers and a RTL that can be trusted.
  12. Uwe Raabe

    New VCL Style from DelphiStyles.com

    Indeed - and DelphiStyles has shown to be a competent and reliable partner for that. Highly recommended!
  13. Lars Fosdal

    New VCL Style from DelphiStyles.com

    We sure do, because this makes me cringe. Too much clutter. That said - I also hate the currently popular naked "flat UI" design philosophy which takes away most UI guidance and makes you guess if something is a link, a button, or just text - and you have to hover and/or click in the right places to find out.
  14. Georgge Bakh

    I-Pascal 2.0

    I-Pascal v2.0 has been released. What is I-Pascal? It's a Pascal language support plugin for IntelliJ IDEA. Integration with Delphi and Free Pascal Compiler. The main goal of the project is to provide modern code editing and inspection tool for Pascal language. Dependency cycles ready. In the new release: Completion options from not used yet units (with automatic modification of uses clause) Completion itself is improved and not is comparable to one for Java Delphi 10.3 inline declarations syntax support. Highlighting, find usage, renaming etc. No inherited destructor call inspection Project site: http://siberika.com/ Installation instructions: http://siberika.com/install.htm Source code: https://github.com/casteng/i-pascal
  15. A.M. Hoornweg

    DPI-change, crashes tDrawgrid.

    Done, https://quality.embarcadero.com/browse/RSP-24430
  16. Hooking events in the Delphi IDE is dangerous, as you never know whether there already is another plugin that uses the same event. I tried to describe a way to make that process a little bit safer and blogged about it: https://blog.dummzeuch.de/2016/03/28/safe-event-hooking-for-delphi-ide-plugins-revisited/ But it's not just other plugins you must be wary about. New versions of the IDE might also start using previously unused events. E.g. Delphi 10.3 is now using the previously unused Screen.OnFormChanged event, but only within the Options dialog. This broke some of the GExperts enhancements to this dialog and those dialogs opened from there, in particular those for the path edit dialog.
  17. dummzeuch

    Decorating read-only controls

    My gripe is not with whether it looks pretty or not, but whether it's usable at all. To get back to the original post's topic: A visual clue that a control is read only, would be nice. But Windows 8 and later 10 ruined that (and that's far from the end of the visual catastrophe these versions introduced). Or take web sites: It used to be that links were easily recognizable with blue text color and underlined. The first thing that disappeared was the "ugly" blue color. Then web designers also removed the underline. Nowadays you only know for sure that something is a link when you click on it. Or one example from non software related design failure: The controls for a faucet (Deutsch: Armaturen) used to show with a blue or red dot that was easily visible whether you turn on cold or hot water. Today these dots are still there (not sure whether that's required by law), if you either know where to look or crane your neck to find them. Apparently somebody decided that they spoil the look of the thing, so they are now hiding them. I'd like to know how many people accidentally get burned because of this.
  18. uligerhardt

    Anon methods passed as event handlers?

    No, that's why I'm talking about class methods. You can use them like this: type TMyEventHandler = class public class procedure OnError(const AMessage: string); end; Something.OnError := TMyEventHandler.OnError; The method has to be non-static to provide the needed Self parameter.
  19. David Heffernan

    Anon methods passed as event handlers?

    Er, the complexity is in Delphi with its multiple different procedural types. C# delegates are simple.
  20. You can try our StyleControls VCL. It includes TscStyledForm component - it solve all problems with VCL Style for current form on High-DPI systems + you can add buttons and tabs in caption area. Also it has TscStyleManager component (one for application) to solve all problems with styled menus and common dialogs. For scaled messages you can use our scdialogs unit with scMessageDlg method and more. http://www.almdev.com
  21. dummzeuch

    Forked VSCode for Delphi

    And then there are the small tools, that are (planned to be) used only for a special problem and then probably never again. It's OK, if you tightly couple UI and business logic if it makes writing them faster (true RAD). Unfortunately some of these tend to live longer than expected and functionality tends to be added later, which would require a redesign. But of course that never happens, because "it works as it is" and the new functionality is "just a very simple addition".
  22. No idea, Cortana is one of the first things I disable when I install Windows. As far as I'm concerned, Cortana is the devilish twin of Clippy.
  23. dummzeuch

    Forked VSCode for Delphi

    Revolutionary idea: If Embarcadero wanted to invest a large amount of dev effort (which translates mostly but not only into spending money) into Delphi, they could put that effort into fixing bugs in the existing IDE. Since the number of bugs seems to be growing rather than dwindling, what does that tell you about their priorities?
  24. Remy Lebeau

    On-demand ARC feature discussed

    Many C++ compilers do offer that as an extension. C++Builder has 'try/__finally'. VC++ and CLang have '__try/__finally', etc. But proper use of RAII trumps the need for try/finally at all. But if you want, try/finally can be emulated in pure C++ using lambdas and pre-compiler macros (see this, for example).
×