Fr0sT.Brutal

Opensource : see my signature

Well, with all these tons of framework scripts, ads, trackers, when just an empty Google page weights 500 kB... lower size seems not something they care about

Just remember that async model is much more complex to implement correctly. You have to build state machine and consider all possible cases. In addition, unexpected things could happen when mixing async and sync methods (i.e., if in the handler of an async event you run some sync methods that lead to socket destruction - you likely will get AV).

F-Droid but only opensource apps Xiaomi probably have something alike (heard they with Huawei and some other companies were going to run their common market but not sure they did).

I doubt having 2 big network libs in a project is nice idea. Though, everything depends on how many connections you'll have. 1000s of threads won't be a good solution either.

Open the site in native mobile browser maybe? Never realized what's the sense in converting every site on the Internet into an individual app.

I like online more so that I don't have to download stuff which then needs to be deleted... too much excess actions. These files are for evaluation purposes anyway. As for the code: it's quite poor. Not the most awful one I've seen but something like I wrote when I was student. IMHO it first needs careful refactoring (no serious skills really, just accuracy and some knowledge of what's right and wrong).

iconfinder and similar. "Font awesome" is very nice as well for mobile and web graphics, considering the current minimalistic monochrome fashion.

Method TCustomHttpTunnelWSocket.HttpTunnelTriggerResultOrContinue calls TriggerSessionConnected(0); on successful tunnel handshake though it likely supposed to be TriggerSessionConnectedSpecial(0); just like Socks5 socket does to consistently report the connection is established.

Read in docs what hash algo password_hash() uses Search implementation of this algo for Delphi Write primitive verification routine

OUCH! That's really a heavy monstrous piece of petrified sh- ehm, code.

Agree. Delphi keeps backwards compat pretty well and major part of code doesn't require any changes.

I'm always voting for code cleanup. And still insist that pretty much of what could be done automatically for this issue could be done via "comment a unit - try to build - OK: remove unit / Fail: revert unit - repeat" cycle. You don't even have to build the whole project as command line compiler, IIRC, allows building separate units. Though, any other cases still require developer's brain. When tools become so smart they could decide that SomeOldLib.i2s is the same as RTL IntToStr we all human devs will become obsolete. Btw, (I'm sure you know that perfectly) any unit removal could potentially lead to subtle bugs even if it seems excess: unit init sections or overridden identifiers. Of course, a tool could check for these cases and leave decision to a user... maybe Pascal analyzer can do it?

I also enter via https://en.delphipraxis.net/discover/unread/

Probably there's something wrong in the way you use Indy or maybe an old version. Try to invite here @Remy Lebeau

"Done. Your free beer awaits you at Alpha Centaura"

So why bother this at all? Uses manipulations are no more than a cosmetic change. Of course the intention could be to remove some 3rd party deps, but that anyway requires much more brain than a mechanical purging/grouping.

FWIW, with UDP packet loss is normal

If deprecation is mentioned in docs, you can check it on docs.emba site, they keep docs for all versions

This 1) only should be done once 2) could be done by a not so genius utility

I think people wouldn't use them if they could avoid them. Alas, sometimes there's no other way

IDE seems to always add units to the end. So you can check the tail of uses list for VCL-related stuff (by namespace prefix, f.ex. - not a universal solution though as there could be 3rd party components/controls). Or you can add a dummy unit that should always be the last one in uses list so anything that goes after is auto-added. Control over it could be bound to the same pre-commit hook. Or you can add a never-enabled dummy ifdef to the very end of uses list that will function like a signature: uses .... SomeUnit {$ifdef foo} USES_END {$endif} Of course, these solutions require somewhat ordering in uses clause. Alternatively, a tool could store uses lists for any unit and reject any changes so a dev using a new unit should additionally allow it.

What happens if you add this define to Fastmm.inc?

Sometimes table and query are both just a thin wrapper over the same dataset class. Table allows nice combobox with table names and controls underlying query itself. With query you have to write query but it gives much more customization abilities.

Alas, auto-using units is a real pain. There's no any good solution that I'm aware of. The most simple is to use traditional IFDEF approach which IDE could understand at design-time but with COMPILER_XXX_UP defines (borrow them from JEDI or anything else). Definition of these flags look VERY sracy but at least they live in separate .inc file that's hidden from coder's eyes. So instead of the same lines for every version you'll have {$IFDEF DELPHI_XE_UP} Namespace.SomeUnit, {$ELSE} {$IFDEF DELPHI_7_UP} SomeUnit, {$ENDIF} {$ENDIF} note the descending order. But every new compiler version must be added to defines list or build would fail (many libs and components suffer from this flaw - all these "added support for Delphi %NewVer%" updates mainly add the corresponding define). There's also option to set aliases for namespaces in project options and use old-style short names though it could only solve a part of these issues. Pre-commit hooks? Also it's a very useful idea for an IDE expert, something like cnPack's property cleaner