Fr0sT.Brutal

SVN. Why "not super nice"?

Still couldn't get your point. Or maybe I didn't explained mine. When I commit changes to VCS, I inspect changes to DPR and revert unneeded ones if IDE screwed up some sections again.

This one is nice as well, SQL-style

Really sly solution, why not just VCS?

Just updated to fresh SVN version and found all my 8.5x fixes are still actual. I really wonder how you guys manage to compile sources with these typos xD Patch file is attached ics_compile_fixes.diff

Explanation: achieve compilability (tested on XE2) Version: latest from 17.12's SVN

@Angus Robertson btw plz don't take my words as offense or something, I didn't mean anything of that sort... Still hard for me to keep emotional or politeness nuances in English. Yep, no problem while the integration isn't too deep. I'll try to keep closer with recent changes.

Very sad to hear that 😞 I'm not reporting, I provided patch instead 🙂

Anything after Application.Initialize is easy to track... the trick is when some earlier actions cause slowdown. When running app in IDE by F7, process is stopped at the entrypoint when all binary file reads and necessary resource loads are made by OS. Then, enabling "Use debug DCUs" and "Trace into", you can trace System.InitUnits that executes all init sections of used units. Something like a non-breaking breakpoint at line "TProc(P)();" with options "Eval expression" = "inttostr(i) + ' ' + inttostr(gettickcount)" will give timings. When the villain's index is spotted, you can "Trace into" the above line to find out what unit it is.

I have TWSocket descendant implementing SChannel connection and currently all TLS-related problems raise an exception (that is, exception is raised by utility functions, I just do nothing special in socket). I wonder if that's the correct way of reporting errors in ICS. I looked at the code of OverbyteIcsWSocket.pas and found some `SocketError` uses, some `RaiseException`, some `raise ESocketException` and some `TriggerXXX(Error)` / `SetLastError`.

Sure you have. Apparently you haven't tried without USE_SSL or with OPENSSL_USE_RESOURCE_STRINGS define haven't you?

MyException := ESocketException.Create(MyMessage, AErrorCode, AErrorMessage, AFriendlyMsg, AFunc, AIP, APort, AProto); if Assigned (FonException) then begin TriggerException (MyException) ; { V8.36 } end else begin TriggerException (MyException) ; { V8.37 } raise MyException; end; if Assigned (MyException) then MyException.Free; { V8.37 } end; end; This fragment looks pretty weird for me 1 - TriggerException is called always so could be lifted before `if Assigned` 2 - `if Assigned (MyException)` is useless because it's created several lines earlier Wouldn't this be the shorter equivalent? MyException := ESocketException.Create(MyMessage, AErrorCode, AErrorMessage, AFriendlyMsg, AFunc, AIP, APort, AProto); TriggerException (MyException) ; { V8.36 } if not Assigned (FonException) then raise MyException; MyException.Free; { V8.37 }

This is the kind of hint that must be prefixed with Use with care and only if you absolutely need this! warning. While this could add some speed, this also reduces encapsulation, making testing more hard. When local variables really kill performance, it's better to use var parameters. Would be nice indeed. It took plenty of time for me to discover that any string concatenation or a routine returning a temporary string causes compiler to generate hidden try-finally block. On the subject: my personal rule is to just keep in mind that local managed variables add overhead. If a routine contains a string operation just for rare error report, don't use concatenation or Format but Exception.CreateFmt instead, or a nested routine. All arguments of record or managed types must be used by reference (const/out/var). But don't bother any more if a routine requires several strings or something non-optimal etc until it causes noticeable slowdown. I really do string concats in a loop and other performance-wise awful things to keep code short and simple when a function is executed relatively rarely.

SNAKE_CASE is good as well (moreover, it even has upppercase form - using a pretty big snake, maybe anaconda - and lowercase with some compact snake like viper). I wonder what "Snake kebab case" would look like 🙂

Yep I already figured it out and modified the text. Anyway there's no any mention of this feature in docwiki

In the exactly same situation (using extra unit for just one 3-lined function annoys me like hell) I ended up with most trivial solution - I named my functions `IfTh`.

Fantastic! This function is undocumented for some reason... I added it to my TEnum<T> implementation

T for types, I for Intfs, E for exceptions, F for fields, rarely A for arguments - when the name without prefix clashes with something but is too good to change. That's all. Other things seem to me just a useless visual noise requiring more time to type

I wonder what you gonna do with, say, TCustomForm's property Left: Integer read GetLeft write SetLeft;

Poor man's solution: const S_M_ExceptInfoPatt = '%s (%s @ $%x)'; ... Result := Format(S_M_ExceptInfoPatt, [E.Message, E.ClassName, NativeUInt(ExceptAddr)]); then run your app in IDE with F7 or stop at an breakpoint, Search > Goto address

TortoiseGit. Never used RAD or VSCode integrated solutions. In RAD I added some useful actions as external tools (Pull, Commit, Log, git command line).

I've no idea about numpy and how it organizes its arrays but making array object point to a buffer coming from Delphi is exactly what I meant

Why not just use pipes or sockets instead?

You of course can feed Python with the pointer to your Delphi array but what you can do with it depends on what you want Python to do with it. Iа Python has raw arrays, you're lucky.

f1 := ReadField; f2 := ReadField; f3 := ReadField; f4 := ReadField;