Anders Melander

Yes, you probably need to use a custom renderer to get control over the formats used. https://github.com/microsoft/Windows-universal-samples/blob/main/Samples/DWriteColorGlyph/cpp/CustomTextRenderer.cpp

Probably because of its size. Most Noto fonts are huuuge. Noto Color Emoji contains both COLR and SVG data. The COLR data is ~1Mb while the SVG data is ~18Mb... I'm not sure what you are saying here. Microsoft is the primary author of the COLR format and DirectWrite supports all the common color glyph formats: https://learn.microsoft.com/en-us/windows/win32/directwrite/color-fonts However, the client has to specify what format to use during Shaping and if the client asks for SVG glyphs then that is what it will use. https://learn.microsoft.com/en-us/windows/win32/api/dcommon/ne-dcommon-dwrite_glyph_image_formats You can try subsetting the font to exclude the SVG data and see if that makes a difference (apart from the 18 Mb data saved 🙂)

SVG color fonts are probably slow. All the other color font types (COLR, SBIX, CBDT) should perform more or less on par with regular OpenType fonts.

Beware of unqualified statements involving always and never. Unless the advice is to never put pineapple on pizza. That one is just a fundamental law of nature. As you've discovered it depends on the type of the variable. Local variables are declared on the stack and such doesn't involve the heap (i.e. the memory manager). Allocating a variable on the stack is basically free of cost. However, managed types need initialization and that initialization can be costly. TSearchRec contains a string and is therefore a managed type (i.e. slow). Integer is not a managed type (i.e. fast). Additionally, managed types are wrapped in an implicit try..finally block to ensure that they're also finalized. The help probably has more info on this. If you want to limit the scope just put a begin...end around the whole thing: begin var FileRec : TSearchRec; while not StopSearch do begin ... GetData (FileRec); UseData; ... end; end; Apart from that, in this particular case, you are touching the file system so the performance of inside vs outside will be dwarfed by that. ...and so the lesson here is: You don't get more useful insight by asking first.

What? Are you saying that this wasn't a good idea?

And how many articles have there been on TForm, TStringList, or TBitmap? Blog posts are just them doing marketing. It's hardly an indication of anything other than how much they want you to buy the product.

That's nonsense; RAD Server is not a replacement for DataSnap and DataSnap is not being discontinued. Actually, IMO it is more likely that RAD Server will be discontinued before DataSnap is.

I miss it every single time I need to install/update. Apparently, there are no UXers left at Embarcadero. Left-aligning the button would likely solve the problem but ideally, it should not be placed on the EULA page where one habitually just clicks through.

Looks interesting but then I went to the SonarQube site to see what their commercial terms were like and... Of course, given that they don't even list prices and that I had to Google for them, I guessed that much. OpenSource only then, I guess.

Why do you say that? My guess is that you've been googling and once again have found some information that only applies to a specific product's implementation of WebDAV and once again haven't bothered to try to understand the context of the information. Maybe read the WebDAV specification instead.

It's a private repository... and why don't you migrate it to 64-bit yourself?

AFAIK the zlib library that TZipFile wraps does not support LZMA compression. If you google for "delphi lzma" there's plenty of other solutions.

It makes better sense when you've read the documentation... https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow And as is usually the case with things like this, Raymond Chen has words: https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19083

Sigh. Did you actually read the posts you highlighted? None of them are relevant to you. You do not need Indy to support it. You just need to be able to handle HTTP requests on the server and send requests from the client. Your server implementation will be completely custom to your application (like every other WebDAV server (which is also why you won't find a standard WebDAV "component" on any platform)) and since you will not be using a standard WebDAV client application, your client implementation might as well also be completely custom. If there's an Indu client component that can do what you want then sure, use that. WebDAV is a very simple protocol and would be easy to implement using standard HTTP components. There's nothing special about those requirements. I would think most WebDAV implementations have similar requirements. User authentication is handled in another layer (pretty standard http layering). The WebDAV layer gets user info from that layer and decides what the user is allowed to access and do. What would a user do with a list of "thousands of files and folders"? This sounds a bit like one of my current clients who as a requirement specified that "the grid must be able to display and scroll through a million rows without any lag"... I mean I could limit the grid to 10,000 rows and nobody would ever notice. Regardless, I don't see why sending a list of "thousands of files and folders" would become a performance problem. Regardless of what solution you go for, it's the same information that is going to be sent over the wire. Anyway, it sounds like you are rubber-ducking a bit here and it would probably be smarter to first figure out what it actually is you want to do before asking about how to do it.

I don't know why you quoted that specific document without specifying the source: https://support.netdocuments.com/s/article/360044231332 It's just some CMS service provider notifying its users that it no longer supports WebDAV. WebDAV isn't going anywhere; It's just a protocol standard.

It sounds like you are reinventing WebDAV... Bad idea, IMO. Supposedly a client that has acquired read-access will expect some kind of file stability. It would make more sense to make write locks exclusive and have read locks block the acquisition of write locks.

It took me a bit longer than expected to get here but I believe I've finally reached the goal. The following shows VTune profiling a Delphi application, with symbol, line number and source code resolution: Download Get the source here: https://bitbucket.org/anders_melander/map2pdb/ And a precompiled exe here: https://bitbucket.org/anders_melander/map2pdb/downloads/ The source has only been tested with Delphi 10.3 - uses inline vars so it will not compile with older versions. Usage map2pdb - Copyright (c) 2021 Anders Melander Version 2.0 Parses the map file produced by Delphi and writes a PDB file. Usage: map2pdb [options] <map-filename> Options: -v Verbose output -pdb[:<output-filename>] Writes a PDB (default) -yaml[:<output-filename>] Writes an YAML file that can be used with llvm-pdbutil -bind[:<exe-filename>] Patches a Delphi compiled exe file to include a reference to the pdb file -test Works on test data. Ignores the input file Example: Configure your project linker options to output a Detailed map file. Compile the project. Execute map2pdb <map-filename> -bind Profile the application with VTune (or whatever) Known issues The -bind switch must occur after the filename contrary to the usage instructions. PDB files larger than 16Mb are not valid. This is currently by design. 64-bit PE files are not yet supported by the -bind option. As should be evident I decided not to go the DWARF route after all. After using a few days to read the DWARF specification and examine the FPC source I decided that it would be easier to leverage the PDB knowledge I had already acquired. Not that this has been easy. Even though I've been able to use the LLVM PDB implementation and Microsoft's PDB source as a reference LLVM's implementation is incomplete and buggy and the LLVM source is "modern C++" which means that it's close to unreadable in places. Microsoft's source, while written in clean C and guaranteed to be correct, doesn't compile and is poorly commented. Luckily it was nothing a few all-nighters with a disassembler and a hex editor couldn't solve. Enjoy!

I have just released version 3.1.2 with the following changes since 3.0.1: map2pdb can now consume JEDI jdbg-files. A rare overflow bug in the MSF writer has been fixed. The map parser can now handle the slightly different files produced by beta versions of Delphi. The big change here is the ability to create pdb-files from jdbg-files. You can thank Stefan for being so annoying that I finally caved in and implemented it to get him to shut up about it. This means that it is now possible to profile Delphi's run-time packages by converting the jdbg-files bundled with Delphi and binding the produced pdb-files to the bpl-files. It's as easy as map2pdb -bind:rtl290.bpl rtl290.jdbg Because of a bug in the JEDI tool Embarcadero uses to convert from map to jdbg, some symbol names produced from Embarcadero's jdbg-files may look a bit strange. It's a minor issue that has no impact on the functionality and there's nothing I can do about it since the original map files aren't available. Get it while it's hot: https://bitbucket.org/anders_melander/map2pdb/downloads/ Here's an example from Stefan showing an application using the rtl290.bpl run-time package being profiled with VTune:

I wish you would change your screen name; If you calculate the Scrabble value of it, using French Scrabble, you get... 26 which, as everyone knows, is twice as unlucky. If losing customers due to superstition really is that big of a problem they should just give up and go do something else.

That "joke" is getting a bit old, to say the least. Maybe it's time to evolve and not do that for once.

How do you justify the price difference between the English and the Russian version? English: USD 550-150= USD 400 Russian: 4*USD 65 = USD 260

No, but making a Delphi 12 preview available most likely would have solved it. These closed betas are a ridiculously out-of-date way of doing things.

If only there was a way to solve that problem...

It would make his project fit on 10 floppy disks instead of 35.

I'm pretty sure that depends on who "you" is. So far I haven't found one.