Arnaud Bouchez

4 hours ago, Stefan Glienke said:

It was perfectly clear that Top, Left, Right, Bottom referred inside the with belonged to the "withed" rect variable and Height and Width to something outside - now those got added to TRect and boom.

Breaking compatibility by adding properties is very likely to break code...
My assumption is that you use and maintain your own classes.

3 hours ago, Sherlock said:

Naming a property/function more explicitly for the sake of with is not helpful.

This was not my point. I didn't mean CarWheel for sure. Wheel, Engine and Drive are fine. a, b and x aren't.
And I wouldn't use "with" over two TCar instances, or two classes with a Wheel property.
But it would have sense, say e.g. to write something like:

with currentCar do
  CarInfo.Caption := format('Engine %s with %d wheel(s)', [Engine.ModelName, Wheel.Count]);

My point was that "As everything powerful can be armful when misused, I like "with", when it is not over-abused".
If the "with" scope is small enough to be obvious and safe, fine. Otherwise, use local variables.

As everything powerful can be armful when misused, I like "with", when it is not over-abused.

For instance, I like "with", when it has only several lines of scopes. It does make sense to me, when used for a single line.
Otherwise, I switch to an implicit local variable: asm generation would be the very same.

If you think "with" should be avoided due to its implicit context switch, I guess next step would be to force using self.foo for class properties... just like the $this->foo of Php... what a progress! 🙂
I am against any new warning at compiler level.
And if you are confused by with someclass do x := a * b and don't know to which class a, b, or x belongs to, it is time renaming the properties/functions to something more explicit!

From the relaxed JSON website:

Quote

 

If a simple-value can be parsed as a number, it will become a JSON number.

{ number: 1.0}
will become

{ "number" : 1 }

 

I still don't get what a "JSON number" is - from its json.org definition, it is any kind of number with none to any decimals...

The worse about Relaxed JSON is that it is not reversible.

It may change the values.

For instance, { number: 1.0 } will become { number: 1 } which is not the same.

So for an exchange format, I would never use Relaxed JSON.

For a settings local file, edited via vim or nano - why not? but as @David Heffernan stated, YAML (or TOML) sounds like better candidates.

The mORMot parser supports "extended JSON", as used with MongoDB: field names can be without quotes.
It follows in fact the JavaScript object declaration syntax.

Internally - between mORMot client and server - it will use it to slightly reduce size and enhance performance.
For regular clients (e.g. JavaScript), it will server standard JSON with quoted field names.
As @Lars Fosdal states, a rigid format seems better when exchanging data between heterogeneous ends.

List of ingredients are stored in at least two MicroServices: the "Pizzaiolo" service (which prepare the pizza) and the "accounting" service (which take into account the ingredients stock, and order them if needed).

You may put the list of ingredients in the "Menu" MicroService... if you want to generate an accurate menu.

Each service may need additional information: the Pizzaiolo would need to have the weight of each ingredient per kind of pizza, the accounting service may have delivery information, and the menu just need the name...

Delphi default MM is a cut-down version of FastMM4 on Windows.
You may achieve slightly better performance on multi-threading by using FastMM4 with some custom conditionals.

IIRC on Apple, Linux or mobile platforms, it uses the clib heap manager. Which is not bad in practice. 

ScaleMM2 or others - like BrainMM - may be better for multi-threaded apps, but tend to consume much more memory.

Under Linux, switching to Intel TBB or JMalloc may give a performance boost, but will also consume much more memory - see my tests with FPC https://github.com/synopse/mORMot/blob/8a55fb3bf2d4cffeb779dd19a8be18e227188f2f/SynFPCCMemAligned.pas#L68

But the main performance enhancement would probably be by changing your algorithms...
Mainly avoiding heap allocations...
See http://blog.synopse.info/post/2018/11/12/EKON-22-Slides-and-Code

Take a look at https://github.com/synopse/mORMot/blob/master/SynCrypto.pas

It is Open Source, works from Delphi 6 up to latest Delphi 10.3, and is the fastest library for Delphi AFAIK - for instance, there is an Intel's SSE4 x64 optimized asm for SHA-256 on x86_64 (Windows and FPC Linux).

You can use the THMAC_SHA256 record, or HMAC_SHA256() function for your purpose.

Following DDD principles, I will define several REST services - MicroServices, to be more exact.

The first service would be a public API. You won't put here ingredients, but only the pizza kinds (marguarita, regina, calzone...), with some potential additional change (add an egg for proteins, remove tomato if allergic...).
This service is known as the application layer. It could be called directly from a web site, a mobile app, or a Linux GTK app (for geeks). It follows the typical high level use-cases of a customer wanting to eat a pizza.

This application layer will then use an internal REST service, in which my pizza "domain" will be coded.
That is, it will know the "pizzaiolo" knowledge. What are the ingredients, how much of each, cooking time, heaven scheduling...

This is the DDD domain, since it is where the real value of the pizzeria is: the better the pizza, the more customers, the more income...

But this application layer may also notify other REST services, like:

- the billing microservice;
- the ingredient stock microservice;

- the user preferences microservice (to retrieve the customer preferred pizzas);

- the delivery microservice when the pizza is ready;

- the management microservice (for the big boss to get consolidated information about the restaurant)...

Those microservices won't be part of the main "domain", and could even be third-party services (billing, delivery...).
Think of the application layer as the "orchestrator" of the whole system.

For more info about services design, and DDD - and how to use Delphi to write such backends, see https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_68

The github link is interresting - if you go to the project page https://github.com/itchyny/fastinvsqrt you find some explanation in English.

See https://en.wikipedia.org/wiki/Fast_inverse_square_root for the theory. 🙂

The license number is used to identify the sale, and you can activate a limited number of times a given licence number.

For a new migration, I would go into creating a VM.

The numbers of Delphi installations is restrained, and after a few setup, you would need to reactivate the licence count - which requires an active licence! So in the future you may need to actually pay a new licence, just to install Delphi on a new computer! (this changed a few weeks ago IIRC)

With a VM, you won't face this problem in the future.

Also note that creating a VM with Windows 10 is free. You are not even required to validate it, if you can stand up with a black wallpaper - which should be find for a VM running a dev environment.

Using '' is the way to go. It works since pascal days, and compiles as a `nil` pointer. Using `EmptyString` or `string.empty` does not make any sense, in the pascal language context.

There is no such thing as a null  string. An empty string is stored as a nil pointer, and there is never some allocated memory with a length prefix of 0. When the length reaches 0, the string is always unallocated by the RTL.

Note: I usually see people writing if length(something)=0 then and still thinking that it is faster than if something='' then. This is plain wrong. The faster version is the latest: if somestring='' - it just checks if the variable pointer is nil, whereas calling length(), even if it is inlined, generates more assembly, and is slower (dual comparison, and an additional jump if the string is void).

On 7/9/2019 at 4:38 PM, chmichael said:

Well, we already have the Current RTL for benchmarking. I'll see what i can do tranfering the old FastCode pascal to this project

We need rather our own optimized pure pascal code.
The RTL did change between versions, so a reference fast pascal version is IMHO mandatory - I have seen pascal version faster than naive assembly.
It could be a very good benefit to install it to old Delphi versions too.

Also be aware that some FastCode pascal is not compatible with 64-bit, nor with FPC, since it targeted 32-bit Delphi only at that time.

And, as with FastCode, you will need to have a system to register benchmarks, on actual diverse computers.
A centralized DB would be better than some XLS files (as with FastCode): any dev could compile and run the code on its own HW, for a given Delphi version, then send it to the main DB.

First step may be to write faster code in pure pascal, with the associated tests.

Then add some asm version, and see if it is actually faster.

There is already a lot of code in http://mormot.net SynCommons.pas which has faster alternatives than the Delphi version.

But two remarks:
1. I wouldn't stick to 64-bit - do why call it UltraCode64 ?
2. FPC compatibility could be very beneficial - as we did for mORMot.

oh I missed the result.x := result.x assignment! 😄

Type-casting to Smallnt() won't be the same as the origin code, for very small or very big values (e.g. x>32768).

Of course, no screen has a 32k horizontal resolution yet... but it may sooner than expected...

I wrote an answer to your question on our forum.

see https://synopse.info/forum/viewtopic.php?pid=29883#p29883

1 hour ago, John Kouraklis said:

From business point of view, it is correct move.

Indeed, from the business point of view, they want to push people buying the Entreprise or Architect editions... so get more money...

But the weird point is that the (very competent) guy behind FMXLinux made it after quitting EMB... weird talent/HR management for sure.
 

I don't see this announcement as a good sign.

From the management/project point of view, they bought a license from the FMX initial developper, who left EMB last year (IIRC) to re-create his own company https://www.fmxlinux.com - EMB dev team was not able to do it on their own anymore.
Sad. I worry about Delphi future if they need to rely on external coders for new targets or features.

From the technical point of view, Linux was supported - with FPC as compiler - 10 years ago http://web.archive.org/web/20091213100642/http://www.ksdev.com/dxscene/index.html when FMX was called DXScene.
So is it a real progress to be able to have back a feature I got 10 years ago, when I bought my lifetime licence to DXScene?
BTW the "LifeTime" of my DXScene license did last 1 year only, since it stopped when EMB bought DXScene - I really felt it was some kind of theft at that time. Now their "LifeTime" license is $349 - I really wonder if it is worth it...

Putting the SQL in the URI is IMHO a way (and unsecure) way of defining a service.
Leaking the database access (and structure) is a bad practice.

This is not REST-oriented at all - see https://en.wikipedia.org/wiki/Representational_state_transfer

The first step would be to put the SQL in the REST body, not in the URI.

Then there is no reason why MARS shouldn't be able to execute it.

Thanks for the tip!
Nice reading.

Note that the chapter about multi-thread friendly MM does not take into account the memory consumption of each, which is a pity.

In short, FastMM4 is very conservative (consume very low RAM), ScaleMM2 define a per-thread heap so will eat more memory, but it is worth saying that I have seen the Intel TBB MM eats hunderth time more memory than FastMM4 (with peaks at 200x RAM consumption).
So I never was able to use TBB on production. Almost the same for jemalloc. Under Linux, a modern glibc has also a great speed - but is a bit paranoid and sometimes SIGKILL the process on some memory error in end-user code.

You have some numbers in https://github.com/synopse/mORMot/blob/master/SynFPCCMemAligned.pas#L57

18 hours ago, RonaldK said:

Linux x64 compiler produce very bloated code.

https://quality.embarcadero.com/browse/RSP-17724

I like very much those generated lines:
0000000000456FDF 8944243C         mov    DWORD PTR [rsp+0x3c],eax
0000000000456FE3 EB00             jmp    0x456fe5 <Project1.initialization()+85>
0000000000456FE5 8B44243C         mov    eax,DWORD PTR [rsp+0x3c]
... which just do nothing: it jumps to the next opcode, and use an unneeded temporary storage... 🙂

Also check https://web.archive.org/web/20170417182109/https://plus.google.com/103246155735524926641/posts/SbLxpp2DipK
 

The problem is not LLVM, which is able to generate very good assembly, but how LLVM is used as backend from the Delphi compiler.
LLVM is a very complex beast, so I don't blame Embarcadero developpers (how many are working on the compiler?), just know how difficult it should be to maintain this path.

I am rather pleased with FPC floating point abilities on Linux x86_64.
It is less optimized than gcc or llvm for sure when using their aggressive settings, but at least FPC generated assembly is clean and efficient. I usually spend hours in the generated assembly to validate algorithms coded in pascal. SSE2 registers allocation and inlining are not bad with FPC, and it is easy to reach good performance on all Operating Systems, once the code is good on a given processor. 

Note that the SQlite3 version embedded with FireDAC tends to be updated at a slow pace, and stick to the Delphi release.
It is currently 3.23.1 in Delphi 10.3, whereas the current is 3.28.

With an OpenSource or third-party solution, you may be able to update SQlite3 without upgrading the compiler.

I have seen requests to upgrade SQlite3 for regulatory or security reasons.

3.23.1 is known to be vulnerable, as reported e.g. by https://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html and https://www.zdnet.com/article/sqlite-bug-impacts-thousands-of-apps-including-all-chromium-based-browsers/

@Markus Kinzler You are right: I forgot about http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html

So many back & forth! 😞
I prefer very much the FPC stability, and attempt to never break existing code - some Delphi people consider(ed) it conservative, but I find it refreshing.

For instance, I would miss shortstring support for sure (are they available in Delphi for Linux?), as IMHO they are a good way to avoid heap allocation and an hidden try...finally block, e.g. for efficient logging or text/JSON/XML generation, if you just append some ASCII characters, and don't mess with encoding. A local shortstring is much more efficient than string in some cases.