Fr0sT.Brutal

FastMM reporting was only one of the options, I also said that DUnitX's mem leak feature uses FastMM facilities. Probably I expressed my point a bit unclear. By "Test project" I referred to DUnitX's self-test project. It has some minor glitches that make it uncompilable (in uses clause). Probably these are leftovers from an old times. Surely there was no offense intention, the project is great (and, what's very important, alive).

Hmm, I'm a bit confused. Do you have two XML's written by two processes? Then I don't get how you could check if a node is "the same". For comparing results you'll have to compare node contents You could assign ID's in runtime only.

Sure he could but pre-defined enums and consts benefit from compiler-controlled item names and CodeInsight showing const values in code editor

Well, you can define lots of overloaded functions like EnumDefValue, EnumCaption etc for now and implement them in any form. Later, if you find a structure you like more, you won't have to change the interface, only the internal implementation. Or, if you decide to switch to enum helpers, perform replace in files with regexp-s ( EnumDefValue\((.+?)\) => \1.DefValue )

For such big numbers you can have all the data in any convenient form (CSV, JSON, XML) and write a tool that would generate a unit from this data.

I suspect you have to use FastMM as well, check DUnitX.MemoryLeakMonitor.FastMM4.pas. Anyway the devs seem not using test project at all, it is even not compilable in current state. Btw, FastMM has its own pretty useful leak report

Yeeah, when you move from English-only to multi-language, these 100 lines will turn into 100 files xD

I prefer the 1st. But keep in mind that most of hard-coded constants could require changing to run-time assignments if you want multi-language support

First could you be more precise what nodes would you consider "equal" and what you're able to do with the loaded document. In the very general case, without preliminary marking all nodes with unique ID you can't tell if two random pointers point to the same node object.

TStringList first reads whole file to a buffer, recodes it to string and then splits it up to lines. While it's the simplest method, it could consume damn much memory (up to 5*FileSize when reading one-byte encoding). So for large sizes one usually prefers some custom read/split implementation

AFAIU Firebird guys prefer perf and stability over language abilities. While it's pretty hard to break a server with just SQL, it is much easier with DLL. And calling a scripting lang like Python from SQL is just a perf killer. Btw, I guess there's also security that is concerned. What if a non-privileged user executes a query with "rm -rf" of "cat /etc/passwords"?

From the point of usability, it's better to indicate somehow that popup menu is available. Otherwise the feature won't be used by nobody except authors ))

Huh, in every programmer's life there's a moment to realize that natural keys suck and surrogate keys rule xD

Well, if you deal with non-changing document, you can calculate paths using indexes, this will uniquely identify a node. Like Base[3].Child[2].GrandChild[2] for a node <Base> <Base> <Base> - 3 <Child> <Child> - 2 <GrandChild> <GrandChild> - 2 <== that's it Or, if you can modify the document internally, you can add ID attr to each node you need. But from what you said you seem wanting to detect duplicates? That's a different task!

I know there isn't but Idera really should think about adding one.

Do you have to stick to msxml? From what I see it's pretty awkward and in Delphi you have tons of native implementations

It can as long as it's asynchronous 😄

Lazarus has multiplatform TProcess with STDIN/OUT interception, waiting for finish and so on. I wonder if something like that exists for Delphi (this should really be in RTL as it's "routine stuff")

M$ tools maybe... Oracle probably (as they both own the language itself) but I doubt about other ones. Anyway the debugger could be attached to any running process so these DLL's could be debugged with RAD studio / MS VS / whatever.

Sure, every security measures should be estimated from the point of what you want to achieve and what skill level of a hacker you want to withstand. In general, every local solution is hackable by design; and not every solution with remote server is non-hackable.

From what I saw regarding UDR's it's just a bloated nightmare even for elementary things. And they haven't got too much advantages over UDF's except sharing current connection/transaction handles.

Consider using pipes, I believe they're a bit harder to sniff than command-line params. Of course you'll need full-featured CreateProcess for this. Or you may encrypt your data and send it via any channel. You can even implement full TLS handshake.

Misconfig affects all users... and too tolerate client tools are making admins too lazy xDDD

In general, a peer couldn't reliably know its external address unless it connects to some remote server and asks him "what's my ip dude". That's why servers that require knowing their own external address usually have a manually editable setting. I'd say that FTP server is configured incorrectly and besides tweaking your side you could write to its owner.

I wonder what's the correct way of using TWSocket.LineMode to read line by line. From what I see in sources and samples, this only works when receiving happens in OnDataAvailable handler. But I create socket descendant and would like to override TriggerDataAvailable instead (using handlers for catching parent events is weird + I want to leave the place vacant for client handler). Unfortunately, I can't make it work. If Receive is called from TriggerDataAvailable, there's no data at all and if inherited TriggerDataAvailable is called beforehand, Receive returns the whole piece of data.