Anders Melander

Yes but that's the same for all three tests. The smaller array should still benefit the most from the cache. To me the posted results indicate that there's a lot of per-sort overhead somewhere.

You didn't answer any of my questions... Regardless, would you care to publish your test code so we can see how the sausages got made?

There's something fishy with those numbers. I would have expected the 500K test to have better throughput than the 5M and 1B tests since the 500K array can fit in the 24Mb cache while the 5M and 1B arrays cannot. Did you do a warm-up run before the benchmark to get the thread pool spun up? How many iterations did you do on each test?

You mean without using {$WARN}? Have you looked in the project settings to see if there's an option there to disable it?

Let me Google that for you... https://en.wikipedia.org/wiki/MsQuic https://github.com/microsoft/msquic/blob/main/docs/FAQ.md Enabling HTTP/3 support on Windows Server 2022 Troubleshooting HTTP/3 in http.sys

*facepalm*

That's a strange statement. Why are threads evil? Eric is trying to do something with a class that just wasn't designed for what he needs. That in itself doesn't make the design wrong or bad. The counter-argument is that no one knows how the functionality of a class' public API will be implemented in future. Class members are private in order to not lock a public API to a specific implementation bound to those private members; They shield the API from implementation details. You are basically arguing against the use of encapsulation.

About three decades of progress. Database Desktop was, as far as I remember, a heavily trimmed down version of the Paradox front end. Borland sold Paradox to Corel in the 90s and apparently Corel, or whatever they're called these days, is still stuck with it. So if you want a query tool that support Paradox and runs on modern Windows your best bet is probably Wordperfect Office (shudder).

I guess so. If only there was some kind of advanced technology one could use to help with that. I mean it's not like this is the first time.

🤦‍♂️ If only there was some way to communicate stuff like that to their users...

I haven't worked on POS systems for almost a year, so things might have changed since then, but I seem to remember that one of the components that were kinda important to the customers was the actual Point Of Sale part... Maybe ask your AI why it left that little detail out...

Yes I know what MVP means but you, your customers, or your sales department, still need to define the criteria for what a "viable" product is. You can't ask us for that because we have no stake in it and we don't know your target market. If you know the needs and demands of your market there are simple methods to define a MVP but it's not a process that involves developers.

That depends on how you define "viable", doesn't it? Nobody is going to be able to answer your question without additional requirements.

As far as I can tell it uses GetStringType(CT_CTYPE3) and skips codepoints with the C3_NONSPACING flag or without the C3_ALPHA flag.

...also known as the single character U+00E5 (Latin Small Letter A with Ring Above) of which U+0061 U+030a is the decomposition. But, even if the input was guaranteed to be composed Unicode then it would not be safe to replace CharPrev with a "-1" without knowing the exact algorithm CharPrev uses internally. The "looks like" part is nonsense since the glyphs produced by that sequence depends on the font being used to render it but it seems like CharPrev just skips all Combining Diacritical Marks.

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!

Not that I know of. The file format is completely undocumented and there's no known API to extract info from it. A bit of googling found these: https://www.delphipraxis.net/48587-dcp-format.html http://hmelnov.icc.ru/DCU/ https://gitlab.com/dcu32int/DCU32INT/-/blob/master/DCP.pas?ref_type=heads The DCU32INT project looks like it could be a stepping stone.

Next up: How to use "with" to make your code more readable.

Nice catch!

The Win32 AlphaBlend API also requires alpha premultipled RGB. But just because the display API requires premultipled pixels doesn't mean that TBitmap should premultiply and then discard the source pixels. What it should have done is to create an internal premultipled copy of the source pixel data for display purpose if and when it was needed. The GR32PNG implementation can probably be adapted for FMX. It's the default PNG format handler in Graphics32: https://github.com/graphics32/graphics32/blob/master/Source/GR32_PortableNetworkGraphic.pas https://github.com/graphics32/graphics32/blob/master/Source/GR32_Png.pas

Are you really comparing the way an actual sentient intelligence learns principles by study to the way a language model works?... Well, I guess you are then. While that's an interesting fantasy, the reality is that you are equaling two entirely different things. Language models can not and does not form independent ideas; It can only function by copying, either directly or indirectly, existing work and nothing prevents a LLM from suggesting a solution based entirely on or copied verbatim from a single source - and that is a license violation.

Open Source does not mean that the code can be used freely. There are still conditions that must be observed (attribution, restrictions on usage, etc.). An AI (or the people that train it) doesn't care about that. I think that is naive. Have the people who wrote those policies earned your trust? In my POV, that whole industry has shown from the start that they can't be trusted. I don't think you understand how these things work; We are nowhere near being able to do anything like that. In fact that task would require a completely different type of AI. All we have now is one that is good at emulating stuff. Volkswagen wasn't a mistake or an accident. They knowingly implemented a mechanism to circumvent an environmental test. AI companies use the Science excuse instead; Their purpose and goal is more important than rules and ethics. If they were actually working a kind of AI that could do more than just copy other peoples work then I might understand it - but they aren't.

It does complicate things but yes, as you suggested, you could have a structure that contains both an TStream (for persistence) and a TBitmap (for display). The TBitmap would be created and loaded from the TStream once, on-demand, when the image needs to be displayed. This is also the technique used internally by many VCL image containers (e.g. TGIFImage, TPNGImage, TJPEGImage). That at least would mean you only "wasted" memory on the bitmaps that were actually displayed. Not really. The data in the stream is compressed and probably much smaller than the decompressed image data.

I don't use FMX and I haven't looked at the source but as far as I can tell, from your the images and description, the problem is that TBitmap premultiplies on load and unpremultiplies on save. The degradation of pixels with alpha<>255 is caused by the inevitable rounding errors. The VCL TBitmap has the same problem if one messes with the AlphaFormat property. Apparently they didn't learn from their first mistake and instead decided to make it worse. The reason the FMX TBitmap premultiplies the bitmap is probably because it needs that when displaying the bitmap (e.g. when using the Win32 AlphaBlend function). Anyway, the solution to your problem is to not use TBitmap as a storage container. Use TBitmap only for display of the image and use instead use TMemoryStream or something like it for storage.

Please also post the image as it is after you have saved it. My guess is that the load+save premultiplies the RGB with the alpha.