Leaderboard

My mistake. This is the correct code: function cntCaseTbl(Z: Int64): Int64; begin Result := 0; //This should be, otherwise the result will be random value if z > 0 then Result := Trunc(Log10(z))+1; else if z = 0 then Result := 1; end;

If I just getting started with the ORM, I would use the one that has been around a long time and heavily tested. V2 still has this in the readme: "WARNING: This set of units is still a work-in-progress, and not yet ready for production."

I would like to have a Delphi version to work with ARM/Linux overall on Raspberry PI and clones. In industry, a lot of embedded ARM-based SOMs are developed with C++ or Python (QT on under the hood), overall for UI parts, but Delphi power could change the trends. I've tried FreePascal + Lazarus but is very messy...

It may sound irritating, but I don't use ORMs at all. Maybe that's because we usually don't have many things stuffed into relational databases, or maybe because this old article left a lasting impression: Object-Relational Mapping is the Vietnam of Computer Science (codinghorror.com). I have no proof, but that for the few times, it was more time-efficient to do it by hand than include a massive ORM library and learn how to use it properly.

Try mORMot: https://github.com/synopse/mORMot

This is a code fragment that shows you how to convert python strings to Delphi strings with PyArg_ParseTuple function ShowMessage_Wrapper(pself, args: PPyObject): PPyObject; cdecl; var LMsg: PAnsiChar; begin with GetPythonEngine do begin if PyArg_ParseTuple(args, 's:ShowMessage', @LMsg) <> 0 then begin ShowMessage(Utf8ToString(LMsg)); Result := GetPythonEngine.ReturnNone; end else Result := nil; end; end; Also have a look at the PyArg_ParseTuple documentation. Using such methods is the low level approach to exposing Delphi code to python. Please have a look at WrapDelphi demos and tutorials for a high-level approach that that does not require you to use PyArg_ParseTuple or worry about reference counting and the like.

Since he already has a hex editor (looks like HxD in the screenshot), setting those bytes to zero would be easy. I don't really see the need for anything Delphi specific there at all

People overuse generics and forget that the implementation often does not need generics at all: type TSupport = class helper for TObject private function __Supports(out ResObj: TObject; cls: TClass): Boolean; public function Supports<T: class>(out ResObj: T): Boolean; inline; end; function TSupport.__Supports(out ResObj: TObject; cls: TClass): Boolean; begin if Assigned(Self) and Self.InheritsFrom(cls) and not ((Self.InheritsFrom(TBoldObject)) and TBoldObject(Self).BoldObjectIsDeleted) then begin ResObj := Self; Exit(True); end; ResObj := nil; Result := False; end; function TSupport.Supports<T>(out ResObj: T): Boolean; begin Result := __Supports(TObject(ResObj), T); end; This code will not cause any bloat at all (in the final executable - see below for the situation during compilation though). What @ventiseis wrote is correct - the issues with long compile-time and possibly running ouf of memory (more so under the LLVM based compiler because they have a larger memory usage already) are real. They are caused by the compiler first compiling unit by unit and stuffing everything generic being used into each dcu just to (possibly) remove it again later during link time. Linker however will only remove exact identical duplicates such as if you have TList<TFoo> in multiple units executable will only contain it once, but it will also contain TList<TBar> and TList<TQux> even though they are also just lists for objects. Since XE7 most methods on TList<T> are marked as inline and unless you are using runtime packages they are not being called in your executable but the internal TListHelper ones but since all RTL classes have $RTTI turned on the binary will still contain all these methods. You only partially get rid of them by using {$WEAKLINKRTTI ON} which you need to put into each and every unit (years ago you could put that into the dpr and it affected all units but that was actually a compiler bug that made flags with scope local being global - but any unit that changed them then also changed them globally which caused quite some weird defects) That is why I did the huge refactoring in Spring4D regarding collections and the generic container registration API. If you use a list from spring with a thousand different classes the binary will only contain the code for the list once unlike with the RTL where you would have it a thousand times The issues are known and reported but obviously are not severe enough or too complex (especially the second one would require some architectural changes to how the compiler deals with generics): https://quality.embarcadero.com/browse/RSP-16520 https://quality.embarcadero.com/browse/RSP-18080

I am not confused. I am frustrated. I want both. Most of all, I want 64-bit debuggers that understand threads and make it easy and robust to focus debugging on specific threads, and that doesn't suddenly stop breaking on breakpoints or break on "invisible" breakpoints in Indy, or just purely stop responding completely. I'd love to be able to "disable" exception breaks for specific threads and only for those threads. I want the broken HighDPI properly and finally fixed. I want the code generation significantly improved for 64-bit. I want RTL, VCL and FireMonkey to be rock solid and efficient. But - also ... I want Generics constraints for enumerated types so that I can use enumerated type and set type operators. I want proper nullable type support, including the relevant operators. I want ARM support for Windows. I want ARM/Linux support for Raspberry PI. I want the static code analysis capabilities of FixInsight and similar, to be built into the DSP. I want a package manager that really works, unlike GetIt which is just a glorified downloader and installer. I want Swagger support for APIs.