Leaderboard

OmniThreadLibrary 3.07.8 has just been released. It contains few small fixes + support for Delphi 10.4 Sydney. Changelog: New features: Implemented IOmniTask.RegisterWaitObject with an anonymous method callback. [Jacek Laskowski] donated a new OTL icon (res\OTL.ico). Added Delphi 10.4 Syndey packages. Bug fixes: [sglienke] A reference to an anonymous method executor in IOmniTask is cleaned up as soon as possible. This allows OTL tasks to be executed from a package. [issue #132] TOmniMREW.TryEnterReadLock and .TryEnterWriteLock were returning True on timeout. SetOnMessage(nil) works correctly. Fixed invalid FreeAndNil of an interface in TOmniFuture<T>.Execute. Compiles with Delphi 10.4 Sydney. https://github.com/gabr42/OmniThreadLibrary/releases/tag/release-3.07.8

If you want to use the"stand alone" tools in GExperts, you might find that they don't work if the bpl files it needs are not in the search path. These tools call the dll, the dll is an IDE plugin, an IDE plugin needs some bpls, so there is no way around that (other than making those tools not use the dll).

I remove them all. I don't have any problems. It means I can use any of the many versions I have installed easily. For versioned packages, e.g. vcl270.bpl then multiple entries are fine. But for non versioned tools, e.g. dcc32.exe then it's a mess. These days it just feels a bit weak to rely on the path to find libraries. I always place them in the executable directory, or in sub directories and use SxS assemblies. I remove all entries and then my build scripts set up the appropriate environment for the target version, and then call msbuild. Works for me but I'm sure there are other ways.

Conclusion: It doesn't matter whether I use Breadth First or Depth First Search, the performance is the same. Switching from SysUtils.FindFirst/FindNext to Windows.FindFirstFileEx/FindNextFile with only basic file information and the flag FIND_FIRST_EX_LARGE_FETCH brought me a performance gain of about 25% which is not too bad. I found no way to benefit from using TDirectory. The only test I made got worse performance than FindFirst/Next. Test environment: Windows 8.1 client accessing a share on a Samba server over 1 GBit Ethernet with minimal traffic (it's a weekend). The computer is a reasonably fast Intel Xeon E3 with 3.4 GHz with 8 cores and 16 GByte RAM. The Server has an Intel Core I9-9940X processor with 16 cores and with 64 GBytes of RAM. The share is stored on a 2 TB Intel M2 NVMe SSD. It's running Ubuntu 18.04.4 LTS and Samba 4.7.6-Ubuntu. The test program was compiled with Delphi 10.4. There was a no noticable difference between building with Debug and Release config. The directory tree is 4 levels deep and contains only a few directories on the first 3 levels but a total of 898 directories on the deepest level. Each of these directories on the deepest level contain from several hundred up to several thousand jpeg files. The purpose of the code is to find all directories on any level containing at least one jpeg file but no subdirectories. All tests were run several times in varying order to prevent any caching effects to distort the result.

I have a collection of Syslog and Windows Event Log Utilities. All 100% developed in Delphi. http://www.allthingssyslog.com/ They are intended for use in testing. Unfortunately I can't put links to the actual tool pages as the site is a single page React Web Application at the moment. Will convert to ASP .Net when I get hosting sorted out. There is a menu in the top right corner of the page which is easy enough to navigate. Go to the Downloads to access the following: 1) The Simulator. This allows you to send test messages to your Syslog server, Log Management system or whatever. Messages can be edited, sent on demand, sent in repeating batches etc. 2) The Windows Event Log Converter. This utility will read entries in a Windows Event Log and forward them to a Syslog Server. There is also a YouTube channel with tutorials on using these utilities here: https://www.youtube.com/channel/UCg97aUZMTKlqMNA_Qxc8wWA Most recently I updated the UIs to make them multi lingual. I just hope google translate didn't give me the German/French/Italian/Dutch equivalent of Engrish. Go to the Utilities page for some extra stuff 1) A basic test Syslog Receiver. It takes messages on UDP and dumps them to a file. Noting special, not even good performance, but useful for demoing basic principles in videos. 2) A Windows Event Log Writer. Works pretty much the same as the simulator, but instead of sending messages to a Syslog receiver, It dumps them in a local Event Log. Using batches it can write up to 12k logs/sec into a Windows Even Log. I originally started writing this stuff to do dev testing on a log management system, but the company was never interested in building out a serious testing architecture. After I left I kept working on them. I still find them useful on occasion, maybe others will too.

Thank you, @Dalija Prasnikar, I just wanted to post exactly that 🙂 New release should go out this weekend.

I always do Stopwatch := TStopwatch.StartNew; On a side note I wonder if the new managed records thing could make your original one work (which I would prefer.)

On the other hand, if I only want to create one installer, it's easier to temporarily edit the makeinstallers.cmd, where I can simply copy one existing line rather than having to remember exactly which parameters I'd have to pass: rem [...] rem *** copy one line from the list below here *** rem *** and remove two REMs *** rem call :makeinst RS103 RS10.3 rem pause rem goto :eof :list call :makeinst Delphi6 D6 call :makeinst Delphi7 D7 call :makeinst Delphi2005 call :makeinst BDS2006 call :makeinst Delphi2007 call :makeinst RS2009 call :makeinst RS2010 call :makeinst RSXE1 call :makeinst RSXE2 call :makeinst RSXE3 call :makeinst RSXE4 call :makeinst RSXE5 call :makeinst RSXE6 call :makeinst RSXE7 call :makeinst RSXE8 call :makeinst RS100 RS10 call :makeinst RS101 RS10.1 call :makeinst RS102 RS10.2 call :makeinst RS103 RS10.3 call :makeinst RS104 RS10.4 rem [...]

@dummzeuch, perhaps one more improvement can be made: creating the installer for only a specific version of the application, depending on the parameters passed to MakeInstallers.cmd (the modified file in the attachment) And then, it will be possible to create an installer, for example, only for Rad Studio 10.4 with the following command: MakeInstallers.cmd RS104 RS10.4

Thanks, that was it 🙂 I remember I disabled it in previous version and when installing 10.4, I exported all settings and then imported them via the migration tool. Fix was to set Enabled to 1 in registry under "Computer\HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\Theme"

Thanks, I missed that one. As for the others I now know why I didn't see those errors: I compiled these projects with Delphi 2007 only. Maybe I should switch to a more modern version.

all should be fixed now in svn

There is a bug. You cannot move active tab. You need to select some other tab first and then you can drag the tab you want. Cannot rearrange editor tabs, when it is selected https://quality.embarcadero.com/browse/RSP-28465

In my installation nothing has changed in this respect. The project window can be pinned and unpinned, where "unpinned" means it's just a small panel to the right that makes the window visible when clicking on it. Maybe undocking and docking it again will solve the problem?

You already fixed the issue, but that issue is already fixed in Omni Thread, too. There is newer version in the making, not released yet, but it has fixes and packages for 10.4. Last commit was just 4 days ago. https://github.com/gabr42/OmniThreadLibrary When new Delphi release comes out and you find issues with some of the libraries you are using, it is good to recheck library for updates. Keep in mind that libraries cannot be publicly updated before official release and sometimes takes a few days to have those patches and fixes generally available.

We see a spike in traffic visiting this post on our site after every delphi release - how-to-fix-your-system-path-after-installing-delphi It's rather sad that it's the second most popular post on our blogs (after the DUnitX introduction post).

TDirectory.GetFiles seems horribly inefficient to me. In most cases it's probably fast enough.. but looking at the code, I can't help think it's use TPath.DoMatchesPattern is wasteful (creating the mask and freeing it each time).

There are two simple enhancements that can be made to Delphi FindFirst (which I never call, having adapted it into my own version as a replacement). I do not think that either will help you search a Samba network drive, but together they can significantly enhance file searching on Windows file systems. The secret is to call Windows FindFirstFileEx instead of FindFirstFile, which is used both by Delphi FindFirst and therefore also by TDirectory.GetFiles. On modern OS, the 'Ex' function allows you to opt for a larger buffer, and also to omit the double search for the 8.3 equivalent alternate names in addition to the full file names. Once you have set up the 'find' optimally in this way, you can call the standard FindNext and FindClose functions as usual. MSDN has the details you need for FindFirstFileEx. But to address your question, my guess is that your recursive search would turn out to be faster than multi-threading the subfolder searches, if you were to measure it. And measuring in your own environment is the best way to get the answer.

But TDirectory.GetFiles (System.IOUtils) internally uses FindFirst/FindNext too...

Sure, why not? The two are located in different continents ;)

I once wrote a tool for that: https://uweraabe.kilnhg.com/Code/Community/Delphi/CompressPath