Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 03/13/19 in all areas

  1. David Heffernan

    Rapid generics

    Well, that's exactly what I have been arguing for. It seems utterly insane to me that this task is handled at runtime when it can be handled at compile time. Anyway, as I understand it the record dtor would run in addition to the RTTI based finalization code. So adding a dtor could only ever make code slower.
  2. Stefan Glienke

    Rapid generics

    But we have the slow RTL routines that can easily be improved - we don't have the new ctors and dtors and actually I would not hold my breath for them to be implemented as you imagine them to - they will be driven by additional typeinfo (look into 10.3 System.pas where you can find all the relevant code for that feature because they just disabled it inside the compiler but did not revert the necessary RTL code). And still if you have an array of those record it would still have to loop through the array and call the dtor for every single item regardless. An optimized version of FinalizeArray/Record can just shift pointers over the array and do the cleanup - even if using the records managed field table - that is just a simple record structure, nothing fancy. Putting everything into nested loops and calls regardless the fact if the fields are even filled with something is what makes the current version slow - that is as I mentioned before what makes Rapid.Generics faster on its Clear.
  3. Original post: https://www.thedelphigeek.com/2019/02/design-patterns-with-delphi-book.html Hurrah, hurray, my third book is here! It’s called Hands-On Design Patterns with Delphi and (just like my first book) I wrote it for Packt Publishing. (The second book was self-published and I expect the fourth one to be, too.) As the name says, “Design Patterns with Delphi” deals with design patterns. It is a bit different from most of design pattern books and websites you will find on the Internet. Case in point A: There are no UML diagrams. I don‘t speak UML. Tried to learn it few times but for some reason the whole concept doesn‘t agree with me. If you like diagrams, don’t fear though. Any book on design patterns - and most websites covering that topic - will gladly show how any design pattern can be diagrammed. That, however, is not important and should not govern your decision to buy the book. More important is case in point B: This book speaks Delphi. All the examples are written in Delphi and language features are used to the full. I also covered few less known Delphi idioms in separate sections. You’ll still be able to follow the discussion even though you may program in a different Pascal dialect. There’s also case in point 😄 Examples make sense. I deeply dislike classical design pattern examples of the “And then we want to write this program for different toolkits and it should also be able to draw circles, not only squares” kind. Euch! I tried to find a good example for each design pattern. Admittedly, I ended with few examples that draw triangles and squares on screen (mostly because some patterns were designed specifically for solving such problems), but most of them are of a more practical nature. This book covers all three classical design pattern categories - Creational patterns, Structural patterns, and Behavioral patterns. It also discusses patterns from the newer Concurrency patterns category. At the end I threw in some borderline-pattern(ish) topics and ended with a discussion of few patterns that cannot be strictly classified as “design” patterns. In this book you’ll find: Chapter 1 An introduction to patterns. Exploration of design principles, design patterns, and idioms. A mention of anti-patterns. A short description of most important design principles. Delphi idioms: creating and destroying objects. Chapter 2 Creation patterns part 1. Singleton. Dependency injection. Lazy initialization. Object pool. Chapter 3 Creation patterns part 2. Factory method, Abstract factory, Prototype, Builder. Delphi idioms: Assign and AssignTo. Chapter 4 Structural patterns part 1. Composite. Flyweight. Marker interface. Bridge. Delphi idioms: comparers and hashers. Chapter 5 Structure patterns part 2. Adapter. Proxy. Decorator. Facade. Delphi idioms: replacing components in runtime. Also: helpers. Chapter 6 Behavioral patterns part 1. Null object. Template method. Command. State. Chapter 7 Behavioral patterns part 2. Iterator. Visitor. Observer. Memento. Delphi idioms: for .. in. Chapter 8 Concurrency patterns part 1. Locking. Lock striping. Double-checked locking. Optimistic locking. Readers-writers lock. Delphi idioms: tasks and threads. Also: bitwise operators. Chapter 9 Concurrency patterns part 2. Thread pool. Messaging. Future. Pipeline. Chapter 10 Writing Delphi programs. Event-driven programming. Actions. LiveBindings. Form inheritance. Frames. Data modules. Chapter 11 Wrapping it up. Exceptions. Debugging. Functional programming. I hope you will like this book and learn a lot from it. I know I did during the nine months I spent writing it. And if you find any bug in the code, let me know so I can correct it in the second release!
  4. dummzeuch

    Grep search and DFM files

    I looked into two problems with GExperts Grep and DFM files. While it is possible to fix both, the fixes have side effects: Grep Search does not find strings in DFM files that are split in multiple lines (#49) Searching for text that gets split in multiple lines can be solved by first joining these lines: object l_Test: TLabel Left = 8 Top = 8 Width = 434 Height = 13 Caption = 'Dies ist die Ueberschrift, und sie ist sehr lang, damit es einen ' + 'Umbruch in der DFM-Datei gibt' end So instead of searching "einen Umbruch" in two lines and not finding it, we join these lines into one and then we will find it. 'Dies ist die '#220'berschrift, und sie ist sehr lang, damit es einen Umbruch in der DFM-Datei gibt' This works fine but breaks the preview in the result window. But that could probably be fixed too. But what about this: object m_memo: TMemo Left = 8 Top = 104 Width = 281 Height = 193 Lines.Strings = ( 'first line' 'second line' 'third line' 'and a ' 'veeeeeeeeeeeeerrrrrrrrrrrrrrrrrrrrrrrrrryyyyyyyyyyyyy' 'yyyyyy long line at the end that should get wrapped.') end There are three lines that are short and then a very long fourth line that gets wrapped into 3 separate lines in the DFM file. I can see no way how this could be detected. I wonder how the Delphi streaming mechanism handles this. (Actually it doesn't. When I load that form, I get a memo with 6 lines. At least in Delphi 2007. And that's a bug.) EDIT: Something apparently went wrong in my first test. I cannot reproduce the problem any more. Now, if I add long lines, the DFM file looks like this: object m_memo: TMemo Left = 8 Top = 104 Width = 281 Height = 193 Lines.Strings = ( 'first line' 'second line' 'third line' 'and a ' + 'veeeeeeeeeeeeerrrrrrrrrrrrrrrrrrrrrrrrrryyyyyyyyyyyyy' + 'yyyyyy long line at the end that should get wrapped.') end And that can easily get parsed. Grep search fails to find some words with Umlaut in fmx files (#112) (which also applies to DFM files) object l_short: TLabel Left = 8 Top = 80 Width = 83 Height = 13 Caption = 'Kurze '#220'berschrift' end Any non ASCII character apparently gets converted to its #<number> representation. Again, a fix would be to parse theses strings and convert them back: 'Kurze Überschrift' Which then would be found when searching for "Überschrift". But then, how do we search for 'first line'#13#10'second line' ? The proposed fix would convert the #13#10 numerical representation to a carriage return and line feed character respectively. Searching for "#13#10" would no longer find these. Searching for "\r\n" with Regular Expression turned on, also doesn't find it, but that might still be a bug in my code. So, after spending a few hours on these "bug fixes" I am not sure whether I want to commit them. They might break more than they fix. Any ideas on this?
  5. Rio 10.3.1 Indy TIdSSLIOHandlerSocketOpenSSL seems to not support TLS 1.3. Is there an update anywhere?
  6. Hi Developers, Deleaker was created in 2006, and is been support Visual Studio from the very first release. Now it's time to find leaks in Delphi and C++ Builder! Deleaker finds memory leaks, leaks of GDI and USER32 resources, handles and many others. Deleaker fully integrates with RAD Studio. Here the official announcement: https://www.deleaker.com/blog/2019/03/11/integration-with-rad-studio/ Let's look how it works! Download Deleaker and launch it. Now you can select versions of RAD Studio you want Deleaker to integrate with. Of course, RAD Studio Rio 10.3 is supported: Deleaker is installed, let's launch Delphi: Great, Deleaker is here: Let's add some leaks: Start debugging, click the button, exit. Deleaker is taking a snapshot: Two leaks are shown as expected. It's easy to navigate to source of a leak: Happy coding!
  7. dummzeuch

    New features in GExperts

    GExperts has recently gained a few new features: Two new experts to start/stop recording and to replay a keyboard macro. These are minimal experts which allow you to add additional keyboard shortcuts to the existing IDE functionality. The idea and the code were contributed by Dejan M. Goto Previous / Next modification Editor Experts. These again ... https://blog.dummzeuch.de/2018/12/15/new-features-in-gexperts/
  8. PeterPanettone

    Extremely useful feature

    That is useful only when using one of these options: Otherwise, attempting to load the associated form file can interfere with the current project! So, the MMX Indexer result-list should automatically load the result file in the IDE on mouse-click ONLY if the result-file is part of the current project (or if the result-file is already opened in the IDE). This would be much smarter! Additionally, when using the Root paths option or one of these options: ...then this option in most cases is useless: ...because the content of the Library path or the Browsing path does not change that often. In this case (if the Rebuild option is unchecked) it would be far more intelligent to not erase the index between IDE sessions or to rebuild the index only if a change has been detected in one of these paths! So a separate dockable context preview panel for the MMX Indexer IMO would be very useful.
  9. Rudy Velthuis

    Rapid generics

    I use: Inkscape, Libre office, Gimp, Blender, Audacity, Atom, etc. I know how to use these programs, but don't have the expertise to improve them. And the soures for these things are vast. It would take days to acquire some familiarity with them. Then I would have to find out, if I could, how to improve things. Very unlikely scenario.
  10. Attila Kovacs

    Grep search and DFM files

    And once you are done patching these into your search routines, one day you will face a component with its own TWriter and TReader which breaks all these regular rules and won't work, or in worst case, it will even screw up your concat logic and crash badly.
  11. WillH

    Any plans to support OpenSSL 1.1.x (Or straight to 3.0)?

    This was discussed recently, seems there hasn't been any movement on it. I'm also interested in this topic as some of our customers are starting to ask about TLS 1.3.
  12. Rudy Velthuis

    Rapid generics

    I would want the ability to do things manually (by giving the record a destructor -- if I don't write a destructor, then the runtime will do its usual thing) and forego the rather inefficient type info queries for every field. I know which items need finalization and which type they are and can therefore do it much more efficiently than something like FinalizeRecord, which has to find these things out at runtime. The ideal situation would be, of course, if the compiler automatically added (wrote) such a destructor for us, using the knowledge it has about the types in the record at compile time, instead of simply compiling in a function like FinalizeRecord and type info. But what I have seen (and which was removed again) already showed a lot of promise.
  13. Don't worry about the EmptyStr change, I'm doing it for several units at the moment. Angus
  14. Rudy Velthuis

    Rapid generics

    Of course I have. But first I don't like the old-style IDE (Lazarus) and FPC is not nearly on the same level as Delphi, despite Delphi's bugs and other shortcomings. And yes, it is open source, but I am not inclined to get acquainted with the complete compiler/linker/code generator source code so I may be able to tweak the output. The argument "it is open source so you can change it if you like" only works for rather trivial projects, IMO. I use a lot of open source, but I don't want to tweak any of it by browsing though the usually vast number of hard-to-read source files. And my level of expertise is not good enough to be of any help either.
  15. Jacek Laskowski

    Extremely useful feature

    CNPack has similar or in some cases better solution, see:
  16. David Heffernan

    Issue closing external apps..

    That's because your button event handlers run busy message loops waiting for the child processes to finish. Your mistake is to run those busy loops in the main thread. You should consider running those loops in dedicated threads, and obviously remove the message processing. You code leaks the process handles and has other problems. Duplicating the code is a bad idea. You should be using CreateProcess to create processes. Fundamentally I would say that your main issue is that copying code without understanding it is a bad idea. You then become unable to maintain it and are unable to critique it.
  17. David Heffernan

    Rapid generics

    I don't much care what you like, or don't like. My point was that there exist plenty of compilers that can emit optimised code that is exceedingly efficient, and extremely hard to beat by humans writing code themselves.
  18. Günther Schoch

    What is the compiler switch -VN used for?

    @Uwe: thank you, that helped the dcc command line help is really not complete -V = Debug information in EXE -VR = Generate remote debug (RSM) -VT = Debug information in TDS -VN = TDS symbols in namespace -> that is probably wrong or misleading but the help link you sent explains it! -V Generate debug info in the .exe file -VN Generate debug info with namespace or unit scope name -VR Generate debug info in .rsm file (for Delphi, set by the Include remote debug symbols option on the Project > Options > Delphi Compiler > Linking page) -VT Generate debug info in .tds file (for C++, set by the Place debug information in separate TDS file option on the Project > Options > Delphi Compiler > Linking page) The -VN option does not specify where the debug information is generated. For example, to generate debug information in the .exe file and to include the namespace or unit scope information, you need to specify two options in your DCC32 command, as follows ...
  19. PeterPanettone

    Extremely useful feature

    Done. Thank you!
  20. Uwe Raabe

    Extremely useful feature

    Seems that this is not possible in the moment. Please file a feature request at support@mmx-delphi.de to make this happen in a future release.
  21. Uwe Raabe

    What is the compiler switch -VN used for?

    These switches are mentioned in the documentation for the Debug Information setting in the projects Debugging Options http://docwiki.embarcadero.com/RADStudio/Rio/en/Compiling#Debugging_Options and in the documentation to the Delphi compiler options http://docwiki.embarcadero.com/RADStudio/Rio/en/DCC32.EXE,_the_Delphi_Command_Line_Compiler#Generating_Debug_Info
  22. Stefan Glienke

    Rapid generics

    Well this still does not tell anything about how the list is being used, What their element type is or if they have a change notification attached (because all that influences the performance). I am asking because I have been spending quite some time looking into the rapid.generics code and the 10.3 system.generics.collections improvements and did some own for spring4d. And what makes testing with isolated (micro)benchmarks kinda difficult is the fact that often enough the hardware effect kicks in and shows you big differences that are just there in this benchmark but in real code completely irrelevant or even contradictory.
  23. Anders Melander

    Right Process for Changing an Application's Icon?

    A word of warning to those (I'm counting 50 since yesterday) that downloaded this version: If your resources contains bitmaps that were created by older versions of Delphi (or rather applications built with older versions of Delphi) then the resource editor might corrupt them on save. It appears that a bug was introduced in TBitmap between Delphi 2009 and 10.2. Here's the short version: The format of a windows bitmap is basically 1) Header, 2) Color table, 3) Pixel data. For bitmaps with PixelFormat>pf8bit the color table is optional. The Header specifies the number of colors in the color table (the TBitmapInfoHeader.biClrUsed field). Older versions of Delphi sometimes saved bitmaps in pf24bit/pf32bit format with a color table and the corresponding value in the biClrUsed field. This was unnecessary but harmless and perfectly legal according to the bitmap specs. Here's an example of what such a bitmap might look like: [File header] [Bitmap header, biClrUsed=16, biBitCount=32] [Pixel data] These bitmaps can be read by newer versions of Delphi, but when the bitmaps are written again they become corrupt. Delphi keeps the value in the biClrUsed field but fails to write the corresponding color table. The result is that the pixel data ends up at the wrong file offset. Here's an example of a corrupt bitmap: [File header] [Bitmap header, biClrUsed=16, biBitCount=32] [Pixel data] The reason why this is a problem for the resource editor is that it is built with Delphi 10.2. I have a fix for the problem but I'm not ready to release a new version with the fix. Here's the fix btw: // Fix for bug in TBitmap. // Saving bitmap with PixelFormat>pf8bit with biClrUsed>0 fails to save the color table // leading to a corrupt bitmap. type TBitmapColorTableBugFixer = class helper for TBitmap type TBitmapImageCracker = class(TBitmapImage); public function FixColorTable: boolean; end; function TBitmapColorTableBugFixer.FixColorTable: boolean; begin if (TBitmapImageCracker(FImage).FDIB.dsBmih.biBitCount > 8) and (TBitmapImageCracker(FImage).FDIB.dsBmih.biClrUsed <> 0) then begin TBitmapImageCracker(FImage).FDIB.dsBmih.biClrUsed := 0; Result := True; end else Result := False; end; The problem appears to be the same one reported here: Setting TBitmap.PixelFormat can lead to later image corruption or EReadError
  24. Allen@Grijjy

    TIdSSLIOHandlerSocketOpenSSL and TLS 1.3 ?

    Some thoughts on OpenSsl 1.1.1....We recently finished porting the OpenSsl 1.1.1a headers to Delphi for all platforms (Windows, macOS, Android, iOS and Linux, 32 and 64-bit where appropriate) and may write an article for our grijjy blog on that sometime soon. The challenge is building in a way that works for each Delphi platform, which we also did in the process. Deploying OpenSsl with your app in a way that is uniform for all platforms but does not interfere with legacy OpenSsl that is sometimes part of the OS is also a challenge. The libraries for LibSsl and LibCrypto often cause dynamic linking issues on POSIX platforms when they attempt to reference one another. We solved this with some creative linking that is platform specific. Also it isn't wired into Indy, because we don't use Indy internally, but it shouldn't be too hard (for someone else to do). The other challenge is TLS 1.3 isn't really completely working in OpenSsl 1.1.1 and has a few outstanding issues. You probably don't want to use TLS 1.3 at this time.
  25. Remy Lebeau

    TIdSSLIOHandlerSocketOpenSSL and TLS 1.3 ?

    The link that Lars provided is a year old, but the answer is still the same. Indy does not yet support OpenSSL 1.1+, and so does not yet support TLS 1.3. It is in the planning stage, no code has been written yet: https://github.com/IndySockets/Indy/issues/183
×